Optimizing teams: A dual perspective on Team Topologies
Elias Lieberich · article · 2024-09-26 source ↗ Reader 🖥️
Cognitive LoadCoordination CostHierarchy & Org ChartsSociotechnical ArchitectureTeam TopologiesValue Streams & Verticals
Team Topologies' four-type model is a useful starting vocabulary, but both authors argue that applying it well requires practical, product-aware judgment calls it doesn't itself supply — Lieberich's engineering-facing checklist (well-defined scope, disambiguated boundaries, minimal dependencies) and Wille's product-facing one (small teams, end-to-end ownership of a user journey, splitting by product/user-group/value-moment/funnel-stage rather than by technology) — because the book's own categories never fully resonated with a product-management, rather than engineering, view of where team boundaries should fall.
practical · mixed — Two linked essays (product coaches Elias Lieberich and Petra Wille, published together by Mind the Product) each arguing for how to apply/adapt the Team Topologies framework in practice — expository summary of the model followed by prescriptive, checklist-style advice. Treated as one document per the assigned slug/metadata; the second author's distinct voice is flagged throughout.
Structure
| Part | Role |
|---|---|
| Shared intro framing Team Topologies as one framework among possible interpretations, introducing two coaches' 'contrasting viewpoints' | context |
| Lieberich's section: what team topology is for, warning signs you need it, what 'good' looks like, a worked airline-booking-engine example, and five practical criteria for slicing teams | evidence/elaboration |
| Wille's section: why the book's categories don't resonate for a product-management lens, her own five rules, four recommended splitting dimensions, and three anti-patterns to avoid | evidence/elaboration (partial counter-perspective) |
| Shared conclusion: no one-size-fits-all; context-dependent, continuous re-evaluation | conclusion |
Key terms
- well-defined scope
Lieberich: a team's problem space should be narrow and intriguing enough that engineers can stay engaged with it for long periods, which he claims is the actual mechanism behind 10x-value teams — not org-chart position. - moments of value creation
Wille: end-to-end slices of a user journey (e.g., job-searching, bookmarking, applying) used as a splitting dimension once product- and user-group-based splits are exhausted — distinct from a technical fracture plane. - don't ship your org chart
Wille's anti-pattern label: designing product teams to mirror the existing organizational reporting structure rather than product/user needs, which she claims causes inefficiency and silos regardless of intent. - Team Topologies' four types (as critiqued, not merely summarized)
Both authors treat stream-aligned/enabling/complicated-subsystem/platform as a given vocabulary, but Wille explicitly states it 'never fully resonated' with her because it is framed from an engineering rather than product-management perspective.
Propositions
- explicitTeams with a well-designed topology deliver roughly an order of magnitude ('10x') more value than otherwise-comparable teams, regardless of their formal reporting lines.conf: low
- explicitReorganizing how teams work together is costly, so a team topology should only be changed when there is clear evidence the current structure isn't working (e.g. huge steering-group decisions, engineering as a detached black box, product managers needing to request engineering resources, low motivation/high churn).conf: high
- explicitA team's sustained engagement and resulting productivity depend more on having a narrow, intriguing, well-bounded problem space than on org-chart position or reporting structure.conf: medium
- explicitSplitting teams by product line (e.g. 'Team Pants') or by abstract business goal (e.g. 'Retention team') without a genuinely bounded, solvable problem produces teams that must touch the whole system and fight each other for shared resources (e.g. UI real estate).conf: medium
- explicitTeam Topologies' four-type taxonomy, because it is framed from an engineering perspective, does not fully resonate as a tool for product-management-led team design.conf: highextendsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p23 — Wille's statement that the book's taxonomy 'never fully resonated' from a product-management angle is a practitioner-side confirmation of the gap flagged in extract-team-topologies — that the team (vs. the value stream) is implicitly treated as the correct atomic unit, which reads differently depending on whether you enter from engineering or product.
- explicitTeams should be kept small — ideally no more than eight to ten people — and claims of needing more (e.g. regulatory compliance) should be challenged rather than accepted as a structural excuse.conf: highsupportsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p13 — Wille's hard '8-10 person' team-size ceiling independently converges with Team Topologies' Dunbar's-number-grounded argument that team size/architecture must respect limits on stable human-group interaction.
- explicitA product team should have end-to-end responsibility for a complete piece of the user journey (e.g. acquisition through onboarding) rather than a horizontal technical slice, to promote accountability and avoid silos.conf: highextendsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p12 — Wille's 'end-to-end responsibility for a part of the user journey' is a product-first version of Team Topologies' fracture-plane principle (boundaries chosen to match what a team can hold at acceptable cognitive load) — reframed around user-journey slices rather than technical/cognitive-load boundaries.
- explicitTeams should minimize dependence on other teams for discovery, delivery, and release, because frequent mutual blocking is itself a signal the structure needs reassessment.conf: highsupportsDevOps Topologies · p3 — Wille's 'minimize dependencies on other teams for discovery, delivery, and release' echoes DevOps Topologies' observation that the number of products/dependencies an organization juggles determines which collaboration topology actually works.
- explicitAs a company grows, the natural sequence of team-splitting dimensions is: by product/market fit, then by user group, then by end-to-end 'moments of value' in the user journey, then by funnel stage — in that order of increasing granularity.conf: mediumsupportsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p15 — Wille's 'don't ship your org chart' anti-pattern is a product-management-side restatement of Team Topologies' claim that relying on org charts/matrix management as the primary structuring principle is counterproductive.
- explicitDesigning product teams to mirror the existing organizational reporting structure ('shipping your org chart') leads to inefficiency and silos.conf: high
- explicitSplitting teams purely by technology (frontend/backend, AI team, no-code team) should be avoided except in rare, strongly justified cases, because it creates communication barriers and misalignment with user value.conf: high
- implicitAs organizations grow and teams specialize further, orchestrating high performance across the whole portfolio of teams becomes a qualitatively different, harder challenge than designing the topology of any single team.conf: medium
Arguments
Team topology should be judged and designed primarily by whether it gives each team a genuinely solvable, bounded problem — not by which named category (stream-aligned, platform, etc.) it formally belongs to. strength: low
Explicit premises:
- Engineers' motivation and productivity track directly with having an intriguing, well-bounded problem space.
- Teams split by product line or abstract business goal without a bounded problem end up needing to touch the whole system, producing friction and resource conflict rather than focus.
Implicit premises:
- A team can satisfy the formal definition of a topology type (e.g. 'stream-aligned') while still lacking a genuinely bounded, solvable problem — the taxonomy's labels don't guarantee the underlying property that actually matters.
- Engineer motivation is treated as the primary causal driver of the claimed 10x value gap, rather than, e.g., technical architecture quality, leadership quality, or market conditions, any of which could confound the anecdote.
Inferences:
- A naive application of the four-type taxonomy (labeling teams correctly) could still fail to produce good outcomes if scope-boundedness isn't separately checked.
Team topology design should start from product/user-journey dimensions (product, user group, value-moment, funnel stage) rather than from Team Topologies' engineering-oriented four-type taxonomy, when the person doing the designing is in a product-management role. strength: medium
Explicit premises:
- The book's four-type framing is engineering-oriented and 'never fully resonated' from a product-management perspective.
- A small, better-fitting set of dimensions (product, user group, user-journey moment, funnel stage) maps directly onto what a product leader needs to reason about: who the team serves and what slice of value they own.
Implicit premises:
- The underlying goals Team Topologies pursues (fast flow, minimal cross-team dependency, clear ownership) are compatible with — and perhaps better served by — a product/user-journey-first decomposition than by the book's engineering-first categories, i.e. these are two routes to similar ends rather than competing goals.
- A product leader's native vocabulary (user group, funnel, value moment) is treated as self-evidently more actionable for team design than an engineering vocabulary (subsystem, platform), without engaging the case where technical cohesion genuinely requires a complicated-subsystem or platform team regardless of product framing.
Inferences:
- If product- and engineering-oriented decompositions of the same system disagree (e.g. a 'pricing and packaging engine' Wille or Lieberich would carve as one subsystem-type team might cut across the user-journey splits Wille recommends), the two authors' frameworks could produce conflicting team boundaries for the same organization — a tension neither essay resolves explicitly.
Narratives
- A worked example of a booking engine (airline/travel/fashion retailer) carved into a stream-aligned 'User buying flows' team, a subsystem/enabling 'Pricing and packing engine' team, and a platform 'Base data' team, with a cross-cutting leadership team.
→ Supports Lieberich's well-defined-scope and disambiguated-boundaries propositions by showing a concrete, non-product-line, non-business-goal decomposition — and (unremarked by either author) itself contains a complicated-subsystem-style team that cuts across the user journey, in tension with Wille's purely product-journey-based splitting dimensions. - A job-board example illustrating Wille's four splitting dimensions (product, user group — employers vs. job seekers, value moments — searching/bookmarking/applying, funnel stages).
→ Supports the proposition that product/user-journey dimensions, applied in sequence as a company scales, give a workable alternative to a purely engineering-first topology.
Questions addressed
- ✅ How should a product/engineering organization decide when and how to restructure its teams?
Only when clear dysfunction signals appear (per Lieberich); then slice by bounded, intriguing problem scope with disambiguated cross-team boundaries (Lieberich), or by product → user group → value moment → funnel stage (Wille), while avoiding org-chart-mirroring and pure-technology splits. - ✅ Does the Team Topologies four-type taxonomy serve product managers as well as it serves engineering leaders?
No, according to Wille — it 'never fully resonated' from a product-management perspective, and she substitutes her own product-journey-based rules and dimensions instead. - ⭕ What happens when product-journey-based team boundaries and genuinely technical (subsystem/platform) boundaries disagree about where to cut the system?
Not addressed — both authors' own worked examples include a subsystem/platform-style team, but neither discusses how to reconcile that with a pure user-journey or user-group decomposition when the two disagree.
Gaps
- illogicalWille's claim that Team Topologies' four-type model doesn't resonate from a product perspective, paired with her own worked example containing a complicated-subsystem/platform-style team (the job board's shared 'base data' or pricing logic, by analogy to Lieberich's booking-engine example), suggests her rejection of the taxonomy may be more about vocabulary/framing than about the underlying need the taxonomy is tracking (that some real boundaries are technical, not product-journey-shaped) — a tension the piece doesn't surface or resolve.
Read next: Compare against extract-team-topologies#p12 (fracture planes should match team-first, cognitive-load boundaries) and #p23 (the team, not the value stream, as the implicit atomic unit) to test whether product-journey-first and engineering-first decompositions are actually reconcilable or structurally in tension. - uninformedThe headline '10x value' claim for well-topologized teams is presented as personal observation ('I have been on these teams a few times') with no comparison group, metric definition, or controlled attribution — exactly the kind of practitioner-anecdote-as-data this reader's persona is skeptical of (wants benchmark data over vendor/anecdotal claims), and strikingly similar in rhetorical shape to AI-adoption 10x productivity claims made elsewhere in this corpus (see extract-latent-space-yegge-vibe-coding-manifesto#p2) without either source examining whether the two '10x' claims share, confound, or are independent of each other.
Read next: Look for controlled or larger-sample studies isolating team-topology quality as a productivity variable, independent of the AI-adoption productivity claims appearing elsewhere in the corpus. - incompleteNeither author considers how their prescriptions would need to change if AI coding agents substantially reduce the human execution work a team does — e.g. whether 'ideally 8-10 people' and 'end-to-end responsibility for a part of the user journey' still hold when a 2-3-person team plus agents can cover what used to require a larger team (a question other, more recent corpus documents engage directly).
Read next: Read against extract-latent-space-yegge-vibe-coding-manifesto#p8 and extract-da-silva-sociotechnical-architecture-product-thinking#p7 on shrinking team size and the 'team as fixed human unit' assumption breaking down under agentic execution.
Related documents
- Thriving with complexity using open sociotechnical systems design
- Beyond Autonomous Teams in Software Product Development
- Sociotechnical Architecture as Enabler of Product Thinking
- DevOps Topologies
- 1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs
- How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery
- Team Topologies: Organizing Business and Technology Teams for Fast Flow
- Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024
- AI Won't Save the Kingdoms We Built
- The engineering manager role is splitting in two