Flowstate - Team topology & structure

The job

Someone in your leadership team just came back from a conference. They’ve read Team Topologies or watched a talk about the Spotify model and now they want to reorganise. Everyone’s getting new names. Squads. Tribes. Platform teams. There’s a slide deck with coloured boxes and dotted lines. It’ll take three months to implement and six months before anyone can ship anything useful again.

I’ve watched this play out at least a dozen times. The re-org happens, people shuffle desks (or Slack channels), there’s a brief period of optimism, and then the exact same delivery problems re-emerge — because the structure wasn’t the problem. The incentives were. The dependencies were. The lack of clear ownership was.

Team topology is the discipline of organising people so they can deliver outcomes without tripping over each other. Not because a book told you to, but because your current structure is actively preventing you from shipping what the business needs. When it’s done well, teams have clear ownership, minimal dependencies, and the autonomy to make decisions without three levels of approval. When it’s done badly, you’ve just rearranged the deck chairs and burned six months of goodwill.

Why it matters

The cost of getting structure wrong is invisible until it isn’t. It shows up as missed deadlines that nobody can explain. It shows up as two teams building slightly different versions of the same thing. It shows up as a queue of pull requests waiting for a review from a team that’s booked solid for the next three sprints.

Here’s the thing: your org chart is your architecture. Conway’s Law isn’t a suggestion — it’s an observation about physics. The software you build will mirror the communication patterns of the people who build it. If you have three teams that need to coordinate on every feature, you’ll build a monolith with three layers. If you have autonomous teams with clear boundaries, you’ll build services with clean interfaces.

I’ve seen a 200-person engineering org at a fintech company spend eight months trying to ship a new payments flow. Not because the engineering was hard — it was maybe three weeks of actual coding. But the work crossed four teams, each with different priorities, different sprint cadences, and different product managers. Every handoff was a two-week wait. Every decision needed a meeting with sixteen people in it.

When engineering leaders get structure right, the results are almost embarrassingly good. Teams ship faster. Escalations drop. Engineers stop complaining about “the process” because the process is just… doing their work. You stop hearing “we’re blocked on Team X” in every standup.

What good looks like

Mature practice:

Teams own outcomes, not components. The payments team owns the payments experience end-to-end, not just the payments microservice.
Dependencies between teams are explicit, documented, and minimised. When they exist, there’s a clear protocol for how they’re managed.
Teams can ship to production without waiting for another team’s release cycle.
Team boundaries align with business domains, not technical layers.
Structural changes are infrequent, deliberate, and driven by evidence — not blog posts.

Struggling practice:

Teams are organised around technical layers (frontend team, backend team, database team) and every feature requires coordination across all of them.
Nobody can clearly articulate what each team owns. There are grey areas where bugs sit unfixed because “that’s not our service.”
Re-orgs happen annually, sometimes more frequently, driven by new leadership or new ideas rather than evidence of structural problems.
Teams have backlogs full of work requested by other teams, with no clear prioritisation framework.

The tell is simple: ask three engineers from different teams who owns the checkout experience. If you get three different answers, your structure is broken.

The approach

Understand the four team types

Matthew Skelton and Manuel Pais gave us genuinely useful language for this in Team Topologies. Not because you need to adopt their framework wholesale, but because the taxonomy helps you diagnose what you’ve actually got:

Stream-aligned teams — these are your delivery engines. They’re aligned to a flow of work, usually a business domain or a user journey. A stream-aligned team should be able to take a feature from idea to production without waiting for anyone else. Most of your teams should be stream-aligned.
Platform teams — these exist to reduce the cognitive load on stream-aligned teams. They build internal tools and services that make it easier for delivery teams to ship. Think CI/CD pipelines, developer tooling, observability infrastructure. The key insight: a platform team’s customers are other engineers. If nobody’s using what they build, something’s wrong.
Enabling teams — these are temporary or semi-permanent teams that help other teams adopt new capabilities. They don’t build features. They upskill. A team that helps your organisation adopt Kubernetes, or migrate to a new testing framework, or implement accessibility standards. They work themselves out of a job.
Complicated-subsystem teams — these own genuinely complex components that require deep specialist knowledge. Your machine learning model serving infrastructure. Your real-time trading engine. Your custom compiler. Most organisations have one or two of these at most. If you think you have five, you’re probably wrong.

Diagnose before you prescribe

Before you touch the org chart, map what you actually have. Sit down with your leads and answer these questions honestly:

Where are the queues? Which teams are bottlenecks for other teams? If every feature request ends up waiting in Team Platform’s backlog, that’s a structural signal.
Where are the grey areas? Which parts of your system have unclear ownership? Where do bugs get bounced between teams?
Where does your structure fight your strategy? If the business wants to invest heavily in a new product vertical but your teams are organised around horizontal technical layers, you’ve got a mismatch.
What’s the blast radius of a change? When a single feature requires five teams to coordinate, your boundaries are wrong.

I worked with a company that had a “frontend team” of twelve engineers serving eight backend teams. Every feature sat in a queue waiting for frontend capacity. The fix wasn’t hiring more frontend engineers — it was dissolving the frontend team and embedding those engineers directly into stream-aligned teams. Throughput tripled in two months. Not because anyone worked harder. Because they stopped waiting.

Make changes incrementally

Here’s where most re-orgs go wrong: they try to do everything at once. New teams, new names, new reporting lines, new ceremonies — all on the same Monday morning. It’s a catastrophe every time.

Instead, make one structural change at a time. Move one team’s boundaries. See what happens. Did the dependency go away? Did throughput improve? Did anything break? Learn from it, then make the next change.

A good cadence is one structural adjustment per quarter, maximum. That gives teams time to settle, build new working relationships, and establish new norms before you disrupt them again.

Set team interaction modes

It’s not enough to define teams — you need to define how they interact. Skelton and Pais describe three interaction modes:

Collaboration — two teams working closely together for a limited period. This is expensive and should be time-boxed. “We’re collaborating on the new auth system for six weeks, then we’ll hand ownership to Team Identity.”
X-as-a-Service — one team consumes another team’s output through a clear API or interface. This is the default for platform teams. Low coordination cost.
Facilitating — an enabling team helps a stream-aligned team learn a new capability. Also time-boxed.

Write these down. Make them explicit. When people know how they’re supposed to work together, they stop inventing coordination mechanisms on the fly — which is where all the meetings come from.

Right-size your teams

The research is pretty clear on this: 5-8 people is the sweet spot for a delivery team. Below five, you lack resilience (one person on holiday and you’re stuck). Above eight, communication overhead starts to dominate. Amazon’s two-pizza rule exists for a reason.

If you’ve got a team of fifteen, you don’t have one team. You have two teams pretending to be one, and they’re almost certainly stepping on each other.

The conversations

How you talk about team structure depends entirely on who you’re talking to.

With your teams:

“We’re going to change this because the current structure is slowing you down” — not “we’re implementing a new framework.”
“You’ll own the full delivery path for [domain]. That means you decide how to build it, when to release it, and what quality bar to hit.”
“This change exists to remove the blocker you’ve been telling me about for six months.”

With your peers (Product, Design):

“I want to align our teams to your product areas so you have a single point of contact for each domain.”
“The current structure means every feature you want requires coordination across four teams. I want to reduce that to one.”

With leadership:

“Our current structure creates a coordination tax of roughly [X] weeks per feature. Here’s how I plan to reduce it.”
“I’d like to make one structural change this quarter and measure the impact before we go further.”
Trust-building: “Here’s what I expect to improve, and here’s how I’ll measure it.”
Trust-eroding: “We need a complete re-org” with no evidence, no timeline, and no success criteria.

What to never say:

“We’re adopting the Spotify model” — Spotify themselves have said it didn’t really work like the blog post described.
“This is what [famous company] does” — your company isn’t that company. Cargo-culting someone else’s org chart is a recipe for failure.

Common failure modes

The perpetual re-org. Some organisations restructure every six to twelve months. Engineers stop investing in their team’s practices because they know it’ll all change soon anyway. If you’re restructuring more than once a year, the problem isn’t your structure — it’s your leadership stability.

Component teams masquerading as feature teams. You rename the “backend team” to the “payments squad” but they still only write backend code, and they still depend on the (now renamed) “frontend squad” for every user-facing change. Renaming teams without changing their scope is theatre.

Platform teams with no customers. A platform team that builds infrastructure nobody asked for and nobody uses. Platform teams need to be ruthlessly focused on what stream-aligned teams actually need, not what’s technically interesting.

Ignoring Conway’s Law. Designing a beautiful microservices architecture while your teams are still organised in horizontal layers. The architecture will lose. It always does.

Optimising for individual utilisation. Structuring teams so every person is “fully utilised” across multiple teams. This guarantees context-switching, destroys focus, and ensures nobody owns anything. An engineer at 80% on one team delivers more than an engineer at 100% split across three teams.

Solving people problems with structure. Sometimes the issue isn’t the org chart — it’s that two leads don’t communicate well, or a team has a skills gap, or priorities aren’t clear. Restructuring won’t fix any of that.

Getting started

If your team structure hasn’t been deliberately designed — or if it has been but three years and two CTOs ago — here’s how to start this quarter:

Map your current state. Draw the actual teams, what they own, and the dependencies between them. Not the org chart — the reality. This takes a day, tops.
Identify the top bottleneck. Find the one team or dependency that’s causing the most pain. Talk to engineers, not just leads — they’ll tell you where the queues are.
Design one change. Don’t restructure everything. Fix the one worst structural problem. Maybe it’s embedding frontend engineers into a backend-only team. Maybe it’s creating a platform team to own shared infrastructure that three teams are currently duplicating.
Set a hypothesis. “This change should reduce our average feature lead time from six weeks to three weeks” or “This should eliminate the two-week wait for API changes.” Something you can actually measure.
Implement and measure. Make the change, give it eight weeks, then look at the data. Did it work? What surprised you? What else needs to change?
Communicate the results. Tell your leadership and your teams what you did, why, and what happened. This is how you earn the trust to make bigger structural changes later.

The goal isn’t the perfect org chart. The goal is a structure that lets your teams ship without fighting the system. If your teams can deliver end-to-end, if ownership is clear, if dependencies are minimal — you’re 90% of the way there, regardless of what you call your teams.

Scenario Planning — model the workforce impact of structural changes before you commit.
Roadmap Communication — structural changes affect what you can deliver and when. Your roadmap needs to reflect that.
Building Long-term Credibility — every well-executed structural change builds trust. Every botched re-org destroys it.