liveBook · Manning

Durable team

As explained in Architecture Modernization: Socio-technical alignment of software, strategy, and structure

A team that remains together over an extended period while owning responsibility for part of a product and its ongoing improvement.

A durable team is a stable group that owns part of a product over an extended period and remains responsible for its ongoing improvement. Its continuity strengthens both collaboration and long-term technical stewardship. section 11.1.2

Durability creates several reinforcing conditions:

  • A default size of five to nine people supports trust, shared context, and sufficient capacity. section 11.1.2
  • Owning a product area motivates the team to improve its ways of working and maintain healthy, evolvable code. section 11.1.2
  • Stable does not mean static: membership can change as priorities, constraints, growth, attrition, and knowledge-sharing needs evolve. section 11.4.3

Product mode

Product mode funds durable teams to discover, build, run, iterate, and pivot capabilities. Each team owns the path from ideation through ongoing maintenance, with success measured through improved business metrics rather than fixed-scope delivery. section 6.4.3

Table 6.1 Key characteristics of project versus product mode (view table figure)

  

Projects

Product mode

Funding model

Building a predefined solution or outstanding scope

The team is funded to build, run, iterate, and pivot if necessary.

Team responsibilities

Separate teams for ideation, development, deployment, and ongoing maintenance

Each team is responsible for discovering, building, and running capabilities.

Team lifespan

For the duration of a project, and then disbanded—usually less than a year

Usually multiple years, as long as their reason to exist remains

Definition of success

The fixed scope is delivered on time and within budget.

Improvement of business-related metrics connected to north stars

Compare project teams with durable product teams across funding, responsibilities, lifespan, and measures of success. section 6.4.3

How Architecture Modernization: Socio-technical alignment of software, strategy, and structure covers it

How deep it goes
Explains team size, trust, ownership, code-health incentives, and reteaming, without descending into implementation mechanics.
Examples
Uses five-to-nine-person teams, product ownership, and monthly developer movement between teams as concrete patterns.
What you can do after
Apply durable-team principles to organize ownership, sustain code health, and adapt membership as priorities change.
How it connects
Connects durable teams to product mode, team trust, legacy code, and dynamic reteaming.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Architecture Modernization: Socio-technical alignment of software, strategy, and structure. The section links point to the parts of the book it draws on.