Team Topologies in the Real World
This month, some of my fellow CNCF working group colleagues will be sharing their thoughts on the topic of “Team Topologies in the Real World”. This is part of a new Content Club initiative, where each month we’ll choose a new topic to focus our efforts around. Content Club is open to everyone, so if you’d like to join us, pop by the #content-club CNCF Slack channel.
Other contributions in this series that you might like include:
Steve Fenton wrote this great piece about his real-world experiences of applying Team Topologies in a Product & Data team.
Matt Menzenski explores the parallels between Team Topologies and Deep Work - two excellent books.
Graziano Casto reminds us that while technical advances are important, the key to successful software development lies in how we organize and enable teams to work together effectively.
What is Team Topologies?
If The Pheonix Project was the book that brought DevOps to life, then Team Topologies is the book you need to truly understand Platform Engineering. Rather than organising teams around technology or business function, Matthew Skelton and co-author Manual Pais advocate for team patterns that optimise for the flow of change and minimise cognitive burden. The book introduces four fundamental team types: Stream-aligned, Platform, Enabling, and Complicated Subsystem teams.
“Every organisation is doing Team Topologies, they just might not know they are.” - Stephen Walters
In this article, we’re going to take a closer look at the role of the Platform Team and I’ll share my observations from working with organisations from across industries, highlighting the good, the bad and the ugly!
The Purpose of Platforms
The core purpose of the Platform Team is very simple: enable stream-aligned teams (e.g. developers) to deliver faster by reducing their cognitive load. Platform team should absorb the complexity that would otherwise burden development teams, reducing cognitive load.
This is achieved by providing a set of internal self-service capabilities (i.e. an Internal Developer Platform) that can be consumed by other teams, without needing to understand the implementation details. The platform team is user-centric, listening carefully and curating feedback to improve the platform in ways that deliver the most improvement for users.
Having a great platform is very similar to running a successful restaurant. The platform team brings in ingredients from various suppliers, mixes them together into something tasty, and provides an environment to enhance the customers consumption. You could try making the same dish at home, but it’ll take you longer, won’t taste quite as good, and you’re left with a pile of dishes to do afterwards!
Of course, the trouble is that technology teams have a tendency to see all problems through the lens of technology. A restaurant could have the best ingredients, but can fail if nobody likes the menu or the service is crummy. I wrote about this a few months ago in one of my most popular articles that posed the question is Platform Engineering in Danger? Whether it is Agile, DevOps, SRE, or some other new innovative way of working, we inevitably seem to get distracted by tooling and forget that these advancements are about helping people work better together.
Three Signs Your Platform Team Has Lost Its Way
I’ve had the honour of working with some of the innovative companies across the UK and Europe, giving me a front-row seat to see how different organisations have approached the same challenges. What’s evident to me is that when things aren’t going well, technology is rarely the problem, and most problems can be attributed to the same three common human factors.
1. Misaligned Priorities
In most of the organisations I’ve worked with, the platform team will generally report up through the CIO or CTO. Meanwhile, development teams that are expected to use the platform report through various business-related functions. An Internal Developer Platform is an ideal solution to help bridge that gap, but it’s important to recognise that development and platform teams will often be pulled in different directions by their leadership teams.
This problem is particularly prevalent in organisations where the funding for IT is accounted for centrally, rather than cross-charged to departments based on their usage. And it gets worse where the use of specific platforms is mandated.
When platform usage is mandated and costs are centralised, platform teams lose the most crucial feedback mechanism any product team needs - the voice of the customer expressed through their choices.
Platform teams can have a difficult time convincing their management of the importance of developer experience, instead being pushed toward traditional governance and control measures. While these measures might satisfy IT audit requirements, they can severely impact development team velocity. The result is predictable: development teams, under pressure to deliver business outcomes quickly, create workarounds or turn to "shadow IT" solutions.
Breaking this cycle requires platform teams to stay laser-focussed on the needs of their “customers”. They must find new and innovative ways of implementing sufficient safeguards to meet governance requirements that don’t unnecessarily impede velocity. E.g. if a manual approval step rarely results in rejection, then what value does it serve, and could it be replaced by automation or converted into a retrospective review process instead.
2. Communication Breakdown
I’m not sure why, but technology teams seem to have an inherit fear of speaking with people that specialise in another discipline. Team Topologies goes into great detail about social cohesion and group dynamics, noting that natural tribalism can lead into “communication silos” where teams become hesitant to interact with other disciplines, develop their own jargon and practices, and begin to form a "them" and "us" mentality.
When I start working with a platform team, the first question I ask is how they prioritise their work and what mechanisms they have in place to collect feedback. It’s depressingly unusual for platform teams to have regular feedback sessions, a “voice of the developer” program to influence platform roadmaps, or a clear set of business objectives that tie platform team success to developer team outcomes.
The business impact of a platform team is directly proportionate to the quality of their user feedback loops.
One my most favourite parts of the Team Topologies book was the authors opinions on what platform teams should be called. Experience has shown that subtle changes in language can have a profound effect on how we communicate. Many of the platform teams I encounter are centred around the platform that they intend to build, often surrounded by language that implies some level of power or control - e.g. “Core Platform Team”, “Central Platform Services”, etc.
These terms unconsciously promote a sense of hierarch or importance that works against the service-provider / product mindset that platforms should adopt. Instead, Skelton and Pais suggest “outcome-orientated naming” that reflect the desired outcomes and reinforce that the platform team exists to serve and enable others - e.g. “Developer Experience Team”, “Developer Enablement Platform”, etc.
Similarly, in this article you will see that I often refer to the users of a platform as “customers”. It was a topic of some contention when I led platform engineering at Sky TV, but it had an immediate and significant change in the way my teams thought about and communicated with users of the platform.
3. Poor Developer Experience
I said earlier that a restaurant could serve the best food in town, but the business will fail if service is slow or the front of house staff are rude. When I’ve been hired to help a platform team struggling to grow their adoption, it is very rarely a lack of technical capability. The problem is that using their platform isn’t fun.
Developer experience is about understanding that every interaction with your platform either adds to or reduces a developer's cognitive load.
Platform teams often focus heavily on what their services do, building feature-rich solutions that tick all the technical boxes. However, how these services work from a developer's perspective is equally, if not more, important.
Platform Engineering is about making the complex appear simple, about turning what could be a hundred small decisions into a handful of meaningful choices. Great platform teams obsess over error messages that guide rather than confuse, documentation that answers questions before they're asked, and interfaces that feel natural and intuitive. They understand that their success isn't measured by the complexity they can build, but by the complexity they can hide.
Get Your Platform Back On Track
The success of a platform team isn't measured by the sophistication of their technology stack or the number of features they deliver - it's measured by how effectively they enable other teams to deliver business value. Team Topologies provides a clear framework for understanding this relationship, emphasising that platform teams exist to reduce cognitive load and accelerate delivery across the organisation.
My top tips to level up your platform team:
🎯 Measure your success by developer velocity and platform adoption.
🤝 Every feature should have a customer champion.
🚀 Make the right way the easy way.
What makes Team Topologies particularly powerful is its recognition that technical excellence alone isn't enough. The book's insights about team interaction patterns, cognitive load management, and organisational dynamics provide a blueprint for building platforms that truly serve their users. Whether you're just starting your platform engineering journey or looking to improve an existing platform, Team Topologies offers invaluable guidance on creating team structures that optimize for flow, reduce cognitive load, and enable fast and reliable software delivery.
In short, go read the damn book, alright! You can thank me later!