I lived through this at a growth start-up where the engineering team tripled in under two years. At fifteen people, we were fast, aligned, and effective. Everyone knew what everyone else was working on. Decisions happened in hallway conversations. The culture was strong because it was small enough to be transmitted through proximity.

At forty-five people, almost none of that was true. Communication had broken down. New hires didn’t understand the culture because nobody had time to transmit it. Decisions that used to take minutes now took weeks because the number of stakeholders had multiplied. We were bigger, but we weren’t better, and for a painful period, we were actively worse.

Scaling an engineering team isn’t just about adding people. It’s about changing the structures, processes, and communication patterns to accommodate growth without losing the effectiveness that made growth possible in the first place.

What Breaks

Communication overhead. As teams grow, the number of communication links increases exponentially. A team of five has ten links. A team of ten has forty-five. A team of twenty has one hundred and ninety. At some point, the overhead of keeping everyone informed exceeds the capacity to do so informally. This is why Amazon’s two-pizza rule exists, teams should be small enough that two pizzas can feed them. Beyond that size, you need to split.

Knowledge fragmentation. In a small team, everyone has a reasonable understanding of the whole system. As the team grows and specialises, knowledge becomes siloed. Osmani describes this happening at Chrome, as the codebase grew in complexity, pockets of specialised knowledge developed, creating bottlenecks around the few engineers who understood particular components.

Cultural dilution. Culture is transmitted through interaction. When the team is small, new hires absorb the culture through daily contact with people who embody it. When the team is large, new hires may spend most of their time with other new hires, and the culture they absorb is whatever emerges from that group rather than what was intentionally built.

Decision-making slowdown. Decisions that used to be made by one person now require input from multiple teams. Coordination costs increase. The bias shifts from “move fast” to “make sure everyone’s aligned,” which sounds responsible but often means nothing moves at all.

Structural Changes That Help

Conway’s Law is your friend. Conway’s Law states that organisations design systems that mirror their communication structures. Rather than fighting this, use it. Structure your teams around the systems you want to build. Cross-functional teams that own end-to-end slices of the product tend to work better than functional teams that own horizontal layers, because they reduce the coordination required between teams.

Shift from relay team to basketball team. Kambil uses this metaphor effectively. A relay team passes work sequentially, design to engineering to QA to ops. A basketball team works together simultaneously, with each member contributing their skills in real time. As you scale, you want teams that operate like basketball teams internally, even if the organisation as a whole has relay-like handoffs between teams.

Invest in written communication. What used to happen in hallway conversations needs to happen in documents, RFCs, and shared channels. This feels slower at first, but it scales in a way that verbal communication doesn’t. A document can be read by fifty people. A hallway conversation can’t.

Create explicit coordination mechanisms. Weekly cross-team syncs, shared planning documents, architecture review forums, these feel like overhead when you’re small, but they become essential as you grow. The key is to keep them lightweight and focused. A thirty-minute weekly sync between team leads is far more efficient than ad-hoc coordination across dozens of individuals.

The Leadership Shift

The leadership skills that work at one scale don’t automatically work at the next. Osmani describes this progression: as your domain grows, leadership becomes more about people and less about technical expertise. Your domain broadens, distractions multiply, and the temptation to stay in the weeds increases precisely as the need to step back grows.

At fifteen people, I could be involved in every significant technical decision. At forty-five, I couldn’t, and trying to be was actively harmful. The shift from “I make the decisions” to “I create the conditions for good decisions to be made” is one of the hardest transitions in scaling, and it happens gradually enough that you might not notice you’re behind until the bottleneck is severe.

The leaders who scale well are the ones who invest in their team’s decision-making capability rather than trying to scale their own involvement. That means hiring well, developing people, creating clear frameworks for how decisions should be made, and then trusting the system you’ve built.

Preserving What Matters

Not everything from the small-team era should be preserved. Some things, like the ability to make decisions without consulting anyone, are features of small scale that don’t survive growth, and trying to preserve them creates dysfunction.

But some things are worth fighting for: psychological safety, a culture of honest feedback, a bias toward shipping, and a genuine care for the people on the team. These don’t scale automatically, they require deliberate effort to maintain as the team grows. That effort is worth it, because these are the things that made the team effective in the first place.

The goal of scaling isn’t to become a bigger version of what you were. It’s to become something new that retains the values of what you were while developing the structures needed for the size you’ve become. That’s a harder problem than just adding headcount, and it’s the problem that separates organisations that grow successfully from ones that grow and break.