Team-First Thinking

The team, not the individual, is the fundamental unit of software delivery. Teams should be long-lived, stable, and small enough to sustain trust, and work should flow to teams rather than to individuals.

Why it Matters

Durable software is built and owned by durable teams. Optimizing around individuals or temporary project groups loses the shared context and ownership that let a team move quickly and maintain what it builds.

Signals

• Long-lived teams owning clear domains; work is assigned to the team; onboarding invests in the team.
• Anti-signals: people reshuffled every project, shared ownership with no real owner, teams too large to maintain trust.

Benefits

Stable ownership, accumulated shared context, faster flow, and clearer accountability for what gets built and run.

Risks

Long-lived teams can stagnate or hoard knowledge. "Team-first" can be misused to justify rigid silos that resist necessary change.

Tensions

Stability competes with the flexibility to move people toward shifting demand. Team autonomy competes with organization-wide consistency.

Examples

Assigning a domain to a team that keeps it for years, instead of spinning up a temporary project team that disbands and leaves the code orphaned.