When your engineering process stops scaling

The inflection point

At eight engineers, the process is invisible because it barely needs to exist. You know what everyone is working on. Changes get communicated in standup or across the desk. The person who last touched the interface definition is sitting three metres away. Nobody has to think about coordination. It happens on its own.

Then you hire. And keep hiring. And at some point the same behaviours that made the small team work start costing you.

It is not a single moment. It is a slow accumulation of small failures.

A parameter changes. Three engineers who needed to know find out two weeks later, in a review. A new hire spends their first month asking around to understand which document is current, because nobody can give them a single answer. Two engineers work on the same interface from different assumptions and the conflict surfaces at integration. A decision made in a corridor conversation, never written down, becomes impossible to reconstruct six months later.

Each of these looks like a people problem. Someone did not communicate. Someone did not ask. Someone did not document.

They are not people problems. They are what happens when informal coordination hits its structural limit.

A team of eight has 28 potential communication links. A team of 25 has 300 (check Metcalfe's Law). You cannot maintain the same quality of informal coordination across 300 links that you had across 28. The process did not fail because the team got worse. It failed because it was never built to scale.

What it looks like from inside

Growing teams usually notice the symptoms before they understand the cause.

Reviews get longer. Not because the work got more complex, but because more time is spent reconstructing context: checking whether the document on screen matches the model, whether the numbers were updated after the last change, whether the decision made three weeks ago is still standing. The meeting that used to be a quick alignment becomes an archaeology session.

New hires take longer to become productive than expected. Not because they lack skill, but because the information they need is distributed across people's heads, email threads, and files named with dates that nobody is confident are correct.

And the people who have been there longest become load-bearing in ways that are hard to see. They are not just doing their job. They are also carrying the institutional memory that the process was never built to hold.

Why fast-growing teams miss it

Fast-growing companies are focused on building and shipping. The engineering process is not the thing anyone is optimising. It is the invisible infrastructure that the real work runs on, and like most infrastructure, nobody notices it until it breaks.

By the time the coordination failures become visible, the team is already deep into patterns that are hard to unwind. The spreadsheet that was fine for five engineers is now the most important document in the programme, and twelve people are editing it. The review deck that used to be a formality is now where engineering decisions actually get made. The informal network of who knows what has become so load-bearing that losing one person creates a genuine crisis.

The process scaled in the wrong direction. More people, more documents, more meetings, more overhead. Not more clarity.

The question worth asking now

Before the next hire: if you doubled the team tomorrow, which parts of your engineering process would break first?

Not the technical parts. The coordination parts. Where does information live right now that depends on a specific person knowing it? When something changes, how does everyone who needs to know find out? How long would it take a new engineer to understand the current state of the design from the data alone, without asking anyone?

The teams that scale engineering well are not the ones that move slowly or add process early. They are the ones that built the coordination infrastructure before they needed it, when the team was still small enough that it felt unnecessary.

That is the only time it is cheap to build.