← Back to Blog

When the Team Grows Faster Than the System

The investment closed. The hiring plan is in motion. New people are starting every week. And somewhere between the third and the tenth hire, a question surfaces that no pitch deck prepared you for: how does all of this actually work together?

What never needed explaining

A solo founder or a small founding team operates in a way that feels effortless — not because it’s simple, but because it’s been repeated so many times that it became invisible. How a feature goes from idea to release. How a client request becomes a decision. How quality gets maintained without anyone writing it down. The full lifecycle — from first contact to delivered product — runs on knowledge that was never made explicit, because there was never anyone to explain it to.

Researchers Nonaka and Takeuchi call this tacit knowledge — knowledge that exists in action, in judgment, in how things are done, but resists being put into words. In a founding team, this knowledge transfers naturally through proximity: you work side by side, you see how decisions are made, you absorb the patterns. The process formed itself through repetition in the startup phase, refined over hundreds of iterations. It works. (Nonaka & Takeuchi: The Knowledge-Creating Company)

Then the team goes from three to fifteen.

The management challenge

Fred Brooks observed in 1975 what every growing team discovers for itself: communication overhead doesn’t grow linearly with team size. It grows exponentially. Three people have three communication paths between them. Five have ten. Ten have forty-five. Fifteen have one hundred and five. (Fred Brooks: The Mythical Man-Month)

George Miller’s research showed that humans can hold roughly seven items in working memory at once — a limit that applies not just to information, but to the number of working relationships a team can sustain without structure. The Scrum Guide draws from this when it recommends teams of ten or fewer. Research on software teams found the optimum even lower: around five, with larger teams producing significantly more defects at several times the cost.

But the real shift isn’t about a number. It’s about what changes in how people work together. In a founding team, communication is ambient. You overhear a decision. You see a problem being solved. You absorb context without anyone having to transmit it. Every misunderstanding surfaces in minutes, because you’re sitting next to each other.

Past the threshold, that ambient channel breaks down. Every assumption that was shared through proximity now has to be stated explicitly. Every decision that happened in a glance across the desk now requires a meeting. And every misunderstanding — the kind that used to correct itself within hours — can now travel through days or weeks before anyone notices.

The cost of late visibility

This is where the real expense hides. Not in salaries, not in tools — in the distance between a misunderstanding and its discovery.

Consider what happens whenever two people collaborate. One communicates intent. The other interprets. They produce something based on that interpretation. The first reviews it and discovers a gap — not because the work was poor, but because something in the intent didn’t fully transfer. Feedback is given. The work is adjusted. The loop closes.

This is the fundamental loop of all collaborative work. And its cost depends almost entirely on its length. Barry Boehm’s research on the cost of change, validated across decades of software projects, shows that a misalignment caught during planning costs a fraction of what the same misalignment costs when discovered in production — sometimes a hundredfold less. (Examining the Cost of Change Curve)

In a founding team, this loop is short. You misunderstand, you discover it in hours, you correct. The cost is negligible. In a team of fifteen without structure, the same misunderstanding can travel through an entire development cycle — through design, implementation, testing — before surfacing. By then, the cost isn’t just the rework. It’s the cascading decisions that were built on the wrong assumption.

The question isn’t whether misunderstandings will happen. They always do. The question is: how quickly do they become visible?

Where this becomes practical

The frameworks exist — Scrum, Kanban, a dozen variations. The principles are well documented. But implementing them in your specific environment, with your team, your product, and the patterns you’ve already built — that’s a different challenge entirely.

This is where I work. I come into a growing organization and start by observing what’s already there. Not to judge, but to see. Because every company already has a system, even if it was never designed as one. The founders built it through years of repetition. Parts of it are excellent. Other parts are invisible load-bearing walls — and they only become visible when they crack under the weight of the growing team.

My approach starts with stability. I bring process into the team — tailored to where you actually are, not where a textbook says you should be. We make visible what’s causing friction: where decisions get stuck, where information gets lost, where the same misunderstandings keep recurring. Once the impacts are clear, we address them. Incrementally. Without breaking what already works.

From that stable base, the team develops the capacity that matters most: observing its own communication, its assumptions, its process. Talking about what they see. Deciding what to change. Acting on it. And learning from the outcome. Not as a one-time intervention, but as an ongoing capability the organization owns.

And if you’re earlier in the journey — team growing, investment secured, system not yet under pressure — that’s often the best time to start. Building the operating system alongside the team from the beginning costs a fraction of rebuilding it under strain.

Further reading

For those who want to go deeper into the concepts referenced in this article:

• Brooks’s Law — The Mythical Man-Month — Fred Brooks. Why adding people to a team increases communication overhead exponentially.
• Examining the Cost of Change Curve — Scott Ambler. How the cost of fixing misalignments grows with the distance from their origin.
• The Scrum Guide — Schwaber & Sutherland. The definitive framework for empirical product development.
• Nonaka’s SECI Model — How tacit knowledge becomes organizational knowledge through cycles of learning and working.