Durable, Domain-Owning Teams (vs. Fluid Teams)

Teams that stay together on the same domain long enough to accumulate deep context and ownership — argued (Larson, Majors) to matter more when AI collapses individual execution cost because judgment and accountability live in the team, and contested by calls to make teams fluid, outcome-formed or widened with outside experts now that execution is cheap.

Also known as: durable teams, long-lived teams, stable teams, persistent teams, team as unit of ownership

Documents (6)

• AI + Teams = ? Marcus Castenfors · 2026-09-26 source ↗ Reader 🖥️
  The default way people use generative AI on a team — everyone working alone in their own chat window — quietly damages team alignment and accrues a 'collective debt'; teams do better when they deliberately decide where to prompt together (especially to define the problem, which is a human act AI cannot do well) versus where to delegate to AI individually or collectively, and when they widen the room to outside domain experts now that AI has removed the technical barrier to those experts contributing directly.
• 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.
• Revised rules of engineering leadership. Will Larson (lethain.com) · 2026-06-15 Reader 🖥️
  In an AI-accelerated engineering organization, the scarce resource shifts from code production to judgment and decision-making: individual judgment matters more (because migrations one person can now drive alone have outsized blast radius), durable domain-owning teams matter more (because execution being cheap doesn't make deciding the right thing cheap), and the organization's capacity to make quick, durable, good decisions becomes the actual bottleneck on how much benefit it can realize from AI.
• Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE Latent Space · 2025-12-26 source ↗ Reader 🖥️
  Chat-style coding tools like Claude Code are a transitional phase, not the destination; the real endpoint is an agent-orchestration dashboard for fleets of simultaneously-running coding agents, and the discipline this demands — reading diffs instead of code, tolerating unpredictability, and solving multi-agent merge collision — will determine which engineers and teams survive the shift to 'factory farming' of code.
• Generative AI Is Not Going To Build Your Engineering Team For You Charity Majors · 2024-06-10 source ↗ Reader 🖥️
  Generative AI accelerates the easy, narrow, disposable part of software engineering (writing code) but does nothing for the hard part (building and operating the sociotechnical systems code lives in), so it cannot substitute for hiring and apprenticing junior engineers — teams, not individuals, are the real unit of software ownership, and starving the junior pipeline is cannibalizing the industry's own future senior engineers.
• 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 (2)

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

2019-09

• explicitcontestedTeams should be long-lived rather than disbanded and re-formed project by project, because teams take time to form and become effective, and stable teams accumulate the context and trust that ownership requires.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow · p14

2026-06

• explicitcontestedThe vision of AI-first companies run by a small number of 'genius engineers' who build perfect, unmaintained software one by one is compelling but implausible at scale, because high-judgment individuals eventually get hemmed in by lack of domain context — durable teams, not roaming star individuals, remain the fundamental organizational building block.
  Revised rules of engineering leadership. · p8

Open gaps (8)

• 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 piece doesn't engage with how AI coding agents inside a team change the DP1/DP2 calculus: DP2's 'redundancy of functions' depends on human members being able to cover for each other with genuine skill, social support, and psychological ownership — properties the six criteria measure — and it's unclear whether or how an AI agent can participate in that redundancy, or whether agents instead reintroduce a DP1-like dependency on an external (non-team, non-human) coordinating resource.
  Thriving with complexity using open sociotechnical systems design — read next: Read against extract-latent-space-yegge-vibe-coding-manifesto's shrinking-team-size claims and extract-da-silva-sociotechnical-architecture-product-thinking#p7 on 'the team' as an implicitly fixed human unit.
• incompleteThe claim that 'ideal team size' shrinks to two or three as agents absorb execution says nothing about what durable domain ownership, on-call accountability, or long-term system knowledge look like for a team that small running many parallel agents on a system with a multi-year lifespan — an AI-era durable-teams question the conversation doesn't engage with at all, focused instead on individual productivity.
  Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE — read next: See the corpus's durable-domain-teams material (extract-team-topologies, extract-da-silva-sociotechnical-architecture-product-thinking#p7) which treats 'the team' as the fixed human unit of ownership — directly in tension with Yegge's shrinking-team, many-agents picture.
• incompleteThe piece doesn't name or seriously engage a company that actually tried the 'small number of genius engineers, nothing to maintain' model and failed, so the rebuttal to that vision rests on general argument and one internal anecdote rather than a tested counter-example — notable given how widely that vision is currently discussed.
  Revised rules of engineering leadership. — read next: Look for case studies (successes or failures) of genuinely tiny, AI-leveraged engineering orgs that tried to skip durable-team structure entirely.
• 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).
  Optimizing teams: A dual perspective on Team Topologies — 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.
• incompleteThe 'first job is murder' bottleneck is framed almost entirely through a US, Big-Tech-adjacent lens (top colleges, feeder systems, connections) without addressing how the dynamic plays out in different labor markets, education systems, or company sizes outside that frame — e.g. apprenticeship or vocational-training traditions in other countries that structure entry-level hiring differently.
  Generative AI Is Not Going To Build Your Engineering Team For You — read next: Look for comparative accounts of entry-level engineering hiring outside the US Big-Tech pipeline, or vocational/apprenticeship-model traditions (e.g. German Ausbildung, or Norwegian fagbrev-style models) applied to software.
• incompleteThe book assumes the team (bounded by cognitive load and Dunbar's number) is the correct atomic unit of software ownership, without engaging the alternative that the unit of value delivery is better modeled as a value stream or 'value center' that crosses team boundaries fluidly.
  Team Topologies: Organizing Business and Technology Teams for Fast Flow — read next: extract-beyond-autonomous-teams-in-software-product-development directly challenges the 'autonomous team' framing this book helped popularize, proposing value-center thinking instead.
• 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.