You’ve probably seen it: a reorganization rolls out, someone draws new boxes on a chart, and within months the same coordination problems resurface — just wearing different names. The issue isn’t that the structure was wrong. It’s that nobody asked the right questions before drawing those boxes.
I recently read Team Topologies by Matthew Skelton and Manuel Pais, and it crystallized something I’ve felt across the last years of leading teams and building software: team structure isn’t a template you copy. It’s a design decision — and like all design decisions, it comes with trade-offs.
Stop Looking for the “Right” Answer
The most liberating idea in Team Topologies is also the most uncomfortable one: there is no universally correct way to structure teams. The book gives you a vocabulary — stream-aligned teams, platform teams, enabling teams, complicated-subsystem teams — but it doesn’t hand you a blueprint. And that’s intentional.
There’s No Perfect Team Structure (And That’s the Point)
I’ve seen teams organized by feature, by component, by customer segment, and by technology layer. Every single one of those approaches worked somewhere and failed somewhere else. The difference was never the pattern itself. It was whether the pattern fit the context.
It Depends (No, Really)
“It depends” gets a bad reputation in engineering. It sounds like a non-answer. But when it comes to team structure, it’s the only honest starting point. What it depends on is worth spelling out:
Company stage and size. A 20-person startup where everyone knows each other has radically different coordination needs than a 500-person engineering org. Structures that enable autonomy at scale create unnecessary overhead when you’re small. Conversely, the informal “everyone talks to everyone” approach that works at 15 people becomes a bottleneck at 50.
Culture and trust. Some organizations have deep trust between teams and can handle loose boundaries. Others need explicit interfaces and clear ownership to function. Neither is inherently better — but picking a structure that assumes trust where none exists is a recipe for conflict.
The nature of the work. A product with a single monolithic codebase demands different team boundaries than a distributed system with clear domain boundaries. Team Topologies pushes you toward aligning teams with the flow of change, which is powerful — but only if you understand where change actually flows in your system.
Cognitive load. This is the concept from the book that stuck with me most. And probably something every seasoned software engineer can relate to. A team’s structure should respect what a group of humans can reasonably hold in their heads. If your team needs to understand three different domains, two infrastructure layers, and a legacy integration just to ship a feature, your boundaries are in the wrong place — no matter how clean the org chart looks.
What Makes a Good Cut?
If there’s no universal answer, how do you evaluate whether your team structure is working? Here are the criteria I’ve found most useful, both from the book and from my experience:
Teams can ship independently. The strongest signal of a good structure is that teams can deliver value without waiting on each other for every change. If your “independent” teams need three other teams in a room to release anything, you have a coordination problem disguised as autonomy.
Boundaries match real dependencies, not imagined ones. Draw the actual dependency graph of your system — not the one on the whiteboard, the one developers experience daily. Good team boundaries minimize cross-team dependencies. They don’t eliminate them (that’s impossible), but they make the remaining ones explicit and manageable.
Communication patterns are intentional. Team Topologies introduces the idea that team interactions should be deliberately chosen: collaboration, X-as-a-Service, or facilitation. In practice, this means asking “how should these two teams interact?” before problems force an answer. Most orgs skip this step and wonder why friction builds up.
People aren’t drowning. Come back to cognitive load. If a team is constantly context-switching between unrelated concerns, the boundaries need to move. This isn’t about comfort — it’s about sustainable pace and quality of decisions.
Structure Is a Living Thing
The biggest mistake I see isn’t choosing the wrong structure. It’s treating structure as a one-time decision. Your product evolves, your team grows, your technical landscape shifts. The team structure that was perfect eighteen months ago might be actively harmful today.
Team Topologies gave me a shared language to have these conversations — and more importantly, a framework to keep having them. The goal isn’t to find the perfect structure and freeze it in place. It’s to build the habit of asking: do our team boundaries still serve the way we need to work?
If you take one thing from this: don’t copy someone else’s org chart. Understand your own constraints, optimize for flow, respect cognitive load, and be willing to evolve. The best team structure is the one that makes your specific context work—right now.