Using Team Topologies to Decide Where Decisions Should Really Live

Many teams adopt the language of Team Topologies: stream-aligned teams, platform teams, enabling teams, complicated-subsystem teams. The diagrams look good. The boxes line up.

But the day-to-day reality feels familiar.

Architects still sign off every major change. Platform decides which services are "allowed". Security is the place where decisions go to wait. Stream-aligned teams carry on escalating decisions to the same central people as before.

In other words, the team structure changed on paper, but the decision structure stayed the same.

We have found Team Topologies most useful not as an org chart tool, but as a way to answer a different question:

For this decision, which team should really own it?

In this article, we look at how to use Team Topologies as a lens on decision-making, the common anti-patterns, and a practical way to realign decisions with the teams that carry the consequences.

A Quick Lens on Team Topologies

We will keep the recap short and focused on decisions.

• Stream-aligned teams own a flow of work for a specific product, capability or user journey. They should be able to make most day-to-day decisions that affect that flow.
• Platform teams provide internal services that reduce cognitive load for other teams. They own decisions about the platform’s interfaces and reliability guarantees, not about each product’s roadmap.
• Enabling teams help other teams adopt new capabilities. They influence decisions through coaching and pairing, not through mandates.
• Complicated-subsystem teams own areas that require deep specialised knowledge (for example, a pricing engine or ML model training). They make decisions inside that subsystem, but coordinate with stream-aligned teams at the edges.

Each team type implies a different sphere of decisions. If the decisions do not match the team’s purpose, friction appears quickly.

The Decisions Hiding in Your Architecture

In a modern system, there are many classes of decisions. For example:

• Product and experience decisions – which features to build, how behaviour should feel for a given user journey.
• Service boundaries and integration decisions – where to split or join services, how they communicate.
• Runtime and operational decisions – deployment cadence, on-call rotation, incident response, SLOs.
• Platform and tooling decisions – what is provided as a shared capability and under what contract.
• Safety and governance decisions – security controls, data handling, compliance and approvals.

If you ask "Who really makes this decision today?", the answer is often:

• "It depends who has time."
• "We escalate to the architect."
• "Platform will have an opinion."
• "Security will tell us if we can."

Team Topologies gives us a principled way to move those decisions closer to the teams that own the outcomes.

Mapping Decisions to Team Types

A useful exercise is to pick a concrete decision and ask two questions:

1. Who makes this decision today?
2. Given our team types, who should own it?

A few examples:

Example 1: Creating a New Service

Today, many organisations require architect or platform approval to create a new service. The intent is good: reduce sprawl and keep a coherent architecture.

But if every new service decision lives outside the stream-aligned team, then:

• Teams have weak ownership of their own boundaries.
• Architectural change queues behind a small group of reviewers.
• Platform subtly becomes a gatekeeper, not an enabler.

Using Team Topologies, we want stream-aligned teams to own the decision to create or reshape services within their domain, within clear guardrails:

• Platform defines what a "ready" service looks like (observability, deployment, security baselines).
• Architecture and enabling teams provide patterns and coaching.
• The stream-aligned team decides when to split or merge, and is accountable for the operational impact.

Example 2: Choosing CI/CD Pipelines

It is common for each team to maintain their own pipelines and ad-hoc scripts. Decisions about how code flows to production are scattered.

Here, a platform team can usefully own pipeline design and evolution:

• They decide which capabilities are available as self-service modules (build, test, deploy, rollback, security scanning).
• They set the default path for how code gets to production.
• Stream-aligned teams decide how to adopt those modules in their context.

If a stream-aligned team is hand-crafting bespoke pipelines, they are making platform decisions by accident. If the platform team insists on approving every job change, they are slowing down product decisions. A clear split helps.

Example 3: Operational Guardrails

Who decides what "good" looks like for availability, latency and error rates?

• If SLOs are decided centrally without input from product teams, they often do not reflect real user impact.
• If each team defines their own standards without any coordination, the system becomes hard to reason about.

With Team Topologies:

• Stream-aligned teams should own SLOs for their user journeys.
• Platform and enabling teams provide templates, practices and shared observability.
• A small set of organisation-wide guardrails (for example, for regulatory or safety reasons) are defined at a higher level, but interpreted by teams locally.

Anti-Patterns: When Decisions Live in the Wrong Place

Certain patterns show up repeatedly when decisions and team types are misaligned.

Architects as Central Approvers

Architecture boards that must approve every significant design decision often start from a good place: preventing chaos.

Over time, they tend to:

• Accumulate a large queue of decisions.
• Be consulted on choices that teams could make themselves with better guidance.
• Encourage risk-averse designs, because nobody wants to be the exception.

A healthier pattern is:

• Architects and principal engineers spend more time with stream-aligned and platform teams, shaping patterns and constraints.
• Most decisions are made where the work lives, inside teams.
• Only a small set of truly cross-cutting decisions require central coordination.

Platform as Gatekeeper

A platform team that can say "no" to every change, but cannot clearly say "yes" to a paved path, becomes a bottleneck.

Signals:

• Tickets to "get onto the platform" stay open for months.
• Teams build shadow paths because the official one is too slow.
• Platform roadmap is driven by interrupts, not by a clear strategy.

Using Team Topologies, we want platform teams to:

• Own the platform product and its contracts.
• Offer clear self-service paths with well-defined boundaries.
• Collaborate with stream-aligned teams on feedback and improvements.

The decisions about product behaviour and release cadence should stay with stream-aligned teams.

Enabling Teams as Permanent Owners

Enabling teams are meant to be temporary partners who raise capabilities and then move on. When they permanently own a domain, they become a parallel architecture group.

A better pattern:

• Enabling teams help define decision frameworks and practices.
• Stream-aligned teams own the decisions once they are capable.

A Practical Workshop: Surfacing Decision Mismatches

You do not need a full reorganisation to use this lens. A simple workshop with a few teams can reveal a lot.

1. List 10–15 recurring decisions.
   • Examples: creating a new service, choosing a database, changing an SLO, adding a new integration, introducing a new runtime.
2. For each decision, capture who makes it today.
   • Individual? Team? Committee? Platform? Architecture group?
3. Classify each decision by impact and frequency.
   • High-impact, frequent decisions living far from the work are strong candidates for change.
4. Overlay Team Topologies.
   • For each decision, ask which team type should own it in your context.
5. Design one or two small experiments.
   • For example, delegate a class of decisions to a stream-aligned team with clear guardrails, and review after a couple of sprints.

The goal is not to centralise or decentralise everything. It is to be deliberate.

Keeping Decision Flows and Team Flows in Sync

Organisations evolve. New products appear, regulations change, teams are split or merged. A healthy system periodically checks whether decision flows still match team flows.

Some signals that they do not:

• Frequent escalations to a small set of people, regardless of topic.
• Decisions being revisited repeatedly, because the "real" decision-makers were not involved.
• Incidents where nobody feels they had the authority to act early.

Using Team Topologies as a shared vocabulary helps:

• Expose where decisions are currently stuck.
• Give teams a neutral language to discuss ownership without turning it into a personal or political debate.
• Align incentives: the team that lives with the outcome should make the decision, within clear organisational constraints.

Questions to Ask About Your Own System

To use this lens in your context, you can start with a few questions:

• Where do product and architecture decisions really live: with stream-aligned teams, or somewhere else?
• Which decisions does your platform team truly own, and which are they holding by accident?
• Are enabling teams coaching others into better decisions, or becoming another approval layer?
• For high-impact, frequent decisions, is the decision-maker close enough to the work to see real trade-offs?
• What is one class of decisions you could move closer to a stream-aligned team in the next quarter, with clear guardrails?

Team Topologies does not magically fix organisational politics. But used as an explicit lens on decision-making, it helps us design systems where responsibility, authority and consequences line up – and where teams can move faster without losing control.