Most organisations have centralised (Cloud) platform teams (or they should). Setting up these teams is a fun challenge but a challenge nonetheless. In 2019 Matthew Skelton and Manuel Pais published their book “Team Topologies”. They share the secrets of successful team patterns and interactions to help readers choose and evolve the correct team patterns for their organisation, ensuring that the software is healthy and optimises value streams.
So you want to facilitate, transform or otherwise improve the use of Cloud or PaaS services inside your organisation, and you want to start a platform team. What is a good definition of a platform?
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination. source: martinfowler.com
In this article and the “Team Topologies” book, the above counts as a valid definition of a platform.
Four Team Types
Now we'll try to establish an archetype/mould for the teams we are trying to create. Team Topologies distinguishes four types of teams, we'll choose 'platform' for our platform team, obviously but the other team types play an important role as enablers, specialists or customers.
The stream-aligned Team is your organisation's most common and primary team type. Typical examples are feature teams. The 'stream' means the continuous flow of work aligned to a business domain or organisational capability.
This type of Team is aligned to a single, valuable stream of work like:
- A single product or service
- A single set of features
- A single-user journey
- or a single user persona
This Team works on the full spectrum of delivery (from idea to production).
Enabling teams are continuously improving their capabilities to stay ahead. An Enabling team comprises specialists in a given technical (or product) domain. They help bridge this capability gap and have a strong collaborative nature. They avoid becoming “ivory towers” of knowledge and increase the autonomy of stream-aligned teams by growing their capabilities. Teams should not form a permanent dependency on an enabling team. We'll use this archetype for our Cloud Acceleration Team.
Complicated subsystem team
Responsible for building and maintaining a part of the system that depends heavily on specialist knowledge. The goal of a complicated-subsystem team is to reduce the cognitive load of stream-aligned teams.
- Video processing codec
- Mathematical model
- Real-time trade reconciliation algorithm
- Transaction reporting system for financial services
- Face-recognition engine
The Purpose of this type of Team is:
- To enable stream-aligned teams to deliver work with substantial autonomy
- To provide internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services
Now that we've listed the four archetypes of the Team. Let's describe 2 (of the 3) interaction modes between the teams.
One Team consumes something (such as a service or an API) provided "as a service" by another team. Responsibilities are delineated, and -if the boundary is effective - the consuming Team can deliver rapidly. The Team providing the service seeks to make their service as easy to consume as possible.
Example: Stream-aligned teams consuming Platform-as-a-service from a platform team.
One Team helps another team to learn or adopt new approaches for a defined period of time. The Team providing the facilitation aims to make the other Team self-sufficient as soon as possible, while the Team receiving the facilitation has an open-minded attitude.
Example: An enabling team helping a stream-aligned or platform team.
The complete picture
If we put the interaction types and the team types together, we see a Cloud Platform Team (in blue) providing the Platform-as-a-Service to the Stream-aligned Feature Team (in yellow). The Stream-aligned Team is assisted by the Complicated-subsystem team (in orange/brown) for Specialist Trade Systems Knowledge and is facilitated (dotted overlap) by the Cloud Acceleration Team (in Purple).
Using these described roles & responsibilities, your organisation can utilise platforms at scale and avoid under-engineering, over-engineering and long queues because of overloaded central Cloud Teams. These queues lead to nasty side-effects like security issues, shadow-IT, higher attrition and lower engineer engagement. Team Topologies allows your organisation to be very clear about the Team's responsibilities and way of interacting with other teams. This prevents all the above side effects and allows for optimal flow in your organisation.
Effective software teams are essential for any organisation to deliver value continuously and sustainably. Team Topologies is a practical, step-by-step, adaptive model for organisational design and interaction based on four fundamental team types and three team interaction patterns.
It is a model that treats teams as the fundamental means of delivery, where team structures and communication pathways can evolve with technological and organisational maturity. There is a good summary of the book that can be found here, or you can purchase the book here.
At ZEN we can help your organisation with the Team Topologies framework using ZEN Cloud Consultancy.
Want to find out how? Let’s get in Touch!