§ CAPABILITY

Engineering Team Topology and Org Design

Team boundaries drawn around the system rather than around history. Who owns what, what each team can ship without waiting, and where the handoffs that cost you weeks are.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call How the work runs

What you're seeing

The same features keep needing three teams.
Usually means The boundaries do not match the way change arrives. Every ordinary feature has become a coordination problem, and the coordination cost is paid on all of them, invisibly.
A service has no owner, or four.
Usually means Both fail the same way — nobody is accountable for its health, and both a change and an incident start with a conversation about who should handle it.
A platform team was formed and product teams route around it.
Usually means The platform is harder to use than the alternative. A shared service that is not the easy path becomes a compliance obligation instead of a product, and it is measured by how often it is bypassed.
Headcount grew and the shipping rate did not.
Usually means The coordination overhead of the additional people has absorbed their output. This is a structural result rather than an effort one, and hiring further makes it worse.

Boundaries drawn around change

The test of a team boundary is whether the changes that happen most often stay inside it.

When they do, a feature is a piece of work. When they do not, every ordinary feature becomes a scheduling problem across two or three teams, each with their own priorities and their own quarter. The cost is paid on every change, and it is invisible in every report because it looks exactly like normal planning.

So the first artefact is a map: which team owns which service, which services have no owner, and which have several. Then a count, per team, of what they cannot ship without asking somebody else. That number is the thing being optimised, and most organisations have never seen it written down.

The platform has to be the easy path

A shared platform that is harder to use than going around it will be gone around.

This is the most common way a platform team fails, and it does not look like failure from inside — the platform exists, it is documented, and there is a policy requiring its use. What is actually happening is that product teams are meeting the requirement while routing their real work elsewhere, and the platform’s success metric has quietly become compliance rather than adoption.

The correction is to treat internal platforms as products with users who can leave. If adoption is falling, the platform is losing, and the answer is not a stronger policy.

Move ownership, not people

Most of the available benefit comes from naming owners and moving services between teams.

That is cheap, fast, and reversible within a week if it turns out wrong. Reporting-line changes are none of those things: they cost momentum, they cost some people who did not want a new manager, and they are extremely hard to undo. They are occasionally necessary. They should be the last instrument reached for, not the first.

The transition plan is sequenced for the same reason. A reorganisation delivered as a single event costs roughly a quarter of delivery while everyone renegotiates what they own.

Where it sits

This capability appears under four parents. It is part of Engineering Hiring, because you cannot write a role definition without knowing which team is being hired into and what it owns. It is part of Engineering Velocity when the delivery constraint turns out to be coordination rather than tooling. And it sits inside both Fractional CTO and Delivery Implementation, where structure is one of the first things a new technical leader is asked about.

Two neighbours. Career Ladders is what makes a structure survivable for the people inside it — a boundary with no progression path attached produces attrition. And Process Rebuild is the layer above: structure decides who talks to whom, process decides how.

How the work runs

  1. Map ownership as it stands

    Which team owns which service, which have no owner, and which have several — the last category is where the delays live.

  2. Trace the dependencies

    For each team, what it cannot ship without asking someone else. Cross-team handoffs are counted, because they are the cost being paid.

  3. Design the boundaries

    Teams drawn so the common changes are inside one of them, with the platform concerns separated from the product ones.

  4. Sequence the move

    Ownership transferred in steps, each leaving the organisation working. A reorganisation delivered as one event costs a quarter of delivery.

What arrives

  • An ownership map covering every service, including the orphans
  • A cross-team dependency count with the expensive handoffs named
  • A target structure with the reasoning for each boundary
  • A phased transition plan with delivery protected at each step

What it costs your team

Around a day and a half of leadership time, plus a short session with each team lead.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Boundaries are drawn around what changes together

    Costs It often cuts across the organisation's history, and history is what people are attached to.

    The test of a team boundary is whether the changes that happen most often stay inside it. Boundaries inherited from who joined when, or from a product line that no longer exists, fail that test and impose a handoff on every ordinary feature. The cost is real and invisible, because it looks like normal planning.

  • Ownership moves before reporting lines do

    Costs It produces a structure that looks untidy on an org chart for a while.

    Most of the available benefit comes from naming owners and moving services, and that is reversible within a week if it is wrong. Reporting-line changes cost morale, momentum and usually a departure, and they fix less than people expect. Reserve them for when nothing smaller works.

  • The transition is sequenced, never delivered as one event

    Costs It takes longer and the end state is not visible for a quarter.

    A reorganisation announced and executed at once costs roughly a quarter of delivery: everyone renegotiates what they own while continuing to be measured on shipping. Moving ownership in steps, each leaving the organisation working, spreads that cost to near zero and allows a step to be reversed if it was wrong.

Frequently Asked Questions

A way of describing engineering organisations by the kind of work each team does and how teams are allowed to interact — stream-aligned teams owning a slice of the product, platform teams serving them, and deliberately limited interaction modes between the two. The useful part is the constraint on interaction, not the vocabulary.
When the same features repeatedly need three teams, when ownership questions have no obvious answer, or when the count of things a team cannot ship without asking someone else is high. If none of those is present, the constraint is somewhere else and a reorganisation would be pure disruption.
No. Often it means moving two services and naming three owners, which takes a week. We would rather change ownership than change reporting lines — the second costs considerably more, is much harder to reverse, and frequently fixes less than expected.
It is the reason this work exists: systems come to resemble the communication structure of the organisation that built them. Which means a boundary drawn in the org chart will eventually appear in the code whether it was intended to or not, so it is worth drawing deliberately rather than inheriting.
Small enough that everyone can hold the same context, which in practice means somewhere between four and eight engineers. The number matters less than the property behind it: past a certain size a team stops having one conversation and starts having several, and the boundary has already formed informally.

Sources

Page reviewed