Common Team Topologies implementation mistakes
Platform teams, Conway's Law, and cognitive load.
👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.
Team Topologies has become the organisational design bible for engineering teams. Matthew Skelton and Manuel Pais created an elegant framework that promises to solve everything from Conway’s Law to cognitive overload. But after analyzing implementations from 2024-2025, I’ve discovered that there is a gap between their polished theory and reality.
While the framework offers genuine insights about cognitive load and team interactions, I can see that when trying to implement them in practice there are loads of expensive failures that people rarely discuss. If you’re considering a Team Topologies transformation (or you’re already in the middle of one) you need to understand what’s actually proven to work.
CodeRabbit CLI brings instant code reviews directly to your terminal, seamlessly integrating with Claude Code, Cursor CLI, and other AI coding agents. While they generate code, CodeRabbit ensures it’s production-ready - catching bugs, security issues, and AI hallucinations before they hit your codebase.
Thanks to CodeRabbit for sponsoring this newsletter!
The Platform Team
The most damaging misconception about Team Topologies is that creating platform teams automatically accelerates delivery. In practice, more often than not platform teams become the very bottlenecks they were designed to eliminate.
The pattern is frustrating. Organisations establish platform teams with mandates to “enable” product teams. Often, these platforms become control centers enforcing standards that nobody asked for while ignoring actual developer pain points.
A friend of mine VP of Engineering told me:
As soon as you put a platform team in charge with a mandate, what they build and what is needed starts diverging in the name of “long-term planning”
When platform teams lose connection with their users (the developers they’re supposed to serve) they begin operating like there are no customers at all, rolling out surprise changes that teams learn about through error messages.
I am not suggesting here that platform teams shouldn’t exist (in fact I am managing one myself). What I am hinting at is that they should be treated as a product.
Platform teams should have product managers, user research, and adoption metrics to serve their customers (interesting research on platform teams from 300 orgs). Docker’s turnaround to $50M ARR and Footasylum’s jump from 6 releases per year to 1,250 deployments per week both involved platform teams that obsessed over developer experience.
Without this product mindset, platform teams cost organisations millions. And that’s real money.
Conway’s Law
Team Topologies promotes the “Inverse Conway Maneuver” - deliberately restructuring teams to create desired architecture. But this rests on a logical fallacy.
Just because teams that can’t communicate create messy interfaces doesn’t mean creating organisational boundaries will force good architecture.
To add to this, the framework’s approach of building walls between teams to force modularity directly contradicts DevOps principles of breaking down silos.
These intentional communication barriers often hide important context teams need to make good decisions. The “unintended communications” Team Topologies tries to eliminate frequently reveal actual user needs and system dependencies.
I’m not saying organisational structure doesn’t influence architecture, it absolutely does. But using Conway’s Law as an organisational design tool requires far more nuance than the framework suggests.
Scale
I believe that Team Topologies works brilliantly for organisations between 50-200 engineers. Apply it outside this sweet spot, and you’re asking for trouble.
Startups under 50 people attempting Team Topologies waste precious time when they should be focusing on value generation. You don’t need stream-aligned teams when your entire company could fit in a large conference room.
Orgs with over 500 people find the four team types insufficient for their complexity, leading to awkward hybrid structures that satisfy neither Team Topologies purists nor practical needs.
The framework shows its best results in mid-size companies making specific transitions. PureGym improved team health metrics significantly by moving from short-lived project teams to stable product teams.
But context matters enormously - orgs with embedded systems, hardware components, or non-web products find Team Topologies’ web-app-centric assumptions completely misaligned with their reality.
Cognitive Load
Team Topologies’ focus on reducing cognitive load resonates with engineers, but the implementation can be a little be patronising. The authors reference a 1988 problem-solving paper that doesn’t actually support their organisational claims, then use it to justify treating experienced engineers like children with limited capacity.
My view is that:
You need your best engineers understanding the full system context, not operating in carefully controlled bubbles.
More importantly, the framework ignores that different engineers have vastly different cognitive capacities and preferences. Some thrive on broad system understanding while others prefer deep specialisation. Forcing uniform cognitive load limits across teams ignores individual strengths and creates artificial constraints on high performers.
Your implementation playbook
If you decide to implement Team Topologies, here’s what I recommend:
Start small. Begin with one pilot team, not a big-bang re-org. Test the concepts, measure the results, and learn before scaling.
Hire platform product managers. Platform teams without product discipline will get disconnected from user needs.
Measure developer experience, not just DORA metrics. Deployment frequency means nothing if developers hate their tools.
Prepare for reality. Implementation takes 2-3x longer than expected. Budget for extensive coaching and enablement. You’ll probably have to create a hybrid model, not pure Team Topologies.
Invest in change management. Technical frameworks fail because of people problems, not technical problems. Get your change management right.
Final thoughts
Team Topologies offers valuable vocabulary for discussing team interactions and cognitive load, but it’s not the organisational silver bullet many believe. The gap between its elegant diagrams and organisational reality requires senior engineering leaders (CTOs & VPs) to approach it with eyes wide open.
Success comes not from implementing Team Topologies but from understanding which problems it actually solves and having the organisational maturity to apply its insights selectively. The framework’s greatest contribution may be starting conversations about team effectiveness and cognitive load.
Focus on gradual evolution, context-specific adaptation, and remembering that no framework, however popular, substitutes for understanding your unique organisational dynamics and constraints.
The best organisational design remains the one that fits your specific context, not the one that worked for someone else’s conference talk.
That’s all, folks!
See you in the next one,
~ Stephane