How reading Team Topologies gave me a framework for patterns I’d seen across a decade of building software teams.
I recently read Team Topologies by Matthew Skelton and Manuel Pais. It's one of those books where you keep nodding as you read, recognising patterns you've lived through. Over the past decade, I've built up a lot of opinions about what makes teams work and what doesn't. The book gave those opinions a framework, connecting things I'd seen across different teams and organisations.
The book lays out four team types (stream-aligned, enabling, platform, and complicated subsystem), three interaction modes (close collaboration, X-as-a-service, and facilitating), and a core principle: cognitive load should drive how you scope a team's mission. Most of it mapped to things I'd already lived through.
Architecture first, then teams
On one project, a team collaboration product, I was one of the founding engineers and helped decide how the squads were drawn up. Instead of letting the org chart shape the system, we identified the business domains first (messaging, notifications, user profiles, spaces, search) and built cross-functional squads around each. Every squad owned their domain end-to-end: front-end, back-end, deployment. No hand-offs to another team. Microservices were the implementation detail, but the real decision was aligning team boundaries to business domains. The team structure followed from that, not from the org chart.
We didn't call it the reverse Conway manoeuvre at the time. We just knew that if teams formed around the existing hierarchy, the architecture would inherit those same rigid boundaries. Org charts are designed for reporting lines and budgets, not for how software delivery flows. Let teams follow the hierarchy, and that's exactly what you get in the code.
I've also seen the opposite. On another project, what should have been a single coherent product experience was spread across four separate product teams, each with their own reporting line and priorities. Nobody owned the end-to-end user experience. The result was exactly what Conway's law predicts: the architecture mirrored the team splits, not the user's mental model. It's a common pattern in large organisations, not a failure of any individual team, but of a topology that doesn't match the product boundaries.
Cognitive load as a design constraint
Team Topologies puts a name on something that's easy to feel but hard to explain: teams have a finite cognitive capacity, and you should design around it.
On the collaboration product, we had a separate mobile squad rather than embedding a few mobile engineers in each stream-aligned team. If every squad had to hold mobile platform specifics in their heads on top of their domain, the cognitive load would be too high. Not every team member could keep everything in mind, and that's when things start falling through cracks.
I've found this to be a good litmus test. When scoping a team's mission, the question isn't just "what needs to be built?" but "can every member of this team reasonably understand the full scope of what we own?" If the answer is no, the boundaries are wrong.
The enabling team that was one person
The book describes enabling teams as groups that help stream-aligned teams acquire new capabilities. I've seen this work with a single senior person.
A security architect I worked with operated exactly this way. They didn't just produce guidelines. They worked directly with stream-aligned squads, embedding temporarily to help them implement specific security outcomes, whether that was JWT token handling, secret management, or threat modelling. They transferred knowledge, then moved on. That's the enabling model in its purest form: build capability in other teams, don't create a dependency.
From collaboration to service
Three interaction modes: collaboration, X-as-a-service, and facilitating. The thing that clicked for me is that you move through them. I've lived through that evolution in multiple organisations, and it's always the same pattern.
In one organisation, recurring incidents across many services followed common patterns. These weren't individual team failures. They were systemic gaps that no single team had the bandwidth or mandate to solve alone. I led a reliability-focused team to tackle this. Rather than building a centralised response function, I embedded my team with one service team at a time, worked closely alongside them on their biggest reliability gap, and built the fix as reusable tooling from the start. Automated secret rotation, safe infrastructure update workflows, continuous deployment with progressive rollouts, reusable infrastructure-as-code modules for common cloud patterns. Each built as a general solution, validated in one team's environment before others picked it up.
Once a solution was proven in production with a real team, the interaction mode shifted. What started as close collaboration graduated to X-as-a-service: other teams could consume the tooling independently, and get updates on it, with minimal coordination. Without embedding first, we wouldn't have understood the problem well enough to build something that actually worked. Without graduating to self-service, it wouldn't have scaled.
We were strict about quality. Every piece of reusable tooling had documentation, tests, and worked out of the box. If the consumer experience is poor, adoption doesn't happen. Once a few solutions were running in production and engineers across the organisation were joining regular community calls, things started moving on their own. Less personal push needed, more gentle steering.
Much of this work followed an inner source model. We didn't expect many pull requests from other teams, and we didn't get them. Stream-aligned teams have their own delivery to focus on. The real value of inner source was something else: working in the open built trust, attracted like-minded people across the organisation, and grew a community around the topic instead of a top-down mandate. Some of that work eventually became open source.
The collaboration trap
Team Topologies describes close collaboration as an interaction mode for early exploration. Two teams working tightly together to discover something new.
I've seen what happens when this mode is skipped. Sometimes teams skip early collaboration for understandable reasons: time pressure, uncertainty about direction, or wanting to move fast without too many voices in the room. But when architectural decisions get made without involving the teams who'll build on them, the downstream cost is real. People don't feel they "disagreed and committed." They feel they were never part of the conversation. The long-term impact on trust and buy-in is hard to recover from.
The glue between teams
Team Topologies would probably say that if you need someone working the seams between teams, your topology isn't right. Fix the boundaries, clarify the interaction modes, and the need for glue disappears. In theory, that's correct. In practice, even a well-designed topology assumes every team can fully deliver on their mission and will proactively coordinate when needed. Neither assumption always holds.
Some teams lack the skills to match their responsibility, whether through outsourcing, rapid growth, or being assigned work outside their expertise. Others have the capability but not the inclination to reach out. Autonomous teams can become insular, and collaboration doesn't happen just because the interaction mode says it should. Someone ends up bridging those gaps informally: orchestrating work across squads, testing a dependency that needs more attention, connecting things that would otherwise fall through the cracks.
But the glue role isn't only about compensating for gaps. Someone with visibility across multiple teams can spot patterns and risks that are invisible from inside any single boundary. Engineering maturity always varies across teams in a large organisation, and that cross-boundary perspective is how you keep the overall system healthy.
Tanya Reilly calls this being glue and frames it as legitimate technical leadership. Good organisations recognise this work and value the people doing it. Others don't, because it sits outside any team's formal scope, and that's how they lose the people who were holding things together.
Teams shape the people inside them
There's an aspect of team design that goes beyond delivery efficiency. Small, autonomous squads create space for engineers to grow. A squad lead with genuine autonomy and full visibility of their work to the broader organisation gets something that large hierarchical teams rarely offer: real ownership and room to develop. People I brought onto the team grew into leadership roles they wouldn't have got near in a traditional structure, because the squad structure gave them room for it. That was deliberate. How you draw team boundaries shapes careers, not just architectures.
What the book gave me
Team Topologies didn't change how I think about teams. It gave me a shared vocabulary for patterns I'd already seen work, and a clearer understanding of why some structures fail. Cognitive load, interaction modes, Conway's law as a design tool rather than an inevitability. These are the kind of things that turn gut feeling into something you can actually discuss with other people.
If you've spent years building teams, you'll recognise most of this book. It does for organisational design what Design Patterns did for object-oriented software: gives you shared names so you can stop talking past each other.
Top comments (0)