Team Topologies · thehardparts.dev
Skip to main content<br>Severity if wronghigh<br>Frequencycommon<br>Audiencesengineering leaders · engineering managers · platform leads · staff engineers<br>Reversibilityhard<br>Confidencehigh<br>At a glanceTD-43<br>Really aboutHow work moves through teams, where expertise sits, and who owns outcomes end to end.<br>Not actually aboutWhether one named topology pattern is fashionable or universally correct.<br>Why it feels hardTeam shapes solve one coordination problem while creating another, and org design often lags behind the work's real flow.
Usually a flow, ownership, and cognitive-load decision, not a reporting-line preference.<br>Heuristic<br>Choose the topology that minimizes handoffs for the dominant flow of work while keeping ownership and support paths explicit.
Default stance<br>Where to start before any evidence arrives.<br>Prefer stream-aligned ownership for outcomes, with explicit enabling or platform support where cognitive load or repeated demand justifies it.
Best when<br>Conditions where this option is a natural fit.<br>a team can own an outcome end to end<br>domain context matters deeply<br>handoffs slow delivery<br>platform and specialist support can enable rather than own the flow
Real-world fits<br>Concrete environments where this option has worked.<br>product squads owning a customer workflow<br>business capability teams with clear domains<br>service teams with direct operational accountability
Strengths<br>What this option does well on its own terms.<br>clearer outcome ownership<br>lower handoff cost<br>faster domain learning<br>better alignment between product and engineering work
Costs<br>What you accept up front to get those strengths.<br>teams may duplicate specialist work<br>local optimization can appear<br>cognitive load can become too high
Hidden costs<br>Costs that surface later than expected — the main thing novices miss.<br>platform needs can be underfunded<br>standards can diverge without light governance
Failure modes when misused<br>How this option breaks when applied to the wrong context.<br>local-optimization<br>ownership-drift
Best when<br>Conditions where this option is a natural fit.<br>expertise is scarce and high leverage<br>shared capabilities need consistency<br>stream teams cannot carry the cognitive load alone<br>enablement can reduce friction without owning the outcome
Real-world fits<br>Concrete environments where this option has worked.<br>security enablement<br>platform infrastructure<br>specialized data or AI expertise used across product teams
Strengths<br>What this option does well on its own terms.<br>concentrates scarce expertise<br>supports standardization<br>can reduce repeated local effort<br>helps stream teams learn
Costs<br>What you accept up front to get those strengths.<br>creates handoffs<br>can blur outcome ownership<br>may become a bottleneck
Hidden costs<br>Costs that surface later than expected — the main thing novices miss.<br>enabling teams can quietly become approval teams<br>platform teams can optimize output instead of adoption
Failure modes when misused<br>How this option breaks when applied to the wrong context.<br>dependency-fog<br>platform-before-product<br>hero-trap
Option A · Stream-aligned ownership<br>Who absorbs the cost<br>Stream-aligned teams<br>Engineering managers<br>Local technical leads
Option B · Specialist, platform, or enabling teams<br>Who absorbs the cost<br>Platform or enabling teams<br>Consumer teams<br>Coordination owners
Option A · Stream-aligned ownership<br>Wins when the organization optimizes for product flow and clear outcome ownership.
Option B · Specialist, platform, or enabling teams<br>Wins when scarce expertise or shared capability creates leverage that outweighs handoff cost.
What undoing costs<br>Hard
What should force a re-look<br>Trigger conditions that mean the answer may have changed.<br>Handoffs dominate delivery time<br>Teams cannot own outcomes end to end<br>Specialist bottlenecks appear<br>Platform work has unclear consumers<br>Team cognitive load becomes unsustainable
Questions to ask<br>Open these in the room. Answering them is most of the decision.<br>Which team owns the end-to-end outcome?<br>Where do handoffs dominate delivery time?<br>Which expertise is scarce enough to centralize?<br>What support should be enabling rather than approving?<br>What work is currently falling between teams?
Key factors<br>The variables that actually move the answer.<br>Dominant work flow<br>Handoff cost<br>Cognitive load<br>Scarcity of expertise<br>Ownership clarity<br>Platform leverage
Evidence needed<br>What to gather before committing. Not after.<br>Delivery handoff map<br>Incident routing map<br>Dependency map<br>Team cognitive load assessment<br>Platform adoption evidence
Common bad reasons<br>Reasoning that feels convincing in the moment but doesn't hold up.<br>Copying another company's topology<br>Moving people without changing ownership<br>Centralizing expertise because it is easier to manage<br>Calling a team platform because it sounds strategic
Anti-patterns<br>Shapes of reasoning to recognize and set aside.<br>Stream teams accountable for outcomes they cannot change<br>Platform teams measured by shipped features instead of adoption<br>Specialist teams...