Keeping speed at scale

Slowness at scale is not a law of nature.

It's an outcome of coordination cost, and coordination cost is a design variable.

The arithmetic is unforgiving, though.

Communication paths grow as the square of the number of people, so an organisation four times the size has sixteen times the potential coordination sitting inside it, and unless you actively reduce how much of that potential gets realised you will spend your entire growth on talking to each other.

Everything that keeps a large org fast is a mechanism for reducing the number of conversations required to get something done.

Where the cost actually comes from

Four sources.

Worth separating, because the fixes are different.

Work that crosses teams.

Every hand-off is a queue plus a negotiation, and a piece of work touching three teams is subject to three sets of priorities. Largest single source, and it's an org design problem, which is exactly why Conway's law is a practical tool rather than an observation.

Decisions that need multiple people. Covered in its own lesson, and the effect at scale is that the elapsed time between "raised" and "decided" grows without anyone deciding it should.

Shared resources. One environment, one release train, one team owning the thing everyone needs.

Every shared resource is a queue, and queue time rises sharply as it approaches capacity.

Approval.

The accumulated process debt of a growing company, each item added after an incident and none of them ever removed.

Notice that only one of the four is about people being busy.

Adding headcount does nothing for the other three. It makes the first two slightly worse.

Independent deployability as an organisational property

The single most useful capability a large engineering org can have.

A team takes something from idea to production without needing another team to act.

That's a statement about the organisation more than about the architecture.

It requires the team to own its own systems, deploy on its own schedule, have the platform capabilities it needs available without asking for them, and be allowed to make the decisions that sit inside its own scope.

Where it breaks is usually one specific dependency, and it's worth finding rather than reasoning about in general.

Trace five recent pieces of work. Note every point where a team had to wait for somebody outside it.

You'll get a short list, it'll be the same two or three things over and over, and those are worth real investment.

Typically a shared environment. A single team owning a piece of infrastructure everyone needs. An approval step.

All three fixable. All three usually treated as facts of life.

The platform layer is what buys speed back

If I had to name the one investment that most preserves speed at scale, it's a good platform layer.

The reasoning is direct.

Most cross-team dependencies are requests for capability rather than for collaboration. I need a database. A queue. A deploy pipeline, monitoring, a way to run this job.

Each of those, if it requires a conversation with another team, is a queue. Each of them, if it's self-service on a paved road, is five minutes.

So the platform's real job isn't efficiency through centralisation. It's removing conversations from the critical path.

That framing also tells you what to build first. Whatever teams currently have to ask another team for.

The failure mode is serious. A platform team that becomes a gatekeeper rather than an enabler.

Now you've converted a distributed cost into a single centralised queue, which is worse than what you started with, because everything waits on one team's priorities instead of on several teams' in parallel.

Self-service isn't a nice property of a platform. It's the entire point.

Autonomy needs alignment or it's just fragmentation

Autonomy without alignment produces ten teams optimising locally and a product that doesn't cohere.

The mechanisms that let both exist are boring, and they have to be maintained.

A written strategy people actually read. Short enough to be read, updated when reality changes.

Every team should be able to say how their work connects to it.

Clear interfaces between teams, technical and organisational, so that autonomy inside a boundary doesn't leak across it.

A small number of genuine standards, embedded in tooling rather than in documents.

Standards that live in a wiki drift. Standards that live in the service template hold.

And enough visibility that teams can see what other teams are doing without asking, which prevents the most common form of duplicated effort.

What alignment shouldn't require.

A central planning process. A review board. A weekly meeting where every team reports upward.

The permanent fight against creeping approval

Approval accumulates continuously, and it does so in exactly the way that makes it hard to argue with, because every single addition is a reasonable response to a real event that actually happened to somebody.

Two structural defences.

Risk classification, so the routine majority of changes never touch a process built for the dangerous minority.

Most changes are low risk. Treating all of them as though they carry the risk of the worst one is what makes a pipeline slow, and it's also what teaches people to stop distinguishing between them at all.

And the annual deletion pass, described in the process-debt lesson: every rule names the failure it prevents and when that failure last happened, and anything that can't is removed.

What makes both work is that somebody senior has to own it.

Nobody's job is removing process. Nobody gets credit for it. And every removal carries a small personal risk.

So it has to be scheduled, and it has to be done by somebody who can absorb that risk.

What to measure

Lead time from decision to customer, at the whole-organisation level, tracked over years rather than months.

It's the only number capturing all four sources of coordination cost at once, because it includes every queue, every hand-off and every approval along the way.

Flat while headcount doubles means you've done something genuinely difficult. Rising means adding people is making things worse, and you want to know that before you plan next year's hiring.