Think small teams
"Think small teams" captures Wardley’s guidance to break large programmes into autonomous cells aligned to user needs. Rather than monolithic projects, create mission-focused groups that own slices of the map, work with minimal coordination friction, and evolve components at the right pace. Small teams make it easier to sense change, swap methods, and scale successful patterns across the landscape.
Why this doctrine matters
- Autonomy shrinks inertia. Teams with clear intent and limited dependencies can respond to signals without waiting for bureaucracy to catch up.
- Cell structures reveal duplication. When each team owns a defined portion of the map, overlapping work becomes obvious and easier to consolidate.
- Smaller units encourage stewardship. Ownership of outcomes—not just deliverables—drives better interfaces, documentation, and knowledge sharing.
Practices to embed
- Map ownership to user needs. Assign teams to coherent value streams so they see how their work impacts the user outcome end to end.
- Limit team span. Keep group missions narrow enough that the team can understand its whole slice of the map and evolve components deliberately.
- Provide lightweight coordination forums. Use communities of practice, weekly map reviews, or shared pipelines to align without reinstating hierarchy.
- Rotate learning between cells. Encourage teams to borrow proven practices from neighbours and retire what no longer fits.
Watch for anti-patterns
- Creating “small” teams that still depend on central approval for every change.
- Splitting teams along organisational silos rather than along user journeys.
- Letting shared platforms become bottlenecks because no single team owns their evolution.
Questions to ask
- Which user needs lack a clearly accountable team?
- Where do dependencies repeatedly stall delivery, and how could we restructure ownership?
- How do teams request help or hand off work without recreating central command?
- What signals show when a team’s scope has grown too large?