Platform Strategies With Team Topologies

Building Internal Developer Platforms is not always straightforward. When I talk to platform teams, I hear quite often questions like: What is a good design for our build pipeline? How should we provision infrastructure? Do we need a developer portal? How much should feature teams know about observability? Many teams answer these questions by relying on their specific experience and forget to take the current socio-technical context into account. If we want to have long-lasting success with our platform efforts, we first need to understand how the engineering teams are structured and how they interact. Obviously, answers will differ by the organization, but fortunately, we have a framework to discuss different designs with Team Topologies by Manuel Peis and Matthew Skelton .

Team Topologies is a fantastic book on how to organize teams in modern technology-driven enterprises. I’ve been reading up on this book for a while and recently had the time to dive deeper. I’ve discovered that many of my experiences and ideas on building and evolving platforms can be mapped or expressed with Team Topologies. So I thought it’s a good time to bring them to paper, which I will start with this post.

Agile, Lean and DevOps Don’t Talk About Team Structures

Throughout my career, I learned and used several great methodologies that helped software engineering teams. Agile, which emphasizes on iterative approaches, small teams and feedback cycles. Lean, which introduced a holistic value-stream thinking. And DevOps which popularized automation and collaboration between developer and operation silos. Today, the principles and practices of these methodologies are taken for granted and teams are implementing them left and right.

These methodologies don’t address how to structure teams when you start scaling out software engineering. The SAFE process never felt aligned with Agile principles. The Spotify model was a great addition by introducing basic team structures like cross-functional teams (Squads) and communities of practices (Chapters & Guilds). While I’ve successfully applied an adoption of this model, I always found something missing.

Team Topologies discusses many different interconnected ideas. In this post, I’ll start with a brief introduction of what the book is most famous for: team types and their interactions. In subsequent posts, I’ll dive deeper and introduce other ideas and examples where I’ve seen them work and fail.

Flow, Flow, Flow

The book introduces four team types: Stream-aligned, Enabling, Complicated Subsystem and Platform. And three interaction modes: Collaboration, X-As-A-Service and Facilitating. As we dive deeper into the types, it’s helpful to remember that the book is about “organizing teams for fast flow”. Matthew Skelton the author, recently even started thinking about renaming the “Platform” team type to “Flow Platform”.

Four Team Types

With flow in mind, the goal is to focus on autonomous, decoupled Stream-aligned teams who maintain full ownership of building, fixing and running their application. I’d like to think of a small shop with just one team, which basically creates the whole app. The other team types support these stream-aligned teams in various ways, but all with the same goal: enable the various stream-aligned teams to deliver features for the business. And you wouldn’t introduce new teams if the Stream-aligned teams haven’t signaled any issues.

The first additional team type Team Topologies introduce is the Enabling team, which consists of a set of specialists which have a specific mandate to help the Stream-aligned teams to overcome obstacles. I’d like to think of these as technical consultants which temporarily collaborate with the team on a specific topic like: test automation or improving the build pipelines. The Stream-aligned team stays autonomous and is now enabled to better build software. In some later posts, I’ll discuss different enabling teams which we have crated in the past.

The next team type should be the Platform team, which offers internal services. It’s important that there is no hand-over between a stream-aligned team and the platform. Instead, the platform offers some kind of self-service, which other teams can choose to use. The whole trend of product-thinking for internal platforms is motivated by this topology. I’ve seen plenty of examples within big enterprises and small firms and I’ll write about product management techniques with concrete examples later.

The final team type is a Complicated Subsystem team which is supposed to be used very seldom. It’s used for subsystems where significant specialists' knowledge is required for a long period of time. The driving factor here is the expertise of the team members, not the potential for reuse. The Complicated Subsystem team never sits in the flow of change and work is never handed over.

Three Interaction Modes

With these team types in mind, the book introduces three modes of how teams interact. These are sometimes overlooked, but are crucial for the overall health and evolution of the software engineering organization.

Often, teams are just told to “work together” and are not further guided on what this interaction should look like. Team Topologies makes the following differentiation on how teams interact and what to expect from each other.

The first interaction mode is Collaboration, where different team members work closely together. The team shares the same goals and their processes and activities are intervened for a certain period of time. The amount of collaboration between the two teams might wary but should be temporary or is a signal for a different team structure. We need to make sure that we have a well-defined collaboration goal and understand that the collaboration comes at a cost of slowing down the teams.

The second mode is X-As-A-Service, where one team provides a service to another team with an API and service level expectations. The team offering the service needs a strong sense of responsibility and a good amount of product / service thinking on topics like value, usability and feasibility. Therefore, these teams are sometimes supported by a dedicated product manager. Platform teams often use this mode to offer some e.g. infrastructure-as-code service once the need is well understood.

The last mode is Facilitating, where one team coaches another team on a specific aspect. This mode is mainly used by enabling teams, but not limited to them. The goal is to enhance the productivity of the teams they support. Facilitating teams often work on a specific aspect across many teams and can also help discover inconsistencies.

Note that teams interact differently with different teams in the organization. It’s important to create a shared understanding of how the different teams want to interact with each other.

Ready for Well Informed Adaptation

This was a very brief introduction and I highly recommend reading the book. But something I hopefully brought across is that we now have a framework to analyze, discuss and evolve on how we structure teams, and in my case the platform teams. Or in short, we have organizational awareness.

In my next post I will show a way on how to build adaptive platforms with Crossplane project and how we can support the discovery and adaptions by sensing and changing interaction modes. Stay tuned.

PS: If you find this topic interesting, and you are building a platform yourself, please reach out. I’d love to chat and exchange ideas.