Organisational Design Above Team Topologies

The design of individual teams is, by now, reasonably well understood. Team Topologies gave the field a usable vocabulary — stream-aligned, platform, enabling, complicated-subsystem — and most delivery organisations can hold a competent conversation about whether a team is bounded around a value stream or a technology. That conversation is worth having.

It is also not where the expensive decisions are made. Above the teams sit divisions, functions, shared services, centres of excellence, regional structures and matrix reporting lines, and those boundaries determine more about throughput than any team-level arrangement can compensate for. A perfectly formed stream-aligned team inside a division that does not own its platform, its data, its security sign-off or its budget is a well-designed component in a badly designed system. It will produce excellent local flow metrics and deliver slowly, and everyone involved will be puzzled.

This is the layer executives actually control. Nobody above director level personally decides how a team of seven is composed, and nor should they. But whether to run a central platform function or embedded platform capability, whether security is a gate or an embedded capability, whether to organise by region or by product — those are executive decisions, made rarely, and they set the coordination cost for every subsequent quarter.

Every boundary is a queue

The single most useful frame for this layer: an organisational boundary is a place where work stops and waits.

Not always for long, and not always visibly. But wherever two groups have different reporting lines, different priorities, different planning cycles and different definitions of urgent, work crossing between them joins a queue. The receiving group prioritises against its own backlog, not yours; its capacity is committed; its planning cycle has a boundary you do not control. The wait is rarely zero and frequently measured in weeks.

This gives you an actual design criterion, which the discipline otherwise lacks. Draw boundaries where crossings are rare, not where the org chart looks tidy. A boundary crossed twice a year costs almost nothing. One crossed by every piece of work is a tax on everything, and its cost is the crossing frequency multiplied by the average wait — a number you can estimate and almost nobody does.

The arithmetic worsens faster than linearly as you scale, for the reasons in the dependency mathematics of scaling. The point for the executive layer is that coordination cost is not a property of how many people you have. It is a property of where you put the lines.

Frequency of crossing is the whole question. Before defending any boundary, count how many pieces of work crossed it last quarter. If the answer is essentially all of them, the boundary is wrong regardless of how sound the functional logic is.

Each boundary has a fixed coordination overhead. Planning alignment, dependency negotiation, interface agreements, escalation when the sides disagree. This is paid every cycle even when nothing goes wrong.

Boundaries compose badly. Work crossing three boundaries does not wait three times one boundary's delay. It waits for the worst case of three independent queues with three different cycle boundaries, and the variance compounds faster than the mean.

Priority conflicts escalate to the first common manager. The higher that manager sits, the more expensive every conflict is — the practical argument for putting interdependent functions under the same leader even when the functional logic says otherwise.

Conway's Law at organisational scale

Conway's observation is usually invoked about teams and modules. It applies at least as forcefully at the divisional layer, and the consequences last longer because divisional structures change less often.

Run three regional divisions and you will get three variants of the same system, because each builds what it needs and nothing forces convergence. Separate the team that builds a capability from the team that operates it and you will get an interface between building and operating, which will become a formal handover with documentation, tickets and a queue. Hold data centrally and product in the divisions and you will get products that treat data as an external service to be requested, because that is precisely what it is.

None of this is a failure of execution. It is the structure producing the architecture it describes, exactly as predicted.

The executive-level move is to read this backwards. Decide what system you need, then arrange the organisation to produce it. If you need a unified customer experience across regions, a regional divisional structure will fight you indefinitely and no amount of governance will win, because governance is a weak force and structure is a strong one. If you need three genuinely independent businesses, a shared platform organisation will be a permanent source of contention, because you have required coordination between units you told to be independent.

Architecture and organisation design are therefore the same decision made twice, and they should be made by people in the same room. In most companies they are made in different rooms, months apart, by people with different vocabularies, which is why the architecture never quite matches the structure and both are blamed.

Shared services, centres of excellence and the centralisation question

The recurring executive decision at this layer is whether a capability should be centralised, federated or embedded. Security, data, design, platform, quality, architecture — each of them gets this question, usually every few years, and usually with the answer oscillating.

The oscillation happens because both answers are correct about different things. Centralisation buys consistency, scale, deeper expertise and a single place to make a standard stick. Federation buys speed, context and ownership. Organisations centralise until the queues become intolerable, federate until the inconsistency becomes intolerable, then centralise again — each swing presented as a correction of the last one's failures rather than a predictable consequence of the trade-off.

There is a better framing than choosing a point on the spectrum. Ask what specifically needs to be central, and make only that central.

Model	Buys you	Costs you	Fits when
Central team that does the work	Deep expertise, consistency	A queue in front of every request	Demand is low-volume and specialised
Central team that owns a platform	Consistency plus self-service speed	Real product investment, ongoing	Demand is high-volume and repetitive
Centre of excellence that sets standards	Coherence without a queue	Weak enforcement, drift	The standard matters more than the implementation
Embedded specialists, central guild	Speed and context	Duplication, variable depth	The work is continuous within each stream
Fully federated	Maximum autonomy	Divergence, repeated learning	Units are genuinely independent businesses

The distinction in the first two rows matters most and is missed most often. A central team that performs the work is a queue by construction, and its queue grows with the organisation. A central team that builds a platform others use without asking is not a queue at all; it is leverage. The difference is not organisational — both are a central group with the same skills — it is whether the interface is a request or a self-service capability.

That converts most centralisation debates into a product question. Your security function can be a gate that reviews every change, or it can provide scanning, patterns, guardrails and defaults that make the secure path the easy path. Both are central. Only one constrains throughput, and choosing between them is an investment decision about whether you will fund the platform work.

Centres of excellence deserve a specific warning. The model — a small central group that sets standards and builds capability without doing the work — is sound in principle and degrades predictably in practice. A group with expertise and no delivery accountability drifts towards producing standards, reviews and frameworks, because those are the artefacts available to it. Within a year it has acquired a review gate, because standards without enforcement are ignored and enforcement requires a checkpoint. It is now a queue, and it got there by doing exactly what it was asked to do. The counter is to make it accountable for an outcome — adoption, or the cycle time of the thing it governs — rather than for producing standards.

Matrix management and the cost of two bosses

Matrix structures exist because organisations have two legitimate axes: what people work on, and what they are expert in. The matrix is an attempt to honour both without choosing.

It can work. It usually does not, for one reason: the matrix is drawn without deciding which axis wins when the two conflict. If a person's delivery lead and their functional lead disagree about what they should do this week, someone must resolve it without escalation. Unstated, it is resolved by whoever has more influence, in every instance separately, and the person in the middle absorbs the conflict as stress.

Three rules make a matrix survivable.

One axis owns the week. State which lead sets day-to-day priorities. The other has genuine but different rights — capability, standards, career development, assignment across streams — which do not include redirecting today's work.

Goals cascade down one axis only. If both axes set objectives, the person has two sets of goals that will conflict within a quarter. Objectives follow the delivery axis; the functional axis holds capability and quality expectations, which differ in kind.

The performance conversation is joint but owned by one. Split ownership produces either duplication or a gap, and the person being assessed can tell which.

A matrix following these rules is a structure with two kinds of relationship. One that does not is a permanent negotiation, conducted mostly by the least senior person present.

Why reorganisations destroy value

A reorganisation is the standard executive instrument for structural problems, and it has a poor record, for reasons that have nothing to do with whether the new structure is better than the old one.

The costs are largely independent of the design. Informal knowledge — who to ask, what has been tried, where the risk actually is — is destroyed and takes a year or more to rebuild. Every in-flight commitment is renegotiated. Every person spends weeks working out their position rather than doing their job. Domain knowledge dissipates as people move between areas. And the period between the announcement and the settling is one of near-total attention capture.

Against that, the benefit of a better structure accrues slowly and is hard to attribute. The honest accounting is a large, immediate, certain cost against a modest, delayed, uncertain benefit. Worth doing when the structural problem is severe and persistent. Not worth doing to correct a misalignment that a change in decision rights would fix.

Which points at the alternative. Most problems that appear to require a reorganisation are actually one of four things, each of which is cheaper to fix directly.

A decision-rights problem. Two groups both believe they own something, or nobody does. Fixing this takes a session and a published map, and it is covered in decision rights and who breaks a tie. It does not require anyone to change desk.

A funding problem. Teams cannot act on their own priorities because money is allocated to projects rather than to durable capability. Changing the funding model changes behaviour without changing a single reporting line, which is the argument in from project funding to product funding.

A dependency problem. One boundary generates most of the friction. Move the specific capability that crosses it, or give the boundary a self-service interface, rather than redesigning everything.

A measurement problem. Two groups are optimising for metrics that conflict. Change the measures. This is the cheapest intervention on the list and the least frequently attempted, because it lacks the visible decisiveness of a new org chart.

When structural change genuinely is needed, make it incremental and reversible. Move one boundary, let it settle for a quarter, observe. This is unsatisfying to announce and considerably more likely to work than a comprehensive redesign, because organisational structures have effects nobody predicts accurately and the only reliable way to find them is to make a small change and watch.

And design against the work, not the people. The common failure is a structure shaped around who is available, who would be upset, and who was promised a larger role. That is a real constraint and pretending otherwise is naive, but a structure built around personalities needs redesigning the moment any of them leaves — the origin of a great many two-yearly reorganisation cycles.

What to do on Monday

Take the last ten significant pieces of work your area delivered and, for each one, list every organisational boundary it had to cross — every group with a different reporting line that had to do something, approve something or agree something. Count the crossings. Then estimate, roughly, how long the work waited at each one.

One or two boundaries will account for most of the total wait. That is your structural finding, and it is more actionable than any org design exercise, because it names a specific interface rather than a shape. Ask one question about the worst one: can this become a self-service capability instead of a request queue. If the answer is yes, you have found a change that improves throughput without moving anybody, which is the best trade available at this layer.