Team Topologies Meets Enterprise Reality
- Darren Emery
- May 26
- 5 min read
Why great teams don’t start with structure — they start with flow.
"In preparing for battle, I have always found that plans are useless, but planning is indispensable."
- Dwight D. Eisenhower
Organisational design is not a static artefact. It’s a living system.
Yet when most enterprises talk about "team design," they inevitably default to reorganising the org chart - lines, boxes, reporting relationships.
As if moving names around in Excel or Powerpoint will somehow conjure flow, speed, and outcomes.
The reality?
You cannot manage your way to flow with an org chart. You must design for it.
In this article, we’ll explore how the interesting principles behind Team Topologies meet the real-world constraints of the modern enterprise - and what to do when you can't simply redraw the org to fit the theory.
Why Team Topologies Became a Movement
When Matthew Skelton and Manuel Pais published Team Topologies in 2019, it resonated because it captured a universal truth: Organisations get the performance they design for - even if it’s by accident.
Team Topologies formalised a few critical patterns:
Four fundamental team types: stream-aligned, enabling, complicated subsystem, platform.
Three interaction modes: collaboration, X-as-a-service, facilitating.
Clear team boundaries, sized for cognitive load, not HR convenience.
Dynamic evolution based on the Organisation's needs.
But while the model is elegant, applying it inside large, traditional enterprises is messy.
Constraints aren’t just technical. They’re political, historical, financial, emotional.
Which brings us to the first major truth of enterprise design for flow:
👉 In reality, you must often work around the org chart to achieve flow, not through it.
When Not to Follow the Org Chart
In many organisations, the org chart represents:
Career hierarchies
Budget control
Historic team compositions
Territory claims
It does not represent:
Flow of work
Logical system boundaries
Necessary collaboration paths
Cognitive load realities
In fact, Conway’s Law ("any Organisation that designs a system will produce a design that copies the Organisation’s communication structure") isn’t just an observation - it’s a diagnosis. If you structure for silos, you’ll ship silos.
If you chase the org chart, you will reinforce existing dysfunctions.
Instead, reality-based leaders do something smarter:They design for flow of work first, org chart second.
They map the actual product or service architecture.
They look at real-world handoffs and dependencies.
They respect cognitive load instead of ignoring it.
They optimise communication paths, not management lines.
Because your customers don’t care what your org chart says.They care whether you can deliver.
Top 5 Blockers to Org Design That Supports Flow
Real-world enterprises trying to move toward a Team Topologies approach often encounter these major blockers:
Hero culture: Rewarding firefighting over building sustainable systems.
Matrix management confusion: Dotted-line chaos kills ownership clarity.
Legacy platform entanglement: Systems that can’t be decoupled easily without massive investment.
Political turf wars: Leaders optimising for headcount, not outcomes.
Rigid HR frameworks: Titles, pay bands, and career paths that don't flex with team purpose.
Recognize these early.They aren't just roadblocks; they are signals about where the system resists flow.
The goal isn’t to steamroll through them - it’s to design smart paths around or through them, with eyes open.
Who Owns Team Boundaries?
Here’s a powerful question every executive should ask:
Who in your Organisation actually owns the decisions about team boundaries?
Is it HR?
Is it Engineering or IT leadership?
Is it Enterprise Architecture?
Is it the business unit leads?
Or worse… is it no one?
In high-performing organisations, the product or service architecture dictates boundaries.
Leadership exists to support and reinforce these boundaries, not ignore or override them.
When no one owns this?
You get blurred ownership, unclear decision-making, death by coordination.
When You Can't Restructure
Sometimes, you can't immediately restructure for flow.
Maybe the politics are too tricky.
Maybe the reorg approval cycle is slow-moving and heavily bureaucratic.
Maybe external dependencies (like outsourced teams) create immovable walls.
What then?
👉 Focus on service boundaries, not squad names.
A few pragmatic moves:
Define clear APIs (technical and human) between teams.
Make "X-as-a-Service" a real thing, not a buzzword.
Minimise coordination overhead for teams working on different streams.
Champion autonomy within service boundaries, even if reporting lines don't change.
Behaviours shape structure. Often, you can behave your way into a better structure before you can formally change it.
And once the behaviours are embedded, the structure tends to follow.
Rethinking Team Types
While stream-aligned teams get all the headlines, don’t overlook:
Enabling teams that help others learn and adopt new practices.
Complicated subsystem teams that manage complex technical areas too intricate to scatter across multiple squads.
Platform teams that offer clear, stable internal services and free up others to focus on value delivery.
Most orgs badly underinvest in enabling and platform teams.
If you think every team must "own their whole thing end-to-end," you’ll overwhelm them.
Not every team should be directly exposed to customer demand.
Some teams should be invisible but vital - like the heart, pumping blood quietly.
Beyond Team Topologies: Toward Real Adaptivity
Team Topologies gives us a brilliant operating model - but it’s not the final form.
True enterprise adaptivity demands moving beyond fixed structures altogether.
Numerous case studies have shown that in adopting Team Topologies:
· Teams became better aligned with flow.
· Bottlenecks were reduced.
· Communication improved.
But the next step is even more profound:
👉 moving towards dynamic, work-driven team formation.
Put simply:
✅ Start with clearer static teams to stabilise flow.
✅ Graduate toward dynamic team formation to maximise adaptivity.
The Enterprise Reality Check
If you take one idea from this article, let it be this:
Good Organisational design for flow is a continuous act of discovery - not a one-time reorg.
Team Topologies gives us a brilliant direction, but the highest performing organisations use it as a foundation, not a ceiling.
Successful enterprise leaders:
Understand Conway’s Law - and intentionally shape communication and ownership.
Respect cognitive load and design teams around what humans can actually handle.
Prioritise flow over structure, and customer outcomes over career empire building.
Evolve structures iteratively around changing needs, not through annual revolutions.
Or as General Martin Dempsey (former U.S. Joint Chiefs Chairman) put it:
“The best organisations don’t merely react to change - they are designed for it.”
Quick Recap for the Busy Executive
✅ Org charts are not system design.
✅ Structure around flow, not titles.
✅ Define boundaries early, not roles late.
✅ Start with service-aligned teams; move toward dynamic teaming.
✅ Team Topologies is a stepping stone, not a destination.
🧠 Organisational flow isn't built once.
It’s cultivated, protected, and evolved - every day.
