How does organising ten teams by component rather than by feature change the dependency load?

## Two ways to draw the boundary When you split people into teams you must choose what a team owns, and there are two shapes. A **component team** owns a piece of the architecture: the routing engine, the data platform, the mobile client, the payments service. Membership follows the technology. A **feature team** owns customer-facing items: a group that can take "let a customer move a booking to a different date" from idea to production, changing whatever code that requires. The choice looks like an org-design detail. It is actually the biggest single lever on how much coordination the whole group will need for the rest of its life, because **dependencies form exactly where a change crosses a team boundary**. ## Why the component split generates dependencies Real work is described in the customer's language, not the architecture's. "Let a customer move a booking to a different date" touches a data model, a service, a client and probably a notification path. If those four things are owned by four teams, this one item now needs four teams to schedule it, four backlogs to accept it, four sets of estimates, and a sequence, because the client cannot finish before the service exposes the change. That is not a failure of goodwill or of process. It is arithmetic: **split by architecture, and every item that spans architecture spans teams.** The coordination machinery a scaling framework adds is then spent managing dependencies the topology itself created. An end-to-end team makes the same item one team's work. The parts still have to be built in order, but the ordering happens inside one team's plan, over hours, without a hand-off. ## What it costs End-to-end teams are not free, and a candidate who cannot name the costs has not run one. - **Breadth of skill.** A team must work competently in several areas. That takes deliberate pairing, learning time, and hiring for range as well as depth. - **Shared code ownership.** Areas that had one guardian now have many contributors. Without strong automated tests, review by people who know the area, and clear conventions, quality drifts and nobody notices until late. - **Loss of deep specialisation.** Some things genuinely need depth — a scheduling optimiser, a compliance-critical ledger, a hardware abstraction. Spreading those thin is a real loss, not an imagined one. - **Transition cost.** The change is disruptive: people leave familiar codebases, informal knowledge maps go stale, and delivery dips before it improves. | | Component team | Feature team | |---|---|---| | Owns | A slice of the architecture | Customer-facing items end to end | | Typical item | Crosses several teams | Stays inside one team | | Dependencies | Created by construction | Created only by genuine specialisation | | Skills | Deep and narrow | Broad, with pockets of depth | | Code ownership | One guardian per area | Many contributors, shared standards | | Best when | Interface is stable, expertise is deep | Product work spans several areas | ## The honest answer is usually mixed Almost nobody runs pure feature teams. The working pattern is end-to-end teams for product work plus a small number of deliberately kept specialist teams, chosen by two tests: **is the expertise genuinely deep**, and **is the interface stable enough that other teams consume it rather than change it?** A platform team whose interface changes with every product item is a dependency generator wearing a platform's name — the hand-off cost is being paid without the specialisation benefit. ## A worked example A coach-tour scheduling platform runs nine teams split by architecture: routing, pricing, inventory, mobile client, partner gateway, data platform and three more. A partner integration deadline lands — an operator's booking feed must go live on a fixed date. Tracing the committed scope over two 3-week iterations shows the shape: 1. Of 34 delivered items, 27 touched three or more teams. 2. Median elapsed time per item was 19 days, of which 13 were spent waiting on another team rather than being worked on. 3. The gateway team spent most of its capacity on small changes requested by others — work it had no product context for and could not order sensibly against its own. Nothing there is fixed by better coordination; a joint planning event would only schedule the same 13 days of waiting more visibly. The fix is topological: create one team that owns partner integration end to end, with the right to change the gateway, the inventory model and the client, and keep only the routing optimiser as a specialist team because its expertise is deep and its interface is stable. In the following measurement window the same nine teams deliver items that touch one or two teams, and the waiting share collapses. ## How to argue it in an interview - Lead with the mechanism — dependencies form where changes cross boundaries — not with a preference for one shape. - Quantify: teams touched per item, and waiting time per hand-off, are the two numbers that make the case. - Name the costs honestly, and name the components you would deliberately keep specialised and why. - Sequence the change between external commitments rather than across one, because delivery dips before it improves.