Lakshya

Engineering Leadership · Chapter 4 of 8

Organisational design

The highest-leverage thing a director does, and the one that shows up as a delivery problem rather than a design one.

3 min read1 diagramAll 8 chapters

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 SAME FEATURE, TWO ORG DESIGNS boundaries cut across the architecture frontendAPIservicesdataplatform one feature crosses all five every change needs five calendars to align — the constraint is coordination, not capacity boundaries follow the architecture checkoutown it end to endcatalogueown it end to endidentityown it end to endplatformserves the other three most features land inside one team — the constraint moves back to capacity, where you can buy it If delivery is slow and every team looks busy, this is the first thing to check.
If team boundaries cut across the architecture, every feature needs several calendars to align and coordination becomes the constraint. When they follow it, most features land inside one team and the constraint moves back to capacity — which you can actually buy.

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.

← Growing people, and managing someone outRunning a distributed and GCC organisation →