Designing for Flow
How We’re Restructuring Our Teams Using Team Topologies
The Starting Point - Functional Teams, Local Efficiency, Global Friction
Before our reorganization, our teams were structured functionally.
We had a backend team, a frontend team, a DevOps team… and each one was excellent in its own domain.
At first glance, it worked well.
From a local optimization perspective, this setup offered many benefits:
focused skills and shared tooling,
strong peer reviews within each discipline,
deep learning loops in each area of expertise.
But over time, something started to feel off.
Every delivery required coordinating three or four teams.
Product features moved through phases like a mini-assembly line.
And no one was responsible for the outcome, just for their "part."
It was efficient in the small. But fragile and fragmented at scale.
As our platform grew, the cracks became more visible:
delays caused by handoffs and unclear priorities,
decisions stalled in cross-team meetings,
teams pulled in different directions by multiple stakeholders.
We were moving fast, but the flow was broken.
And we started asking ourselves a hard but necessary question:
What would it look like to design the organization around value, not just functions?
The Problem - Structure Becomes a Bottleneck
The people don’t cause most organizational issues; they’re caused by how we’ve arranged the work.
If a team needs to align with three others just to ship a change, it’s not autonomous.
If no one owns the full lifecycle of a feature, no one truly learns from its results.
If priorities conflict across silos, execution slows, and so does accountability.
The structure itself becomes the bottleneck.
That’s what we were seeing.
We had good teams doing good work, but the system around them wasn’t enabling flow.
The Shift - Rethinking Team Boundaries Using Team Topologies
When we identified our business value streams (see the previous article), we finally gained a clearer understanding of the problem in context.
We were organizing teams around skills, while the product required cohesive problem-solving across domains.
So we started to rethink our structure using the principles of Team Topologies:
not as a strict model to apply, but as a lens to observe and design around flow.
Here’s how we approached it:
✅ Stream-Aligned Teams
We aligned teams with specific value streams, so they could own end-to-end delivery of product capabilities, both tech and customer outcomes.
🧭 Clear Boundaries
We reduced overlap between teams by defining bounded contexts, each with its own backlog, roadmap, and metrics.
🤝 Support Roles
We introduced enabling roles to support team evolution where needed (e.g., DevOps, DevSecOps, platform, security, data), rather than centralize decision-making.
🔄 Interaction Modes
We defined how teams interact:
X-as-a-Service for reusable infrastructure,
Collaboration for cross-domain initiatives,
Facilitation for coaching and onboarding.
This gave us a shared vocabulary to reduce friction and increase clarity.
How We Did It
The transformation didn’t happen overnight.
We started with a simple premise:
Each team should be able to deliver value independently, within their domain.
From there:
we mapped our major value streams,
created cross-functional teams with full-stack capabilities,
assigned clear product and technical OKRs aligned with company-level goals,
and enabled them to work in autonomy, with support from platform and enabling teams.
Importantly: this wasn’t about “splitting the monolith.”
It was about splitting responsibility, so that each team could own, learn, and improve within their domain.
📌 What changed:
more effective meetings,
clearer product ownership,
more visible outcomes,
and stronger motivation from within the teams.
Because when teams are responsible not just for tasks, but for outcomes, something shifts.
They stop waiting for direction.
They start driving value.
Conclusion - You Design for Flow, or You Design for Friction
An organization is part of the architecture. And it’s either helping you or slowing you down.
We’re still learning. We’re adjusting.
But today, our team structure mirrors our product structure and strategy, and that has made all the difference.
Team Topologies gave us language, concepts, and clarity to design our organization with intention, not just history.
And most of all, it helped us stop fighting the structure - and start focusing on value.
What’s Next: From Teams to Strategy - Aligning Tech with Product
Redesigning team structures is just one side of the coin.
The other is making sure that, once autonomous, teams know where they’re going, and why.
In the next article, we’ll explore how we’ve been working on a Tech Strategy that doesn’t live in a slide deck, but actually guides everyday decisions.
We’ll talk about:
why every tech strategy needs to be paired with a clear product vision,
how to co-create direction across tech and product,
and what it takes to move from “we need this tech” to “this tech makes our vision possible.”
📩 If this sounds like the challenge you're facing right now, you're not alone. We’ll dive into it next time.