Engineering Leadership · Chapter 4 of 9
Organisational design
The highest-leverage thing a director does, and the one that shows up as a delivery problem rather than a design one.
When delivery is slow and every team reports being busy, the cause is usually not capacity. It is that the boundaries between teams do not match the boundaries in the system.
The diagnostic
- What fraction of work items have a cross-team dependency, and how long do they wait? This single measurement usually settles the argument.
- Can a team ship to production without another team's calendar? If not, they are not really a team, they are a stage.
- How many teams touch your highest-value flow? If it is more than two, that is your reorganisation.
- Where is unplanned work landing? Concentrated operational load usually means one team owns something everybody depends on and nobody funded.
What good boundaries look like
The useful vocabulary here is Team Topologies: stream-aligned teams that own a slice of value end to end, a platform team that provides a paved road they consume without filing tickets, enabling teams that embed temporarily to build capability and then leave, and complicated-subsystem teams for the genuinely hard shared components. The failure mode is a platform team that behaves like an enabling team — permanently embedded, doing other teams' work, and never building the road.
Reorganise sparingly, and say what you expect to change
Every reorganisation costs roughly a quarter of productivity and a quantity of trust, so it needs to buy more than it costs. State in advance what should improve and by when — usually cross-team dependency wait time — so you can tell afterwards whether it worked.
A leader who has reorganised three times in two years is not iterating; they are searching, and the team knows it.
The one law of organisational design
A system's architecture tends to mirror the communication structure of the organisation that builds it. That observation is sixty years old, it is the most reliably true thing in this area, and it has a practical consequence most people miss: you can use it deliberately.
If you want three loosely-coupled services, three teams that rarely need to talk will produce them. If you want one coherent system, splitting it across four teams in three time zones will not give you one — it will give you four systems with an integration problem. Choosing the team boundaries is choosing the architecture, whether or not anyone says so.
Where to cut
| Boundary | Works when | Fails when |
|---|---|---|
| By product area | Each area has real users and its own roadmap | Areas share a data model — every change becomes a negotiation |
| By layer (frontend / backend / data) | The layers genuinely have different skills and cadences | Usually. Every user-facing change now needs three teams to agree, which is the slowest possible structure for the most common kind of work |
| By platform vs product | The platform has genuine internal customers and a product mindset | The platform is a dumping ground for work nobody wanted, in which case it becomes a queue |
| By customer segment | Segments have genuinely different needs | They don't, and you have built the same thing several times |
The most common mistake is cutting by layer and then being surprised that delivery is slow. It is the structure that maximises cross-team coordination for the most frequent kind of change, and it usually happens because it matches how people were hired rather than how work flows.
Autonomy is not free, and the bill arrives later
“Every responsibility a team cedes to increase its focus becomes a new cross-team dependency.” That line comes from a well-known post-mortem of a famous autonomy-first organisation, and it is the sentence to keep.
Giving a team a narrower remit genuinely does make it faster at its own work. It also converts the coordination that used to happen inside the team into coordination that now has to happen between teams — where it is slower, more political, and owned by nobody by default.
Coordination cost is conserved. You can pay it inside a team through hierarchy and shared context, or across teams through dependencies and negotiation. No structure removes it; every structure relocates it.
So the question about any proposed reorganisation is not ‘does this increase autonomy’. It is “where does this move the coordination cost, and who owns it once it moves?”
In the organisation that inspired the line, the answer to the second half turned out to be nobody — every team had its own way of working, so every collaboration needed its own way of engaging, and productivity across the organisation suffered even as individual teams felt fast.
A practical rule for reorganisations: state, in advance and in writing, what you expect to get faster and what you expect to get slower. Every structure trades one for the other. A reorganisation announced with only benefits is one where the costs will arrive unowned, and where nobody will be able to tell afterwards whether it worked.
Check yourself