MicroservicePatterns.com

Suggestions

  • PagePattern catalogAll patterns by category.
  • LabCircuit Breaker and Retries labCrash a dependency and tune the breaker.
  • LabSaga labFail a step and watch the compensations run.
  • PagePractice questionsScenario questions with explanations.
  • PageDesign reviewCheck your own architecture for anti-patterns.
Teams and ownership · Foundation

Stream-Aligned Team

The Stream-Aligned Team pattern gives one long-lived, cross-functional team ownership of a business capability or user journey through every technical layer, so it can deliver changes without handing work to other teams.

Last updated

Use it when

  • Features keep crossing several layer-based teams and waiting at each handover.
  • You have split, or are splitting, the system into services by business capability.

Avoid it when

  • The organisation is small enough that one team owns everything. Splitting adds coordination for nothing.
  • The work is a deep specialism that would overload any team that also owns a capability. That is a complicated-subsystem team.

Goes with

Decompose by Business CapabilityYou Build It, You Run ItPlatform TeamMicro-Frontends
Try the labTest yourself

What is the Stream-Aligned Team pattern?

A stream-aligned team owns a slice of the business, such as search, ordering or payments, and the software for it in every layer: web and mobile screens, its BFF, its services and their data. It has the skills to design, build, test, release and run that slice. Most teams in an organisation are stream-aligned, and the other team types exist to help them go faster.

What problem does the Stream-Aligned Team pattern solve?

Teams organised by technical layer (a frontend team, a backend team, a database team) need each other for almost every feature, so work queues at every handover. A team that owns its capability end to end can take an idea to production on its own and learn quickly from what users do with it.

How do you implement the Stream-Aligned Team pattern?

  1. Draw team boundaries around business capabilities, the same way you draw service boundaries.
  2. Give each team the skills for every layer it owns, and keep the team small enough to share one understanding of its domain.
  3. Keep teams stable for years, and bring work to the team rather than moving people between projects.
  4. Limit what each team has to know by giving it a platform for the layers' foundations and a short list of blessed stacks.
  5. Measure the team on outcomes for its capability, not on output.

When should you use it?

  • Features keep crossing several layer-based teams and waiting at each handover.
  • You have split, or are splitting, the system into services by business capability.

When should you avoid it?

  • The organisation is small enough that one team owns everything. Splitting adds coordination for nothing.
  • The work is a deep specialism that would overload any team that also owns a capability. That is a complicated-subsystem team.

What do you gain?

  • Ideas reach production without handovers
  • Clear ownership of each capability
  • Teams learn their domain deeply

What does it cost?

  • Each team needs a broad mix of skills
  • Some duplication of effort across teams
  • Cognitive load grows unless a platform absorbs it

What are common mistakes with the Stream-Aligned Team pattern?

  • Calling layer teams 'stream-aligned' while every feature still needs three of them.
  • Expecting one team to master every technology in every layer, with no platform to lean on.
  • Reshuffling teams every quarter, so nobody owns anything for long.

Stream-Aligned Team in practice

Real-world example

Amazon

Amazon wanted teams small and autonomous enough to move quickly for their customers.

Its two-pizza teams are small enough to be fed by two pizzas, ideally fewer than ten people, and each has single-threaded ownership of a specific product or service across the full customer experience. They do not hand what they launch to another team to run. AWS notes the model is not perfect: autonomy brings a risk of duplication and siloed work that needs governance, and it may not suit every organisation.

Source: Amazon's two-pizza teams (AWS Executive Insights)

Example decision record
Context
Every feature crosses web, mobile, API and database teams and waits at each handover.
Decision
Form long-lived teams around business capabilities, each owning its slice through every layer, with platform teams providing the layers' foundations.
Consequences
  • Most features are delivered by one team.
  • Teams need broad skills and a platform to keep cognitive load manageable.

Test yourself on Stream-Aligned Team

Teams and ownershipfoundation

An online shop has a web team, a mobile team, an API team and a database team. Adding a gift message to checkout needs work from all four, and takes six weeks of handovers. What structure would help most?

4 questions involve this pattern. Practice all of them →

Done with Stream-Aligned Team?

Saved in this browser only. See your progress →