One Mode and Five Types Is All That You Need

A Journey Through Organizational Models

Like many of you, I’ve spent years watching executives wrestle with the same fundamental challenge: how do you create teams that consistently deliver exceptional results while keeping people genuinely motivated and engaged?

The search for answers has taken us through decades of organizational thinking. Matrix structures promised the best of both worlds—deep expertise and cross-functional focus—but often delivered coordination nightmares instead. Traditional hierarchies offered clear lines of accountability, but at the cost of innovation and speed. The early wave of agile transformations promised both velocity and employee happiness, yet many organizations found themselves drowning in ceremonies and processes that felt more bureaucratic than liberating.

Each approach had merit, but each also had its blind spots.

Then, in 2019, something shifted. Matthew Skelton and Manuel Pais published Team Topologies, and suddenly we had a framework that felt different. Instead of focusing solely on organizational charts or process improvements, they addressed something more fundamental: how teams should be designed and how they should interact with each other. I’ve watched it transform organizations and clarify thinking in ways that previous models couldn’t.

The Foundation: Understanding Team Topologies

For those unfamiliar with Team Topologies, it’s built on a deceptively simple premise: the way teams are structured and how they interact determines the architecture of what they build. This isn’t just theory—it’s Conway’s Law in action, and Skelton and Pais gave us a practical framework to work with it intentionally.

The framework defines four team types:

• Stream-Aligned Teams deliver value directly to customers
• Platform Teams provide internal services that reduce cognitive load
• Enabling Teams help other teams build capabilities
• Complicated-Subsystem Teams handle complex domains requiring specialized expertise

And three interaction modes:

• Collaboration for discovery and learning
• X-as-a-Service for consuming services with minimal coordination
• Facilitating for knowledge transfer and capability building

This framework addresses real organizational challenges with practical guidance. But as I’ve observed its application across different contexts, I’ve noticed something: the organizations that seem to get the most sustainable value from it tend to simplify it in consistent ways.

The Pattern That Emerges

Here’s what I’ve observed: when organizations successfully implement Team Topologies, they tend to converge on X-as-a-Service as their primary interaction mode.

This isn’t to say that collaboration and facilitating don’t have their place—they absolutely do. Teams still need to work closely together during discovery phases, incident response, and when building new capabilities. But the day-to-day operational pattern that seems to create the most sustainable results is service consumption through well-defined interfaces.

Think about what this means: instead of teams constantly coordinating about who does what and when, they primarily interact by consuming each other’s services. The service offerings define the contract, and the service becomes the boundary.

This creates something powerful: clarity. Teams know what they’re responsible for, what they can expect from others, and how to measure their own success. The coordination overhead that plagues so many organizations—the endless meetings, the unclear handoffs, the finger-pointing when things go wrong—starts to dissolve.

But there’s more to this story. When you embrace X-as-a-Service as your primary interaction mode, you start to see team types differently too.

Five Service Types That Cover Everything

When you start thinking about teams as services, something interesting happens: the four team types from Team Topologies reveal both a gap and an opportunity for simplification.

Let me share what I’ve observed. When I look at organizations through a service lens, I tend to see five distinct types of services that teams provide:

Customer-Facing Services

What Team Topologies calls Stream-Aligned Teams

These are the teams that own the experiences customers directly interact with—the mobile app, the checkout flow, the onboarding process. The term “Customer-Facing Services” creates instant clarity about purpose and priority.

Business-Enabling Services

What Team Topologies calls Complicated-Subsystem Teams

These teams handle the complex internal systems that keep the business running—regulatory compliance, financial reporting, HR systems, analytics platforms. “Business-Enabling” emphasizes their essential function rather than technical complexity—they provide the capabilities that allow the organization to operate effectively.

Platform Services

What Team Topologies calls Platform Teams

This one needs no translation. Everyone understands what a technology platform does—it provides foundational IT capabilities that accelerate everyone else. Developer platforms, monitoring infrastructure, deployment pipelines, data platforms. These are the technical force multipliers.

Center of Excellence Services

What Team Topologies calls Enabling Teams

These teams multiply expertise across the organization—security consulting, architecture guidance, testing practices, performance optimization. “Center of Excellence” immediately communicates their role as knowledge hubs and expertise multipliers—language that resonates naturally with business leaders.

But here’s where it gets interesting. When you start mapping real organizations to these four types, you realize that one service type is missing—something that becomes essential when you scale.

The Fifth Type: Stewardship Services

This is where my thinking has evolved beyond the original Team Topologies model.

When you embrace X-as-a-Service as your primary interaction mode, you realize that the intentional design of the enterprise itself can be treated as a service. Someone needs to ensure that all the other services work well together, that they’re aligned with enterprise needs, and that the overall system operates as intended. (For a deeper exploration of this systems thinking, see Enterprises Are Systems Too: Designing for Competitive Advantage.)

This is where Stewardship Services come into play—services that treat enterprise design as a core service offering. They design organizational structures, develop leadership capabilities, and evolve the overall system to ensure all other services work together effectively. Their “customer” is the enterprise itself, often represented by the board of directors and executive team.

In most organizations up to several thousand people, there should be only one Stewardship Services team. Multiple stewardship teams create competing visions and conflicting enterprise designs—an anti-pattern that undermines the very clarity and alignment this service type is meant to provide.

This fifth service type fills a gap that becomes apparent when you scale. Without stewardship, you can end up with beautifully autonomous services that don’t work well together as a system.

The Shift

One interaction mode and five service types. It sounds almost too simple, doesn’t it?

But that’s exactly why it works. Simplicity creates clarity, and clarity enables autonomy. When teams understand their role as a service provider, when they know who their customers are and what success looks like, when they can interact with other teams through well-defined offerings rather than endless coordination meetings—something shifts.

The cognitive load decreases. Teams can focus on what they do best rather than spending energy on organizational complexity. The coordination overhead shrinks. Dependencies become explicit and manageable. The scaling becomes predictable. You add services, not management layers.

Most importantly, teams start to feel that sense of autonomy, mastery and purpose that Daniel Pink identified as the foundation of intrinsic motivation. They own something meaningful, they can make decisions within clear boundaries, and they can measure their impact. (For a deeper exploration of how Drive theory applies to team design, see Beyond Team Structure: Why Intrinsic Motivation Drives Performance.)

This isn’t about replacing Team Topologies—it’s about finding the essential pattern within it that balances the sophistication needed to handle real organizational complexity with the simplicity needed for humans to actually execute it. It takes the service thinking one step further: treating enterprise design as “just another service” that is part of the service ecosystem.

One mode and five types. Sometimes the most powerful ideas are the ones that feel obvious once you see them.