I’ve lost count of how many times I’ve seen leaders point at the Spotify model as if it were a blueprint.
It never was.
What made this discussion resonate with me is the reminder that copying a visual structure is not the same as designing an organisation for fast flow. Squads, tribes, chapters, and guilds gave the industry a useful vocabulary. They helped people move away from rigid functional silos and toward more autonomous teams.
That was valuable.
But the real work starts where that model stops.
What matters is not whether I can redraw the org chart with modern labels. What matters is whether teams can take an idea from concept to production without drowning in coordination cost. That means I need to think about a few things much more explicitly:
- team cognitive load
- the architectural impact of communication paths
- the kind of interaction teams are having
- how the organisation evolves as the business changes
This is where Team Topologies feels more honest to me. It treats the team as the fundamental delivery unit, not the individual. That sounds simple, but it changes everything.
If a team is the unit of delivery, then there’s a hard limit to how much complexity that team can own. At some point, the software becomes too broad or too tangled for a team to truly understand. And when a team can’t understand what it owns, it can’t improve it quickly, operate it safely, or be genuinely accountable for it.
That’s the conversation many leadership teams still avoid.
We talk about speed, but not enough about cognitive load. We ask teams to own services, platforms, infrastructure, compliance concerns, analytics, and half the business domain besides. Then we act surprised when delivery slows down.
It’s not a motivation problem. It’s a design problem.
The other point I strongly agree with is Conway’s Law. I’ve watched this play out repeatedly at scale: the architecture follows the communication structure whether leaders intend it or not. If my teams are arranged in a way that creates awkward dependencies, the software will reflect that awkwardness. Always.
So org design is not a people-only topic. It’s a product and architecture topic. In some companies, it’s a board-level topic.
Because if my structure limits the kinds of systems I can build, then it also limits the business models I can support.
That’s why I like the emphasis on clear interaction modes between teams. Not all collaboration is good. In fact, too much of it is often a sign that the system is poorly designed.
There’s a meaningful difference between:
- two teams collaborating to discover something new
- one team consuming a capability as a service
- one team enabling another to build a missing capability
Most organisations blur these together. Then everyone wonders why meetings multiply, ownership gets fuzzy, and delivery feels slower than it should.
Clarity matters here. If two teams are collaborating, that should usually be for learning or discovery, not forever. If one team provides something as a service, the consumer experience should be simple enough that constant hand-holding isn’t required. And if a team is enabling others, that support should build capability, not create dependency.
That’s strategic organisational design, not process theatre.
I also liked the framing around the thinnest viable platform. I’ve seen platform efforts become giant internal products with vague mandates and expanding scope. That usually ends the same way: a central team building too much, moving too slowly, and frustrating the product teams it was supposed to help.
A platform should reduce friction. No more than necessary.
Sometimes the right platform is not a massive investment. Sometimes it’s a small, well-designed paved road that makes the next 20 decisions easier and safer. The test isn’t how impressive it looks. The test is whether stream-aligned teams can move faster because it exists.
That’s the lens I’d use as a CTO:
Are we making it easier for teams closest to customer value to ship, learn, and adapt?
If the answer is no, the model doesn’t matter.
My biggest takeaway is this: organisation design should be treated as a dynamic capability, not a one-time restructuring exercise. Strong engineering organisations don’t just define teams well. They evolve teams deliberately as technology, regulation, and market conditions change.
That’s the part many companies miss. They want a static model to save them from doing ongoing leadership work.
There isn’t one.
There’s only the discipline of designing for flow, managing cognitive load, being intentional about team interfaces, and adapting the organisation as reality changes.
That’s harder than copying Spotify.
It’s also what actually works.