Ruth Wageman’s first field research project, as she recalled it in 2020, began with a reorganization. She was a graduate student at Harvard, and the people she was studying were service reps who had just been put into self-managing teams.
Each rep had once had his or her own customers, schedule and preferred way of doing repairs. Now they shared territories and designed their work as a team. Their front-line managers changed jobs too. A manager who had supervised 10 to 20 individuals became the coach of two to four teams.
The managers wanted to know what that meant. What “precise alchemy of coaching behavior,” in Wageman’s words, would turn their teams into superb ones? Coordinating tasks? Asking good questions? Cheering the team on? And which old supervisor habits, like telling a team its problems and how to solve them, had to go?
They were asking about the part of the job that, in her data, would turn out to matter least for how well the work got done.
Design against coaching
Wageman also published a separate field study in 2001. It compared two things leaders do for self-managing teams: the design choices they make when setting a team up, and their hands-on coaching once it is working. Her frequent co-author, the Harvard psychologist J. Richard Hackman, described it as a study of self-managing field service teams at Xerox.
Both kinds of leadership affected how well a team managed itself, how members got along and how satisfied they were. Only design affected how well the teams did the work. In Hackman’s summary, design features accounted for 37 percent of the variation in performance outcomes, and leaders’ coaching for less than 1 percent.
Coaching wasn’t worthless. Well-designed teams were helped more by good coaching than poorly designed ones were, and hurt less by bad coaching.
Sixty, thirty, ten
By Hackman’s estimate, most of how a team does is settled before its work begins.
He put numbers on it in his 2011 book Collaborative Intelligence, writing that “my best estimate is that 60 percent of the variation in team effectiveness” depends on how far a team’s enabling conditions are in place, 30 percent on the quality of its launch, and just 10 percent on the leader’s hands-on, real-time coaching. In Wageman’s account, the 60 is prework: getting a real team, a compelling purpose, the right people, a solid structure and a supportive organizational context in place, long before the team is brought together.
Notice what kind of claim this is. Hackman called it an estimate. Wageman calls 60-30-10 a “helpful heuristic” for where team leaders should put their energy, one that she and Hackman formulated from the survey they built on their many studies of teams. Neither presents it as a measured split. The 37 percent comes from one study of one company’s service teams. Read it as a rule of thumb from two researchers who studied teams for many years, not as a law.
The 30 is the part people skip. Wageman describes the launch as the moment a list of names becomes a bounded team. Members often test the leader’s statement of purpose, ask clarifying questions with “a confrontational undertone,” and redefine the purpose to some degree. That’s why she wants the leader to decide beforehand which parts of the purpose are negotiable and which are not.
Agents set up to fail
AI agents give a quick way to see the same split, because a run’s setup is written down before anything happens.
In a 2025 study, Mert Cemri and colleagues at UC Berkeley annotated more than 1,600 execution traces from seven multi-agent systems and sorted the failures into 14 types. In a sample of 210 of those traces, 30 from each system, the largest category, 41.8 percent of failures, was system design issues: agents ignoring the task requirements, repeating steps, losing context, not noticing the task was done. Those failures happen during the run, the authors note, but often reflect choices made before it, about the system’s architecture, its prompt instructions or how it keeps track of state. When they changed only the workflow and prompts, with the same underlying model, success rose by up to 15.6 percentage points, from 25.0 to 40.6 percent on one system’s benchmark. Task completion rates still stayed low.
You can test this on your own runs. When an agent run goes wrong, write down whether the cause was in the setup (what the task said, who owned which step, when to stop) or in the moment. Fix the setup, run the same task several times, and compare against the old version’s runs. One run proves little either way. If your fixes are mostly mid-run nudges, you may be spending the 10 percent.
A calendar with 130 meetings
Imagine you’ve been handed five people and six months to rebuild your company’s customer onboarding. Your calendar has a weekly one-on-one with each of them, about 130 meetings of coaching, and a thirty-minute kickoff.
Wageman’s rule suggests moving the time forward. Before the kickoff, you decide what is fixed (the launch date, the budget) and what the team can reshape (the scope, the order of work). At a kickoff that now runs half a day, someone pushes back on the goal itself, and the team rewrites a third of it.
Some of the one-on-ones get cancelled. Nobody asks for them back.