Design teams around a flow of value. Team Topologies, by Matthew Skelton and Manuel Pais, gives four team purposes, three ways for teams to work together, and one limit to protect: how much a team can hold in its head.
Team types
Start with one customer outcome. Give a stable, stream-aligned team responsibility for building, operating, and improving that slice of work, then identify the support it actually needs.
Example: An order-tracking team owns the customer experience. A platform offers deployment tooling. An enabling team coaches observability. A complicated-subsystem team might own a genuinely specialist prediction engine.
These are different support purposes, not a sequence of delivery handoffs. An ordinary shared component does not automatically need a complicated-subsystem team.
Interaction modes
Make each working relationship explicit: discovering together (collaboration), consuming a service (X-as-a-Service), or receiving help to become more capable (facilitating). A team can use different modes with different partners. Give collaboration a purpose and a review date so that temporary discovery doesn’t become a standing dependency.
Cognitive load
A team must be able to understand the work it owns. Tools, domains, and responsibilities all consume that capacity, even when the backlog looks manageable. Ask the team: What must we keep in our heads to make a safe change? Then remove one burden: move unrelated work to a clear owner, offer a supported path, or put a specialist system behind a usable interface.
First decision
Choose one team and write its purpose in a sentence. Can it deliver a useful change without passing ownership through several departments? If not, investigate the boundary or dependency before renaming teams.
Related: Conway’s Law