Skip to content

Change 2 of 6

Structure

One team from idea to customer.

Small teams with the skills and decision rights to own a value stream end to end.

The change

Design boundaries around customer value.

A group with research, design, and engineering skills in it is not automatically independent. If it depends on other teams to decide, test, or release every change, its pace is still determined by those handovers.

A value stream is a part of the customer journey with a clear result, such as completing setup or making a purchase. Give a small, persistent Stream Team ownership of that experience from end to end. Then work through the skills, systems, and decisions needed to serve that scope. A team boundary is useful when it removes recurring coordination from the work.

Faster AI-assisted delivery makes unresolved handovers more visible: a team can finish a change quickly and still wait days for permission or another team.

What changes in practice

  1. Name the scope.

    Define the part of the customer experience the team owns. Make the boundaries clear enough that people know where decisions belong.

  2. Bring the necessary skills together.

    Put the core design and development capabilities in the team. Add other expertise where the scope requires it. Give the team the authority to test, change, and release within agreed guardrails.

  3. Design the connections deliberately.

    Resolve recurring dependencies. Where a capability is genuinely shared, make its ownership and service relationship explicit.

A practical example

Slice a booking product around the customer journey.

In our booking platform, a customer finds a place to stay, books it, and later manages the reservation. Each part of that journey gives a Stream Team a scope with a customer result to improve. The team owns the interface, business logic, and data for that scope, with the skills and authority to research, design, build, and release changes.

The Product Team sets product strategy and Stream Team objectives for the whole booking product. Connections need explicit agreements: for example, the price shown in search must match the price at checkout. If routine improvements keep needing several teams to change together, revisit the boundaries and the systems behind them.

An illustrative booking product split into three Stream Teams. Find a stay: Search Team owns search and comparison, helping customers find a suitable stay. Book a stay: Booking Team owns reservation and payment, helping customers confirm a booking. Manage a stay: Stay Management Team owns changes and cancellations, helping customers manage their reservation. The Product Team sets product strategy and Stream Team objectives.

Structure in practice

Real case studies from UXDX conferences and other sources.

Amazon logo

Two Pizza Teams

Amazon faced a problem of slowing development speed. They decided to create autonomous teams who would be able to move faster. But it wasn't all plain sailing.

E-commerce / Technology

DAZN logo

Micro-frontends

Exploring how DAZN accelerated innovation and team autonomy by removing blockers from their teams through the adoption of micro frontends, transforming their development process and scalability.

Media / Sports Streaming

Browse 7 structure case studies ↗

Common objections

Autonomous teams will duplicate work and we lose our shared functions
Some duplication is likely, and a little of it is often a fair price for teams that don't have to wait on each other. Give each Stream Team a clear customer journey to own and be explicit about which capabilities are shared. When several teams keep needing the same thing, and the waiting costs more than building it once would, that's the time to turn it into an Internal Product Team with its own roadmap. It's best to avoid building a platform up front just to remove every trace of duplication, because centralizing functionality can lead to bottlenecks and reduced agility.
True autonomy is too expensive
There is an up-front cost, and it can be significant. In Working Backwards, Colin Bryar and Bill Carr describe Amazon teams spending up to nine months removing dependencies before they delivered new features. With AI it would be a lot quicker today. The alternative is paying for coordination every time something changes. You don't have to do it all at once, though. Agree the scope and the investment up front, and then check whether waiting and rework are falling before you go further.
If you break apart the code then you'll have to collaborate more
You'll still collaborate, but the conversations will be about different things. With stable interfaces, teams can use each other's capabilities without lining up every release. So they talk about the API structure and functionality because someone still needs to own those interfaces, check compatibility and talk through changes as needs evolve. If you find the same teams having to change their code together again and again, that's usually a sign the boundary is in the wrong place, or that the shared piece needs a product owner of its own.
Stream Teams will never really be autonomous. Our code base is too tangled and we will always share code and release together
Plenty of established code bases are tangled, so you're in good company, and you don't need to untangle everything before you start. Pick one customer journey and look at which changes currently need coordinated edits, shared environments or joint releases. Domain mapping helps you find a boundary that is realistic, and from there you can improve the interfaces, tests and deployment a step at a time. It also helps to know that sharing a repository doesn't stop a team from owning its part of it. Agree how much you're willing to invest, and check that waiting is going down before you extend the approach.
Do we need to duplicate every shared function?
No. Capabilities that many teams reuse can be offered by Internal Product Teams, and Enabling Teams can build skills across several teams at once. The useful question to ask about any connection between teams is whether it helps a team act, or whether it keeps making the team wait.
All common objections ↗