Why your team is getting slower as it grows

There's a specific frustration that CEOs and engineering leaders experience as their company grows. At ten people, the team was fast. Ideas became features within days. Decisions happened in a conversation. Everyone knew what was happening and why. The company felt like a small boat that could turn on a dime.

At forty people, the same company feels like it's moving through treacle. Every decision requires a meeting, every meeting requires a pre-meeting, and every feature requires a planning phase that takes longer than the building would have taken a year ago. You've hired good people and given them good tools, and somehow the output per person has dropped rather than increased.

The natural explanation is that you've made a hiring mistake, or that the team has a culture problem, or that the new people aren't as good as the original ones. These explanations are usually wrong. The actual cause is mathematical, and it was described by Fred Brooks in 1975.

The communication path explosion

The number of one-to-one communication paths in a team grows with the formula n(n-1)/2. At 10 people: 45 paths. At 20: 190. At 40: 780. At 100: 4,950.

Knowledge that needs to travel through these paths to reach everyone who needs it simply can't, because the network is too large to carry that volume of information through person-to-person transfer. So gaps form. Teams don't know what other teams are doing. Decisions made in one part of the organisation don't reach the parts that are affected by them. Context that was once shared through proximity now requires explicit effort to distribute.

The team's response to these gaps is usually more coordination: more meetings, more Slack channels, more status updates, more alignment sessions. Each of these helps locally (the people in the meeting are aligned) while making the global problem worse (the meeting consumed time that could have been spent building, and the alignment is only available to attendees).

This is why meetings multiply as teams grow: they're compensating for a knowledge distribution system that no longer works. And it's why adding more people often makes things slower rather than faster: each new person adds more communication paths to an already overloaded network.

The three symptoms

The slowdown manifests in three specific ways, each of which is often misdiagnosed.

Decisions take forever. What looks like indecisiveness is usually missing context. The decision-maker doesn't have the information they need, so they call a meeting to gather it, which requires scheduling across multiple calendars, which takes days. The decision that could have been made in five minutes if the context were documented takes two weeks because the context has to be reconstructed from people's heads. The fix is documented decision history and readily available system context, not faster meetings.

Work gets duplicated. What looks like poor coordination is usually invisible existing work. Team A starts building something that Team B already built, because Team A didn't know Team B's work existed. This happens because the knowledge is scattered across tools that don't connect. The fix is searchable, unified knowledge across teams, not more cross-team syncs.

Onboarding is painfully slow. What looks like a hiring quality problem is usually a documentation problem. New hires take months to ramp because there's nothing comprehensive for them to read, so they have to reconstruct the organisation's context through conversations. The fix is documentation that new hires can consume on their own, not more buddy programmes.

The structural fix

The pattern across all three symptoms is the same: knowledge that should be documented and searchable is instead locked in people's heads and Slack threads, which forces the team to use synchronous communication (meetings, DMs, shoulder-taps) to transfer context that should be available on demand.

The structural fix is a knowledge layer that captures and maintains the organisation's context automatically, making it searchable by anyone without requiring the knowledge holder to be present.

Self-writing documentation built from the team's existing activity, Slack conversations, GitHub PRs, meeting recordings, creates this layer without requiring anyone to do additional work. The knowledge that's currently shared through ephemeral channels persists, becomes searchable, and is available to anyone who needs it, at any time, without interrupting anyone else.

The teams that make this investment before the slowdown becomes acute maintain their velocity through growth in a way that teams relying on person-to-person knowledge transfer cannot. The knowledge scaling problem is real and mathematical, but it's also solvable, and the solution is infrastructure rather than culture.

Frequently asked questions

Is this just a documentation problem? It's a knowledge infrastructure problem, of which documentation is the most visible component. It also includes searchability (can people find what exists?), currency (is the documentation current?), and discoverability (do people know the docs exist?). Self-writing documentation addresses all four because it generates, maintains, and makes searchable the knowledge that's already being shared through daily work.

We've tried documentation initiatives before and they didn't stick. Most documentation initiatives fail because they add work on top of existing work. Engineers are told to write docs in addition to shipping code, and the additional work gets deprioritised under deadline pressure. The approach that sticks is one where documentation is generated from the work itself rather than created as a separate activity.

At what point should we be worried? If your team has grown past 15 people and you're noticing any of the three symptoms (slow decisions, duplicated work, painful onboarding), the communication architecture is already straining. The investments are cheapest to make now and most expensive to make once the symptoms are severe.

Related reading: The knowledge scaling problem, How to scale an engineering team, Brooks' Law is still right, The coordination tax. Related pages: Self-writing docs, Find anything, One search.