The Journey to Stream-Aligned Team: Seeing Team Evolution Through Interactions, not Labels

16 Jan

For a long time, I’ve found John Cutler’s Journey to Product Teams infographic useful as a way of making sense of different ways of working. It visualised different patterns of team interaction — waterfall, agile with a release silo, feature factory, product team — and, importantly, helped people recognise that not all “agile” teams were operating under the same conditions. The work captured the interaction patterns teams tend to fall into, with those interactions expressed through the language of practices and process.

The underlying insight was powerful: the closer a team gets to owning a problem end-to-end, the more effective it can be.

Over time, however, “product team” thinking arguably created a subtle misunderstanding. It led organisations toward the idea that teams own a product, when in reality what they are owning is a value stream — often spanning multiple products, services, and touchpoints. But the essential point still holds: teams that perform best have autonomy over the full flow of work needed to meet user needs.

Recently, I started wondering what if we re-expressed that same journey, not in terms of practices or process labels, but purely through team interactions? That question led to some interaction models I've created to try to articulate the Journey to Stream-Aligned Team.

Why naming teams isn’t enough

Giving teams names can be useful. It helps people recognise patterns and diagnose problems. But one thing I see repeatedly is organisations renaming their teams — “we’re stream-aligned now” — without changing the behaviours, interactions, or capabilities required to actually operate that way. The label changes, but the interaction landscape doesn’t.

A team can call itself stream-aligned while still relying on handovers, approvals, release gates, or specialist bottlenecks that fundamentally prevent end-to-end ownership. The idea of stream alignment isn’t wrong, but the conditions needed to support it haven’t been created.

A reference map: translating the journey into interactions

The first model is a reference map, a translation of John Cutler’s journey into Team Topologies interaction language. His infographic already surfaced interaction patterns such as internal and external handovers; it did so by naming the processes and practices teams tend to use. Those labels have proven effective because teams can quickly recognise themselves in them.

What this model does differently is make those same interaction patterns explicit, using Team Topologies team shapes and interaction modes as a shared visual language.

By using interaction symbols instead of process labels, the model helps teams see what is actually happening, not just what they call their way of working. It also makes a common anti-pattern easier to spot: teams adopting the name “stream-aligned” without having changed the interaction patterns required to support it.

Journey to Stream-Aligned Team

Framing the journey to a stream-aligned team using the 7 DORA team archetypes

This model uses the same interaction language, but adds the missing context teams usually need: the environmental constraints they’re operating within. It does this using the seven team archetypes described in the 2025 State of AI-Assisted Software Development report from DORA.

Rather than ranking teams using broad categories like low, medium, or elite, the report uses cluster analysis to identify seven team archetypes*** based on observed combinations of delivery performance, system stability, product outcomes, and team well-being.

One of the most useful aspects of the DORA archetypes is that they describe not just outcomes, but the conditions and behaviours teams tend to exhibit. That arguably makes them more helpful than labels that focus primarily on process. I’ve found it much more productive to treat these archetypes as environments, not team identities. Rather than 'being' an archetype, teams operate within an archetypal environment shaped by constraints, interactions, and organisational design.

Reframing familiar team labels

Seen through this lens, familiar team labels start to shift meaningfully:

What might be called a “waterfall team” could map to an environment with foundational challenges. This reframes the issue away from process choice and toward unclear user ownership, functional silos, and handovers that disrupt flow. The interaction model makes those constraints explicit.
An “agile team with a release silo” could map to an environment with legacy bottlenecks. The team may be working iteratively, but lacks control over key parts of the delivery path, limiting its ability to respond and adapt.
A classic “feature factory” often resembles what DORA describes as a stable and methodical team. These teams are dependable and productive, but typically don’t own opportunity selection or requirements shaping, which slows feedback and learning.
At the other end of the spectrum, harmonious high achievers align closely with genuinely stream-aligned teams. They have a clear understanding of the users they serve and, critically, they collectively own all the capabilities required to deliver end-to-end value.

By saying “we’re operating in an environment with foundational challenges” rather than “we’re a waterfall team”, the conversation shifts away from process debates and towards what needs to change in the environment for the team to thrive. That shift is more than semantics; it changes where teams look for leverage.

Team-first capability, not role-based ownership

A core idea featured within these models is team-first capability. Stream-alignment isn’t about having the right specialists present. It’s about the team as a whole taking collective ownership of the capability it exists to deliver.

That means:

no internal handovers between individuals
no single-person bottlenecks
shared responsibility for outcomes, not just tasks

Specialists may still exist within the team, but they are not gates. Knowledge, responsibility, and decision-making are shared so the team can move together. Once a team clearly understands which user needs it exists to serve, cohesion becomes visible. When a team is trying to serve multiple, unrelated user groups, misalignment quickly emerges — and that creates the conditions to reason about whether boundaries need to change.

This is where User Needs Mapping becomes a natural north star: designing teams from the outside in, anchored in the needs they exist to meet (more on that in my next article!)

AI as a capability amplifier

Organisations that succeed with AI tend to have a good handle on their team archetypes and interaction environments — because AI amplifies what’s already there. I explore this in Chapter 7 of my book, User Needs Mapping: Aligning Teams Around What Matters, and it’s a point the 2025 DORA report reinforces from a different angle. Taken together, they suggest that AI adoption is less about introducing new capabilities, and more about exposing the strengths and weaknesses of existing ones.

This is where team interaction modelling becomes particularly useful. By capturing and representing the environmental constraints teams are operating within, we can reason more clearly about where AI is likely to help — and where it is likely to amplify existing dysfunction

For example, adding AI capability to a development team operating in an environment with foundational challenges will often result in local optimisation. The team may produce more output, more quickly, but the rest of the organisation is unable to absorb the increased flow.

Introducing AI into the Build team exacerbates pressure on Test

Similarly, introducing AI-enabled “vibe coding” to a product team operating in an environment constrained by process is unlikely to improve time to value. While ideas and prototypes may be generated faster, the surrounding organisational system — approvals, release mechanisms, dependencies — is not set up to carry that speed through to production.

Introducing AI at Opportunity Selection results in ideas that cannot be delivered

By contrast, organisations operating closer to the pragmatic performer or harmonious high achiever environments tend to make much more effective use of AI. These teams already have a clear understanding of their users, their needs, and the value streams required to serve them. AI is applied in service of existing team-first capabilities, helping teams shorten feedback loops, reduce extraneous cognitive load, and iterate on customer feedback more effectively.

A fully autonomous team with end -to-end capability can make maximum use of AI capabilities

The same tools behave very differently depending on where they’re placed in the interaction landscape. Seen this way, AI adoption stops being a tooling conversation and becomes a question of interaction readiness.

Why I’m sharing this

I’m sharing these models as sense-making aids, not as prescriptions for how teams should be organised.

They’re intended to help teams:

visualise the environment they’re actually operating in
explain why some improvements stall while others suddenly work
reason about what would need to change in order to evolve

If you recognise your team’s archetype, try mapping it using team interaction modelling to explore how your ways of working might evolve. If the models are helpful — to explain a situation, prompt a conversation, or challenge an assumption — please use them, adapt them, and share them. I’m particularly interested in where they don’t hold up.

And if you’d like to talk through any of this, feel free to reach out.

*** The seven DORA archetypes are commonly described as:

Foundational challenges These teams are stuck in survival mode, facing significant challenges with fundamental gaps in their processes, environment, and outcomes.
The legacy bottleneck Teams in this cluster are in a constant state of reaction, where unstable systems dictate their work and undermine their morale.
Constrained by process These teams are running on a treadmill. Despite working on stable systems, their effort is consumed by inefficient processes, leading to high burnout and low impact.
High impact, low cadence These teams produce high-impact work, reflected in strong product performance and high individual effectiveness. However, this is coupled with a low-cadence delivery model characterized by low software delivery throughput and high instability.
Stable and methodical These teams are the steady artisans of the software world, delivering high-quality, valuable work at a deliberate and sustainable pace.
Pragmatic performers These teams consistently deliver work with impressive speed and stability, even if their work environment hasn’t reached a state of peak engagement.
Harmonious high-achievers This is what excellence looks like - a virtuous cycle where a stable, low-friction environment empowers teams to deliver high-quality work sustainably and without burnout.