Team Topologies

Skelton & Pais's model for designing teams for fast flow: four fundamental team types (stream-aligned, enabling, complicated-subsystem, platform), three interaction modes (collaboration, X-as-a-service, facilitating), cognitive load as the sizing constraint, and practices such as team APIs, fracture planes and the thinnest viable platform — the reference vocabulary the AI-era call for 'agent topologies alongside team topologies' builds on.

Also known as: team topologies, stream-aligned team, stream-aligned teams, enabling team, complicated-subsystem team, thinnest viable platform, team API, team interaction modes, fracture plane

Part of: Sociotechnical Architecture

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (15)

• DevOps Topologies Matthew Skelton (devopstopologies.com) · 2026-10-08 source ↗ Reader 🖥️
  There is no single universally correct Dev/Ops team structure for achieving DevOps's actual goal — improved delivery of customer and business value — because the right topology is contingent on an organization's product count (via Conway's Law) and on whether its Operations function has the capability and appetite to move from infrastructure-racking toward genuine value-stream alignment; a reference catalog of named anti-patterns and working patterns lets an organization diagnose and choose among structures rather than assume one conformation fits all.
• Beyond Autonomous Teams in Software Product Development Ben Linders · 2026-09-10 source ↗ Reader 🖥️
  Because a team's contribution in a complex organization is really a share of an ever-shifting web of value dependencies rather than a discrete 'product,' organizations should replace 'autonomous product team' thinking with 'value center' thinking, in which every unit at every level (person, team, team-of-teams, org) answers the same five recursive questions and trades off autonomy against coherence according to the shape of the value it carries, not according to ideology.
• How a Culture of Data-Driven Conversations Can Support Platform Engineering Ben Linders · 2026-06-04 Reader 🖥️
  To survive growing cognitive load and operate as a multi-platform team without scaling headcount, a platform org should run SRE as a service through a center of excellence, embed Federated SREs and new bridging roles (production manager, technical tribe lead) into business units, and make SLOs/SLAs a shared organisational currency so that operational ownership is pushed down into product teams rather than centralised in the platform.
• How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery Ben Linders · 2026-05-21 source ↗ Reader 🖥️
  Internal platforms should be run as products that expose composable 'golden bricks' rather than prescriptive 'golden paths,' so that developer teams can self-assemble their own flow of value with low cognitive load while the platform team is held accountable to adoption, experience, and DORA-like outcome metrics.
• Architecture as Code to Teach Humans and Agents About Architecture Neal Ford and Mark Richards · 2026-04-15 Reader 🖥️
  Software architecture should be defined as code — capturing structural constraints deterministically — so that both human developers and AI agents can receive fast feedback on whether implementations conform to design intent.
• Technology Radar, Volume 34 Thoughtworks (Technology Advisory Board) · 2026-04-14 source ↗ Reader 🖥️
  AI-assisted, agentic software development is moving faster than the industry's ability to evaluate it, which means teams must simultaneously retain long-held craftsmanship principles (testability, deliberate design, feedback loops) and rethink team/agent topologies, trust boundaries and metrics that were built for a pre-agent world.
• The Future Of Software Engineering Thoughtworks · 2026-02 Reader 🖥️
  As AI takes over code production, engineering rigor does not disappear but migrates to specifications, tests, constraints, risk management, and a new 'middle loop' of supervisory work — and organizations that fail to deliberately rebuild their practices, roles, and governance around these new destinations will suffer compounding losses in quality, comprehension, and stability.
• TBM 390: Governance by Principle, Not by Template John Cutler · 2025-11-23 source ↗ Reader 🖥️
  Governance should be built from first principles — context-specific risk management, accountability, evidence, and decision rights — rather than inherited from project/program templates and accounting-flavored false precision, because software investment is durable and dynamic rather than static and project-shaped; most organizations' governance is procedurally legitimate (defensible on paper) while failing the substantive test of actually serving investors, employees, and customers, and nothing in major governance frameworks (OECD, NIST, ISO 38500, etc.) actually requires projects or programs as the unit of governance.
• 5) Vidar Moe: Det eneste Vidar vil er å ha det lett Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-11-17 source ↗ Reader 🖥️
  Vidar Moe's core engineering-leadership philosophy is 'gjøre det lett og rett' (make it easy and right) — a Toyota-Way-inflected craft and leadership stance in which you lead an organization most powerfully not by exhortation but by patiently building the tooling, frameworks, fagtid, hiring filters, fixed-term leadership rotation, and shared decision arenas that make the right thing the path of least resistance; the episode's ironic title ('the only thing Vidar wants is to have it easy') inverts this — Moe wants the work to be easy precisely because he is willing to do the very hard, decade-long, mostly invisible work of removing friction from doing the right thing, and his current concern with AI agents is the natural next chapter of the same project.
• 1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-10-13 source ↗ Reader 🖥️
  What warrants the Steve Jobs analogy in Larsen's case is not product taste in a consumer sense but the disciplined construction of a 'strategic narrative' so concrete and personally believed that it can pull a large bureaucracy through a paradigm shift — and this only works when paired with a complementary engineering apparatus (reverse Conway architecture, cross-functional value streams, common components discovered rather than designed, a 'golden-path' platform that makes the right thing the easy thing) operated by a leader who keeps an 'inngangsbillett' to the technical conversation so that the narrative remains connected to what is actually happening on the floor.
• Optimizing teams: A dual perspective on Team Topologies Elias Lieberich · 2024-09-26 source ↗ Reader 🖥️
  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.
• Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 SQUER Solutions · 2024-06-11 source ↗ Reader 🖥️
  Successful architecture modernization is primarily an organizational and narrative problem, not a technology-upgrade problem: it succeeds when architects treat the value stream (business domain + outcomes + team autonomy + deployability) as the real unit of design, triage the system as a portfolio rather than rebuild it wholesale, and use social tools (listening, impact mapping, event storming, enabling teams, early visible wins) to earn and sustain the organizational permission that technical skill alone cannot secure.
• Thriving with complexity using open sociotechnical systems design Trond Hjorteland · 2022-01-05 source ↗ Reader 🖥️
  Software organizations should undergo a radical, participatively-designed structural transition from DP1 (bureaucratic, redundancy-of-parts, externally-coordinated) to DP2 (self-managing, redundancy-of-functions, internally-coordinated) sociotechnical design — the empirically-grounded Open Systems Theory tradition that agile, product, and 'team-first' movements have been independently and incompletely rediscovering — because only DP2 generates the variety needed to thrive in today's turbulent technical and social environment, and because that change must be structural and self-designed, not a culture or values campaign layered on top of unchanged structure.
• Sociotechnical Architecture as Enabler of Product Thinking Eduardo da Silva · 2021-04-30 source ↗ Reader 🖥️
  An organization can only achieve Product Thinking's goal — maximizing continuous, high-velocity value exchange with the customer — by holistically co-designing three interrelated systems together (the customer/market, the teams/organization, and the software architecture), a discipline the author names Sociotechnical Architecture, building on Conway's Law, Team Topologies, and Ackoff's Systems Thinking.
• Team Topologies: Organizing Business and Technology Teams for Fast Flow Matthew Skelton & Manuel Pais · 2019-09-16 Reader 🖥️
  Sustainable, fast software delivery requires organizations to treat team boundaries, responsibilities, and interactions as a deliberately designed, continuously evolving system — using each team's cognitive load as the limiting constraint on what it can own, and Conway's law (via the reverse/inverse Conway maneuver) as the lever for aligning architecture to the team structure an organization actually wants — rather than treating team shape as an accident of historical org charts and project-based reorganizations.

Propositions touching this concept (15)

By publication month, oldest first (extraction month when no publication date is known).

2019-09

• explicitdevelopedThere are exactly four fundamental team topologies — stream-aligned, enabling, complicated-subsystem, and platform — and most other named team types in practice are variations or combinations of these four.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p5
• explicitestablishedStream-aligned teams should be the default, most common team type in an organization, aligned to a continuous flow of business value with minimal hand-offs to other teams.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p6
• explicitEnabling teams exist to close a temporary capability gap for stream-aligned teams and must actively avoid becoming a standing dependency — their value is in handing off learned capability, not in retaining it.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p7
• explicitComplicated-subsystem teams should be formed only when part of a system genuinely requires specialist knowledge beyond what a generalist stream-aligned team could reasonably hold, and should otherwise be avoided to prevent unnecessary hand-offs.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p8
• explicitdevelopedA platform should aim to be the 'Thinnest Viable Platform' — the smallest amount of shared, self-service capability that actually reduces cognitive load for consuming teams — because over-building the platform creates a new bottleneck.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p9
• explicitA team's effective interface to the rest of the organization ('Team API') includes its documentation, onboarding process, and communication norms, not just the literal code-level API it exposes.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p11
• explicitMembers of effective stream-aligned teams tend to report achieving or progressing toward 'autonomy, mastery, and purpose' (Daniel Pink's components of engaged knowledge work), treated as both a cause and a signal of good team design.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p17

2021-04

• explicitdevelopedTeams must have the right scope and capacity (topology) to actually build the intended product; architecting systems without considering team setup, following Team Topologies' 'team-first approach,' leads to delivery surprises.
  Sociotechnical Architecture as Enabler of Product Thinking · p2

2024-06

• explicitSustaining a modernization effort requires a temporary 'architecture modernization enabling team' whose core skill is facilitating other teams to find their own solutions rather than solving problems for them directly.
  Architecture Modernization: Aligning software, strategy, and structure • Nick Tune • CodeCrafts 2024 · p11

2024-09

• 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.
  Optimizing teams: A dual perspective on Team Topologies · p5

2024-10

• explicitdevelopedDeveloper independence (completing the full application lifecycle without an enabling team) is the platform-engineering lever with the clearest productivity payoff — a 5% gain at both individual and team level — larger in per-capita terms than having a dedicated platform team, which produced a 6% team-level gain but a negligible individual-level one.
  2024_final_dora_report · p6

2025-11

• explicitToyota Way / Lean and the DORA / Accelerate / Team Topologies tradition are the same intellectual lineage — Lean's practices map directly onto modern continuous-delivery metrics.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p15
• explicitcorroboratedTeam 'shapes' (in Team Topologies vocabulary: stream-aligned, platform, enabling, complicated-subsystem) are useful models, not permanent installations, and should be expected to evolve as products, architecture, and organizational needs change — governance should periodically re-check fit rather than install team types and forget them.
  TBM 390: Governance by Principle, Not by Template · p12

2026-04

• explicitdevelopedTeams must rethink how they collaborate and structure themselves for agentic systems — considering agent topologies alongside existing team topologies and rethinking feedback cycles accordingly.
  Technology Radar, Volume 34 · p4

2026-05

• implicitOrganisational design (autonomous, stream-aligned teams owning their flow) is a prerequisite for bricks-style platforms; without it, bricks become rubble.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p12

Tensions

Open gaps (45)

• incompleteThe AI platform team concept is asserted but not developed. How does it differ from existing developer experience (DX) or platform engineering teams? What skills does it require? How does it avoid becoming a bottleneck itself? The analogy to Docker containers is gestured at but not followed through.
  Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle — read next: Team Topologies (Skelton & Pais) on platform team design patterns; internal developer platform literature
• incompleteThe claim that the five questions apply unchanged 'at all levels: team, team-of-teams, department, whole organisation' is asserted but only ever demonstrated with a single team-level worked example (Scrum backlog, sprint goal); no worked example is given at the team-of-teams, department, or whole-organization level, so the universality/recursiveness claim is untested within the piece itself.
  Beyond Autonomous Teams in Software Product Development
• incompleteThe article explicitly defers 'how to implement these ideas' and 'who should do this' to other articles in the author's broader Sociotechnical Architecture series, some of which were still unwritten at publication — so the holistic framework is argued for conceptually but not demonstrated through an implementation case study beyond the illustrative Restaurant Product analogy.
  Sociotechnical Architecture as Enabler of Product Thinking — read next: The author's later Sociotechnical Architecture and Systems series, if subsequent installments addressing implementation exist.
• illogicalThe claim that siloed/local optimization 'almost never' maximizes overall customer value is asserted via Ackoff's systems-thinking authority and the restaurant analogy, not demonstrated through a comparative case (siloed optimization tried and found wanting versus holistic co-design succeeding under otherwise comparable conditions).
  Sociotechnical Architecture as Enabler of Product Thinking — read next: extract-dora-2024-accelerate-state-of-devops for metrics-based evidence on this trade-off.
• incompleteThe talk assumes a small, highly skilled team that can make and evaluate architectural decisions rapidly. No discussion of how these practices scale to larger organizations where most engineers are not senior architects.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: Team Topologies (Skelton & Pais); research on scaling agile and continuous deployment in large organizations
• incompleteFowler claims the lessons are 'still relevant today' but provides no modern examples or evidence. The piece is purely retrospective endorsement. What does violating conceptual integrity look like in 2026 — in microservices, AI-generated code, or platform teams? How does Brooks's Law manifest with remote/async teams, AI pair programmers, or open-source contribution models?
  Bliki: Mythical Man Month — read next: Brooks's own 'No Silver Bullet' essay (included in the anniversary edition); Conway's 1968 paper on organizational structure mirroring system design; Team Topologies (Skelton & Pais) for a modern treatment of communication paths as architectural constraints; Fred Brooks's later reflections in 'The Design of Design' (2010).
• incompleteThe Jobs analogy is named but not fully cashed out against its disanalogies. Jobs's reality distortion field was famously paired with cruelty, factional purges and product taste applied to consumer aesthetics. Larsen's framing is the opposite — toppdivisjon-ledelse runs on indre motivasjon, not fear; authenticity / easy-to-read-ness is the asset; the product is a public-sector welfare system. The conversation does not name these disanalogies, so the analogy carries more rhetorical work than it earns.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read Walter Isaacson's Jobs alongside Tracy Kidder's Soul of a New Machine and Marc Andreessen-tradition writing on charismatic founder leadership to surface the disanalogies; for the NAV case specifically, read Cutler on 'institutionalized overload' to see what indre-motivasjon-based mobilisation can hide. Connects to the gap in the Skjærpe ep 17 extract on transformations that fail in the liminal phase.
• incompleteThe NAV transformation is described entirely from the inside by one of its architects. There is no counterfactual: comparable Norwegian agencies that did not transform similarly, post-Larsen reversion at NAV, what failed within NAV and why. The 'hagiography risk' the hosts flagged is real and unexamined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Compare Skatteetaten, Statens Pensjonskasse, Helsedirektoratet trajectories during the same period; read the NAV-flow article in the user's library (Optimizing for Fast Flow in NAV) for the inside-but-different-author view; read the Skjærpe ep 17 extract for the immediate-successor's view from inside the system. Look for what the NAV transformation displaced or made impossible (e.g. casualties among legacy fagsystemer staff).
• incompleteThe 'common components are discovered, not designed' thesis is asserted with the NAV fakturering case as the load-bearing example, but the inverse failure mode (premature divergence — many verticals each solving the same problem badly because no one promoted the pattern to the platform) is acknowledged in passing ('we have capabilities in the platforms that strictly speaking are only needed one or two places ... it is a little behagelig that it got fixed over there') without being theorised. The position is one-sided.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Read the Wardley Mapping / pioneers-settlers-town-planners tradition for an explicit account of when components should be designed up front (the 'industrialised' part of the map). Read Cutler on 'horizontal team accountability' for how teams refuse to own platform-like problems they should own. The Vipps ep 18 extract may have a relevant view from the perspective of an organisation that did design infrastructure up front.
• incompleteThe 'easy to read' / authentic-leadership claim collides with the strategic-narrative claim. Strong strategic narrative is itself a construction; sustained reality-distortion presupposes some performance discipline. The conversation treats easy-to-read-ness and disciplined narrative as compatible without examining the tension. When does the constructed narrative cross into managed-impression territory, and what is the leader's check on that?
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Erving Goffman's Presentation of Self; Edgar Schein on the discrepancy between espoused theory and theory-in-use; Bent Flyvbjerg on narrative in megaprojects (where the same person both believes and constructs the future). The Cutler 'signals that look like decisions' thread is also relevant — for an easy-to-read leader, even contemplative musings can be read as commitments.
• incompleteThe inngangsbillett method is a personal description, not a teachable account. Larsen says he spends 'many hours a day' on craft and uses the hermeneutic-circle approach, but does not name which key terms, which structural maps, which sources, or how to know when the inngangsbillett is sufficient for a given fagdomene. The 'Fred George reads no books, he talks to authors' punchline gestures at one upper-bound technique but leaves the floor undefined.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Hubert Dreyfus's five-stage skill model (novice → expert) for a more precise grammar of 'how much do I need to know'; Cal Newport's deep work / deliberate practice tradition; the recent harness-engineering and AI-coding research extracted in this repo on what 'understanding a system' actually requires before AI can help you scale that understanding.
• uninformedThe conversation invokes Peter Senge's learning organisation as one of the three common denominators of Larsen's narrativer but does not interrogate how durably the organism-organisation framing has held up under real conditions over the 30 years since Fifth Discipline. There is a tradition of critique (e.g. Mintzberg on the messiness of organisational learning; recent operations-research literature on actual learning loops in software organisations) that the conversation does not engage with.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Mintzberg's Rise and Fall of Strategic Planning; Argyris on double-loop learning vs Senge's framing; the more recent DORA / Accelerate research on what kinds of learning actually correlate with performance — and what kinds (e.g. 'just keep adapting') do not.
• incompleteThe episode ends on Larsen's most quotable problem — moving from project mindset to outcome-driven verdistrøm-mindset — but does not specify what makes this so hard at Telenor specifically. Is it inherited governance? Board reporting cadence? Career incentives for people who have always shipped to scope? The hosts move on. This is the single most actionable place the conversation could have gone deeper.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: Cutler on outcome-orientation and operating-system design; Marty Cagan's 'product team vs feature team' distinction; the Una Aamodt-Mathisen ep 10 extract (lede uten fasit) likely has direct material on the same problem at a different scale. The Vidar Moe ep 5 ('det eneste Vidar vil er å ha det lett') may have a relevant view on operating-model simplification.
• incompleteThe hagiography risk is structural: Truls worked for Larsen, Audun met him at a formative moment, both are visibly inspired. The format does not include any adversarial pressure. The episode is therefore best read as Larsen's self-presentation lightly facilitated by admirers — strong as primary source, weak as evaluation.
  1) Torbjørn Larsen: Det nærmeste vi kommer Steve Jobs — read next: For an evaluation lens, read external accounts of NAV's transformation (audit reports, Riksrevisjonen, Aftenposten / NRK coverage of NAV IT projects during the Larsen era), and look for counter-narratives in the Norwegian public-sector tech community. Compare to Holte ep 2 (the senior public-sector counterpart) for a different view of the same period.
• incompleteThe episode systematically tells the success-side of the story. Crisis → response → improvement is the recurring arc, but failed experiments, dead-end framework choices, or instances where 'gjøre det lett og rett' produced unintended organisational uniformity are absent. Moe's stated regret is only directional (could have done more, faster, in more places), not structural (e.g. 'this particular default we engineered was wrong'). The hosts twice surface the hierarchy-is-inevitable point but do not press on whether the framework-team's 'easy and right' becomes a hidden orthodoxy.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with Allen Holub's #NoAccountability strand (already in the user's persona) and with anything on the costs of platform-engineering paved roads (e.g. Charity Majors / Honeycomb on the limits of golden paths). The user's existing extraction on Cutler's institutionalised overload is a strong complement here — Cutler's frame would ask what the second-order costs of the SpareBank 1 system look like.
• incompleteMoe's persistent 'vi' is itself a load-bearing rhetorical pattern that the hosts notice in closing but do not unpack. The episode is a portrait of a person who declines to be individuated — he says 'vi' even when narrating decisions whose intellectual origin clearly lies with him personally. This is consistent with the leadership-through-defaults thesis (the work is the structure, not the speaker) but it also obscures the part of the story that does depend on a specific senior practitioner persistently present in the system for 14 years. The question 'how transferrable is this without Moe (and Stian)?' is not engaged.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in tension with the previous Heis episode on hierarchy (Eikeland, ep 4, alluded to: 'forrige podcast-episoden snakket om... det er sjelden helt flat struktur') and with the leadership-presence strand in the user's library (Cutler on power and space, TBM 413). Beck's writing on senior individuals' role in evolutionary design is a direct anglophone parallel.
• incompleteThe 'organisatorisk gjeld' coinage at the close is the most pregnant unfinished idea in the episode. Moe gestures at the next direction of 'lett og rett' — engineering golden paths for product development itself, with good practices baked into roadmap tooling — but does not work it out. This is exactly the territory where the AI question reconnects: an agentic product-development assistant that encoded the right defaults could be the next instance of 'lett og rett', and would be a Moe-shaped answer to the alienation worry from his essay.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with the user's existing extractions on harness engineering for AI coding agents and on 'Agents Don't Know What Good Looks Like'. The Backstage / Internal Developer Platforms tradition (Spotify) is the obvious anglophone analogue. Team Topologies (Skelton & Pais) and DORA's recent platform engineering findings are the natural canon. Truls's closing observation that Toyota → DORA → Team Topologies is one lineage is exactly the bridge.
• incompletePair programming is named as the most effective form of knowledge sharing and as the substrate that the rest of the infrastructure exists to support, but the cost question (developer preference, time investment, neurodiversity, hybrid/remote context) is not engaged. Moe acknowledges that change in this direction is 'ordentlig seig' — really tough/slow — but does not ask why even at SpareBank 1, with all the structure in place, pair programming is not yet universal. The same gap exists in his essay's TDD-with-the-agent prescription.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read Birgitta Böckeler's recent work on remote pair programming, and the user's already-extracted Beck material on TCR (which functions as a half-step toward pair-discipline). The 'AI Joy Gap Developers' extraction the user already has — which treats reconnection-of-developers as needing organisational structure — is a direct complement.
• incompleteThe Norwegian / Lean-Norwegian context is implicit but not theorised. The åremål concept comes from Norwegian political and academic life and is being repurposed for engineering leadership. The fagtid concept has roots in Norwegian work-culture autonomy ideas. The DORA / Lean / Toyota convergence Truls names at the end is itself partially a Nordic management-culture convergence. There is a comparative essay latent here that the episode does not write.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in parallel with NAV's 'optimizing for fast flow' piece (already in the user's queue), with Norwegian Self-Determination Theory–inflected management writing (autonomi, mestring, mening), and with the wider tradition of Nordic engineering culture vs. anglophone agile-at-scale. The user's coding-agents corpus already includes Nils Brede Moe (no relation? — but a Nordic empirical-software-engineering voice in the same neighbourhood, including the upcoming Heis episode 9).
• incompleteThe architect's function is never defined. The talk asserts that architecture has not changed in its core function, only in practice — but it does not say what the function is. The closest thing to a definition is 'enabling speed and flow via loose coupling and high cohesion', which is more a goal than a function and which collapses architecture into platform engineering in some readings.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Vlad Khononov on coupling in distributed systems; Ruth Malan on architecture as 'the design decisions that are hardest to change'; Team Topologies for the sociotechnical framing Ulseth invokes.
• uninformedUlseth notes he has not yet seen conversational architecture practiced and that sociotechnical architecture is a new acquaintance — yet these are the frameworks he is now bringing into Fremtind's IT strategy. The talk does not engage seriously with the published critiques of these models (e.g. that Team Topologies under-specifies platform-team funding, or that Harmel-Law's model assumes a maturity teams may not have).
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Andrew Harmel-Law's own book and the Architecture Decision Records literature; critical reviews of Team Topologies (Manuel Pais et al.).
• incompleteSame gap as the Golden Bricks extract, in a different colour. The whole programme assumes a Team-Topologies / Spotify-style organisation already exists — stream-aligned squads inside tribes, a platform team adjacent to them, business decision-makers sitting at tribe level. The Federated SRE, production manager, and technical tribe lead are role inventions overlaid on this topology, not designed to produce it. The article describes role responsibilities mechanically but treats the underlying org redesign — the part that costs years and political capital in most enterprises — as already done. For a reader whose org is functionally shaped, this is the part that matters most, and it is invisible.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Skelton & Pais, Team Topologies (esp. the 'enabling team' interaction mode, which is what Federated SREs functionally are). Cutler on operating-model design and accountability layering. Pais on cognitive-load assessment as a precondition for federation. Reinertsen on capacity allocation and queueing — the 20% tithe is a capacity-allocation decision that needs queue-theoretic defence.
• incompleteThe 'democratisation' mechanism is never opened up. The article uses 'democratised SLOs/SLAs' as the load-bearing cultural claim but never explains how democratisation happens — who publishes the SLOs, in what tool, who is allowed to negotiate them, what stops squads from quietly setting easy SLOs to escape scrutiny, what the production manager does when a squad's SLO drifts. Without this, 'data-driven conversations' is a slogan with no enforcement surface. The mechanical specification matters: democratisation without governance is just SLO theatre.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Google SRE Workbook on error budgets and SLO policy (the governance scaffolding democratisation usually rides on). Honeycomb / Charity Majors on observability ownership. Forsgren et al. on metrics that resist Goodhart pressure.
• incompleteThe 20% mandatory squad investment is presented as a structural lever, but the article never says how it is funded. 20% of every squad is a large standing tax on feature delivery; in most orgs this is the single most contested resource decision a CTO can make. The article gives no defence of the figure (why 20% and not 10% or 30%), no description of how it shows up in planning (is it a fifth person, a fifth of everyone's week, a rotation?), no answer to what gets dropped when the rest of the squad's commitments don't shrink. This is the place where the prescription would either hold or shatter in practice.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Reinertsen, The Principles of Product Development Flow, on capacity allocation under variability. Allen Holub on the politics of capacity-as-budget. Cutler on the operating-system level of organisational design.
• incompleteThe four-rebuilds story is reported as triumph but never costed. Destroying and rebuilding the platform architecture four times has a cost — for the consuming squads who must re-learn it, for the regulators who must re-approve it, for the institutional memory that bleeds out at each rebuild. The article reports the platform team's experience ('it worked perfectly for us') without checking the consumer side. The same testimony from the squads might read very differently.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Ford, Parsons & Kua on evolutionary architecture (the disciplined version of what Petean is describing). Hohpe on architecture decision records and the institutional cost of irreversibility. Naur on programming-as-theory-building — what gets destroyed in a rebuild that isn't in the code.
• incompleteCost-per-change is offered as the financial counterpart to DORA but is not interrogated. Of the four reasons given for the decline (platform effect, expertise maturity, federation, massive business scaling), the fourth alone could explain the result via simple denominator inflation. Without weighting or counterfactual ('cost per change held flat through a comparable scaling period before federation'), the metric is decorative. This matters because cost-per-change is the kind of number that gets quoted as proof of platform ROI without the caveats travelling with it.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: FinOps Foundation material on attribution and unit economics. Cutler on signal-vs-noise in metrics. The DORA / SPACE original papers on the limits of self-reported organisational improvement.
• uninformedNo engagement with the existing literature on embedded/federated SRE. Google's SRE Book has a chapter on the embedded-SRE model; the CNCF Platforms WG has written on platform-team interaction modes; Team Topologies' 'enabling team' is functionally close to the Federated SRE role described here. The article presents the three-role pattern as if it were freshly invented, which makes it harder to compare against the failure modes the prior literature documents (embedded SREs going native to squads, central guidance eroding, federation creating shadow operators).
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Beyer, Jones, Petoff, Murphy (eds.), Site Reliability Engineering, esp. the embedded-SRE chapter. CNCF Platforms WG whitepapers on team topologies for platforms. Skelton & Pais, Team Topologies, on the enabling-team interaction mode.
• incompleteThe piece fuses the mindset shift with one specific cloud-provider architecture (self-service, CRDs, service/control/management planes). It leaves unresolved whether that architecture is a precondition of product thinking, a consequence of it, or merely this team's instance — a lighter platform could adopt product thinking without it.
  Shifting Platform Development from Projects to Products — read next: Skelton & Pais, 'Team Topologies' (platform-as-product and the 'thinnest viable platform'); John Cutler on separating operating model from tooling.
• incompleteNo deprecation or sunsetting mechanism. The founding complaint is 'accumulated capabilities competing in priority', yet the product model as described adds new abstractions without any account of retiring unused ones — the accumulation problem is diagnosed but structurally left unsolved.
  Shifting Platform Development from Projects to Products — read next: Kent Beck on removing/simplifying (Tidy First? — subtraction as design work); lifecycle/deprecation practices in platform engineering (e.g., Team Topologies on platform evolution).
• incompleteThe claim that 'business people' are taking back power from engineering/developers is a significant organizational-leadership claim, but the interview never explores the mechanism — how this shift plays out inside engineering orgs, what it implies for platform/API teams' autonomy and decision rights, or what leaders should do in response.
  Kin Lane on AI and the Future of APIs — read next: Organizational-design and platform-team-autonomy literature (e.g., Team Topologies, John Cutler's writing on product operating models) to unpack what this 'business takeback' means for how engineering leadership should structure teams and decision rights under AI-driven budget shifts.
• incompleteThe organizational dynamics are unaddressed: how does a centralized infrastructure team get authority to override individual team hardware preferences? The talk mentions 'infrastructure needs to do the heavy lifting' but not how to achieve that organizational mandate.
  Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability — read next: Platform engineering organizational models — Team Topologies (Skelton & Pais), or talks on Netflix's infrastructure organization
• incompleteThe 'golden path vs golden brick' distinction is rhetorical, not analytical. What actually changes when you move from path to brick? The article never decomposes the shift along the three axes where the shift really lives: (a) governance — who owns correctness, the platform team (path) or the consuming team (brick); (b) composability — who designs the assembly, and against what contract; (c) team autonomy — does the consuming team have the decision-rights, time, and skill to assemble well? Without this decomposition, 'bricks' is a slogan, not a model.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Skelton & Pais, Team Topologies (esp. platform team / stream-aligned team interaction modes). Camille Fournier's writing on platform teams. Gregor Hohpe on architecture decision records and IT architecture as conversation. Manuel Pais on the cognitive-load assessment.
• incompleteThe organisational shift the article requires but does not theorise. Bricks-not-paths only works in an organisation that has already pushed correctness, security review, cost ownership, and incident response down into stream-aligned teams. In an org where the platform team is also the compliance team and the on-call team, bricks-without-a-path means each stream team must reinvent guardrails. The piece treats this organisational redesign as free — but it is the actual hard part.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Cutler's TBM essays on institutional overload and accountability. Allen Holub's #NoAccountability work. Conway's Law re-readings (Skelton/Pais). Andrew Clay Shafer / DevOps adoption literature on the politics of platform ownership.
• incompleteStrawmanning of the golden path. In Spotify's original formulation and most current usage, a golden path is an opinionated default route through optional tooling — not 'the single way to do things.' Bryant collapses 'golden path' into 'golden cage' to set up the brick contrast, which makes the move feel sharper than it is. The real design choice is the ratio: which bricks ship with reference compositions (paths) attached, and which don't.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: The Spotify Backstage docs on golden paths. The 'paved road' material from Netflix engineering. Honeycomb's writing on opinionated developer platforms.
• incompleteNo treatment of the leaky-abstraction risk that the brick model amplifies. The more composable the platform, the more surface area developers can latch onto — and the harder it becomes to change the implementation later. Bryant raises leaky abstractions as a warning but never connects them to the brick model, which is precisely where they bite hardest.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Spolsky's original 'Law of Leaky Abstractions.' Ousterhout, A Philosophy of Software Design, on deep vs shallow modules — bricks must be deep modules or the abstraction tax is real.
• uninformedNo engagement with the actual maturity literature on internal developer platforms — CNCF Platforms Working Group whitepaper, Team Topologies' Thinnest Viable Platform concept, the platform-engineering maturity model from PlatformCon. The piece treats the field as if Bryant is naming things for the first time.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: CNCF Platforms WG whitepaper (2023+). Team Topologies' TVP material. McKinsey/ThoughtWorks platform engineering reports for the practitioner-economics view.
• incompleteThe post diagnoses the problem brilliantly but doesn't offer a transition path. How does an organization that recognizes it's running the engineering-as-bottleneck model actually shift to the learning model? What are the first moves? Who has to change their behavior first? The 8 questions at the end are diagnostic, not prescriptive.
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier — read next: Cutler's earlier work on mandate levels and enabling constraints; Team Topologies (Skelton & Pais) on organizational design; Marty Cagan's 'Transformed' on product operating model transitions
• incompleteThe essay focuses on the product/design/tech axis inside a single org. It does not address how this dynamic changes in regulated, public-sector, or critical-infrastructure orgs where 'teams' are also legal/audit/governance entities — a context particularly relevant to Norwegian public-sector tech (NAV, Entur, public services).
  TBM 423: Why Defining Teams Is So Hard — read next: Pia Andrews / GovTech writing on public-sector team design; Mark Schwartz ('A Seat at the Table', 'War and Peace and IT') on bureaucracy and IT leadership; Mariana Mazzucato on mission-led public organizations. For the Nordic context: Skatteetaten/NAV/Entur case studies on team topologies in regulated environments.
• incompleteThe 'pendulum' framing is descriptively useful but normatively underspecified. Cutler observes the swing between 'everything is a product' and 'three products only' but doesn't propose what the stable middle looks like — what's the unit of organization that resists both inflation and deflation of the product label?
  TBM 423: Why Defining Teams Is So Hard — read next: Team Topologies (Skelton & Pais) explicitly types teams (stream-aligned, platform, enabling, complicated-subsystem) as a possible answer; Sriram Narayan on agile organization design; Marty Cagan's 'empowered product teams' framing as a competitor.
• incompleteThe post barely engages with what 'aspirational' actually looks like — there is no example of a North-Star map that is being incrementally closed versus one that is permanent theater. Without exemplars, the distinction is rhetorical rather than operational.
  TBM 423: Why Defining Teams Is So Hard — read next: Team Topologies (Skelton & Pais) — their stream-aligned/platform/enabling/complicated-subsystem taxonomy is the closest thing to an operational aspirational map; useful to read it through Cutler's lens to see whether it survives the 'permanent theater' test.
• uninformedThe evidence base is a set of hand-picked industry case studies presented as successes; there is no longitudinal or comparative data on organizations that adopted the four-topology model and did not see improved flow, or that abandoned it.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow — read next: Look for independent post-adoption research (e.g., DORA/Accelerate-style empirical studies) measuring flow metrics before/after Team Topologies adoption specifically, rather than case narratives selected by the authors.
• incompleteThe document identifies the productivity/experience paradox but offers no framework for resolving it beyond the 'agent experience' reframe. How should organizations actually measure and invest in developer satisfaction when it is decoupled from output?
  The Future Of Software Engineering — read next: DORA team's ongoing research on developer experience metrics; Nicole Forsgren's work on SPACE framework
• incompleteThe batch-size regression is flagged as an 'active regression needing industry attention' but no countermeasures are proposed beyond general governance reform.
  The Future Of Software Engineering — read next: DORA State of DevOps reports; continuous delivery literature on changeset sizing with AI tools
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Technology Radar, Volume 34 — read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.
• incompleteThe Tiger Team concept is described but there is no discussion of how Tiger Teams dissolve back into the organization, how knowledge transfers, or how the org evolves its permanent structure based on what Tiger Teams learn.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Literature on temporary organizations, project-to-product transitions, and Team Topologies by Skelton and Pais.