The Extra Chair
You were faster when you were smaller. Now there are more capable people, and getting anything through takes longer.
The answer is usually more help. More people to share the work.
More process to keep them aligned. The work still slows, so you push harder.
That can make the failure feel personal. You remember what the company could do.
You know the people haven't stopped caring. Yet the effort that once produced progress now goes into keeping everyone informed.
More effort can go into coordination without moving the work forward. Growth changes the cost of getting work done, even when everyone does their job well.
Growth raises four costs at once.
Coordination costs rise as more people need to agree.
Context gets lost as work passes between people.
Feedback arrives after the decisions it should have informed.
The structure sets a limit on what all that effort can produce.
I call the way these forces work together the Momentum Engine. Each cost can look like a different problem from inside a department. Together, they explain why adding help can leave a company slower than before.
The people may be doing more. The work has farther to travel.
The extra chair
The first cost is arithmetic.
Five people have ten possible pairwise connections. Ten people have 45.
Fifty have 1,225. Those are possible pathways, not a count of conversations everyone must have.
But when work requires everyone to coordinate with everyone else, the distinction offers little comfort. Capacity grows with each person. The number of possible connections grows much faster.
Fred Brooks described this in The Mythical Man-Month in 1975. He had managed IBM's OS/360 project, which involved more than 1,000 people at its peak.
His warning was blunt: "Adding manpower to a late software project makes it later."
Brooks called that an oversimplification. The condition matters: work that can be divided without much communication behaves differently from work whose parts must fit together.
The extra chair adds more than another pair of hands. It adds a possible conversation with everyone already sitting there. Some of those conversations become necessary before anyone can finish.
Kelly Johnson treated that cost as something to contain. His Lockheed team designed and built the XP-80 in 143 days. One of his rules said the number of people connected with a project must be "restricted in an almost vicious manner".
The result doesn't prove that every smaller team wins. It does challenge the habit of counting the help while leaving out the coordination.
A hire can be needed and still create more work for the people already there. Both belong in the decision.
The telephone
Fewer people, though, won't help much if the message loses its meaning between them.
Suetonius describes Augustus placing young men at intervals along military roads to carry reports. He later changed the arrangement to use carriages, allowing the same courier to bring a dispatch from its origin.
That courier could answer questions on arrival.
The historian Anne Kolb explains what the relay lacked: the final messenger had no personal knowledge of the message's contents. He could deliver it, but couldn't explain the conditions behind it.
The final messenger lacked the knowledge behind the words he carried.
A handoff inside a company has the same risk. The person passing work on compresses what they know into what the next person needs. That compression can drop the detail that made the decision sensible.
A summary isn't careless just because it's shorter. It has to leave things out. The cost appears when the omitted detail becomes necessary and nobody receiving the work knows it existed.
Augustus's change kept someone available who could be questioned. The message arrived with a route back to its context.
That solves one problem with information. It doesn't solve the delay before it arrives.
The lag
Information can arrive intact and still arrive too late to guide the next decision.
In 1959, Milton Friedman warned the Joint Economic Committee that policies "operate with a long lag and with a lag that varies widely".
His concern wasn't simply that effects took time. The delay varied, making it hard to know when an action would take effect. In A Program for Monetary Stability, he reported leads of six to 29 months at business peaks, and four to 22 at troughs.
A company isn't an economy. But delayed feedback creates a similar difficulty: you can act again before learning what the last action did.
Fast software delivery can shorten that delay. In DORA's 2018 survey, elite performers reported deploying on demand, multiple times a day. Their time from committed code to production was under an hour.
By DORA's survey arithmetic, they deployed 46 times more often than low performers. They had 2,555 times faster lead times and seven times lower change failure rates. Those multiples came from normalized survey ranges, not measured averages.
The faster group wasn't buying speed by accepting more failure.
I think of this as the speed paradox. Short feedback loops let people find errors before more work depends on them. Slowing everything down for safety can postpone the knowledge that would make it safer.
But even a fast loop has to fit inside the structure that carries it.
The ceiling
Gothic builders faced a structural limit in stone. Taller walls needed more support. Making them thicker restricted the space available for windows.
The flying buttress carried the thrust outside the wall. Notre-Dame de Paris was among the earliest Gothic cathedrals to use it. Its nave rises 33 meters.
Moving the load let builders work within the stone's limits.
Companies face their own version of that ceiling. In 1968, Melvin Conway argued that organizations produce system designs that are "copies of the communication structures of these organizations".
How people have to communicate shapes what they can build. Asking them to work faster doesn't remove the dependencies between them.
That is why a new org chart can leave the old delays untouched. If decisions still follow the same route, the work still waits in the same places.
I think of that surviving arrangement as the structural zombie. The boxes changed. The dependencies stayed alive.
The ceiling is easy to mistake for a shortage of effort because effort is what people can see. The route that effort must follow is harder to notice.
When the fix adds to the cost
Put the four costs together and the usual response starts to look different.
Hire to go faster, and more people need to coordinate. Specialize their roles, and more work crosses boundaries. Add approval to catch what gets lost, and feedback takes longer.
Keep all of that inside the old structure, and the ceiling holds.
Each addition has a sensible local reason. The overloaded person needs help.
The specialist brings useful skill. The approval catches a real mistake.
None of those reasons tells you what the addition costs elsewhere.
This is the treadmill: hit a constraint, add something to compensate, create another constraint. The company keeps responding to the strain at the point where someone feels it.
The fix becomes another source of friction.
Relief still matters. During a live incident, stopping the damage is the right work. And sometimes capacity really is the constraint, with no upstream defect producing the shortage.
But relief needs a follow-up when the work keeps arriving broken. Who is changing the step that generates it? Will fewer people need to stay synchronized afterward?
Without that change, the burden has moved rather than disappeared.
Fixing one link can also load another. Faster production can overwhelm review.
Better summaries can leave the handoffs intact. Smaller teams can still depend on the same central approval.
The useful test is what happens to the whole route, not just the busiest point on it.
The customer gets the whole route
Who pays for those internal costs?
The customer does, even when every department can show that its own work is complete.
Jakob Nielsen warned about websites mirroring organization charts in 1997: "Users should not have to care how your company is organized".
Nigel Bevan made the same distinction. A site's structure can reflect the organization's internal concerns rather than the user's needs.
A message can suffer the same inversion of empathy. It is built for the room where it was written, rather than the person who has to use it.
That website is one visible result. The same test applies to every product the customer touches. They meet the communication structure as the product, and the feedback delay as waiting.
I've been on the other side of that gap. Early in my career, I ran the same SEO for two clients and got the same rankings.
One grew. The other saw no return it could trace.
The channel report was right both times. It couldn't account for how the rest of each business affected the result.
That's why I follow the problem past the channel that produced it. A department boundary can mark where one team's part ended. It doesn't change what the customer got.
The chair that costs almost nothing
I expect AI agents to make this harder to see. Adding another agent can look cheaper than asking whether the work needs another handoff.
In research first posted in December 2025, Yubin Kim and colleagues found that multi-agent results depended heavily on the task. Setups lost 39 to 70 percent on sequential planning tasks, while gains reached about 81 percent on parallel financial reasoning.
Kim and Xin Liu described the sequential failures this way: "the overhead of communication fragmented the reasoning process".
Independent agents amplified errors 17.2 times, compared with 4.4 times under a central coordinator. I read those results as a reason to examine the connections before counting the agents.
I expect the same loss of context at handoffs to matter when tools cross company boundaries. A cheap addition still needs the information required to do useful work.
DORA's workplace surveys give me another reason to watch the downstream result. In 2024, each 25 percent rise in AI adoption was associated with an estimated 1.5 percent drop in delivery throughput. It was also associated with a 7.2 percent drop in stability.
Those were survey-model associations, not proof that AI caused either decline.
The 2025 findings changed part of the picture. Adoption was now associated with higher throughput, while instability still rose. DORA described AI's role as amplification.
My expectation is that agents added to an unchanged structure will raise output and breakage together. A hire can add capacity and coordination at once, too. I don't expect more output alone to tell me whether the system improved.
I'd be wrong if DORA's next data showed teams adopting agents without changing team shape, batch size or handoffs, while stability rose alongside throughput.
That would give me a reason to revise the expectation. Until then, I would check what reaches the customer, not just how much the tools produce.
Large doesn't have to mean slow
Good people, a strong culture and better tools can reduce these costs. Async communication can make each connection cheaper. Skill can prevent confusion before it spreads.
Netflix was running thousands of deployments a day by 2018. By 2021, it reported more than 20,000 daily deployments.
Size clearly doesn't make speed impossible. Nor does the number of possible connections tell you how many connections the work actually requires.
That is where structure matters. Amazon's two-pizza rule keeps teams small, but size is only part of it. Those teams have ownership of a specific product or service.
The aim is to let useful work finish without requiring the whole company to agree.
Copying the visible arrangement is no guarantee. Former Spotify product manager Jeremiah Lee said its famous squad model "was only ever aspirational and never fully implemented".
A team name doesn't establish independence. A smaller box on the chart doesn't remove an approval.
Culture and talent matter to how well people work within those boundaries. They don't make the boundaries free to cross. The question is whether the work still requires them to cross as often.
Small where the work happens
At Buurtzorg, small teams run home nursing.
Jos de Blok founded the Dutch home-nursing organization in 2006. He had worked as both a district nurse and a manager inside a system that split care into timed tasks.
Buurtzorg gave small nursing teams responsibility for care in their neighborhoods. Teams have at most 12 members and split when they grow. Coaches help without holding authority over them.
A back office of about 50 supports more than 14,000 staff.
The extra chair is contained by the team-size limit.
The telephone is shortened because one team owns the patient's care.
The lag is shortened because the nurses doing the work see its result.
The ceiling changes because those teams don't wait on a middle-management layer to direct their care.
Fewer hours of home care didn't tell the whole cost story. KPMG's 2015 study, using 2013 data, found 108 hours of home care per client per year, against 168 elsewhere. Patient satisfaction was among the highest.
But total cost per client was about average once follow-up care was included. Quality was measured through patient surveys, not clinical outcomes.
That makes Buurtzorg useful without making it a miracle. It changed who held the context and who could act on it.
You can begin closer to home by listening to where the frustration sits.
We were faster when we were smaller points toward coordination.
It got lost in translation points toward the handoff.
We don't know what's happening points toward feedback.
The system won't let us points toward the ceiling.
Each calls for a different change. None tells you, by itself, to add more.
You may not need the company to be smaller again. You may need less of it involved in each decision.
Growth doesn't require every task to grow with you.
I keep writing down where the work slows, as I find it.