Hi!
Lately, I’ve revisited Team Topologies book and had an amazing discussion in our CTO community - CTO.PUB
Just as a starting point to remember: Organizations at different stages of technical and cultural maturity will find different team structures effective. And that's ok. Pick whatever works for you.
4 Fundamental Archetypes
There are four fundamental team topology archetypes:
- Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
- Enabling team: helps a Stream-aligned team to overcome obstacles. It also detects missing capabilities (i.e. QA / DevOps / UX).
- Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.
- Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams.
Stream-Aligned Teams
Those autonomous teams work on the full spectrum of delivery; they are, by necessity, closest to the customer and able to quickly incorporate customer feedback while monitoring software in production.
The Amazon two-pizza team model is an example of a stream-aligned team. They have ownership and responsibility and are independent. The fact that Amazon still uses this model shows how effective it is.
Stream-Aligned Team should be able to cover a set of capabilities to progress work from gathering requirements and exploration stages to production. Those capabilities include:
- Design & architecture
- Development & coding
- Security
- Infrastructure and operability
- Metrics and monitoring
- Viability Analysis
- Product management
- Testing and quality assurance
- User experience
It's essential NOT to assume each capability map to an individual team role! This might be a team with a mix of generalists and a few specialists. Having only specialized roles would lead to a bottleneck whenever a piece of work depends on them, who might be busy.
Stream-Aligned Teams - Expected Behaviour
What is the expected behaviour from an effective stream-aligned team?
1. It aims to produce a steady flow of feature delivery.
2. It is quick to correct the course based on feedback from the latest change.
3. Uses an experimental approach to product evolution, expecting to learn and adapt (growth mindset) constantly
4. Ideally, it has zero or minimal hand-offs of work to other teams.
5. Is evaluated on the sustainable flow of change it produces
6. It should have time and space to address code quality changes (including tech debt) to ensure that code changes are safe and easy.
7. Proactively and regularly reaches out to the supporting fundamental-topologies teams (enabling, complicated subsystem and platform).
8. Members feel they have achieved or are on track to "autonomy, mastery and purpose".
Enabling Team
An enabling team is composed of specialists in a given technical domain, and they help bridge this capability gap. Jutta Eckstein called them "Technical Consulting Teams" - and it matches well what we could expect from them - guidance not execution. It can be both internal and external in an organization.
The goal of the team is to make itself in the long run not be needed, as their primary focus should be on transferring knowledge.
Enabling Team - Expected Behaviour
What is the expected behaviour from an effective enabling team?
1. It proactively seeks to understand the needs of stream-aligned teams, doing regular sessions and agreeing when more collaboration is needed.
2. It should stay ahead of the curve in keeping up-to-date with the newest trends, tooling and practices in their area of expertise. Way before it's needed from stream-aligned teams.
3. It helps with the management of the technology life cycle (i.e. "There is a thread in library X" or "New UI Testing framework can make it 50% faster).
4. Sometimes it might be a proxy for services that are currently too difficult for stream-aligned teams to use.
5. It should promote learning, across stream-aligned teams, acting as a facilitator of knowledge-sharing sessions and workshops.
To summarize the primary purpose of an enabling team is to help stream-aligned teams deliver working software in a sustainable, responsible way. Stream-aligned teams should (most of the time) expect to work with enabling teams only for short periods (weeks/months). After the new skills and understanding have been embedded in the team, the enabling team will stop daily interaction with the same team, switching their focus to a different team.
Complicated Subsytem Team
When there's a very specific part of your company/product, that requires very specialized skills and knowledge:
It might be a blockchain microservice,
It might be video processing,
It might be face-recognition,
it might be some algorithms (often requiring a PhD in mathematics)
or some other very specialized knowledge...
It wouldn't be economically good to have such an expert in each of the stream-aligned teams. This team is created, because of its technical expertise, not because we want to have a shared component.
Its main task is to offload some cognitive load from Stream-Aligned Teams that need to use the complicated subsystem.
In most cases, there would be only one to a few complicated subsystem teams in a Team Topologies organization. You can also search for contractors for those high-specialized roles or find someone offering them in an "as-a-service" bundle.
Complicated Subsystem Team - Expected Behaviour
What is the expected behaviour from an effective complicated subsystem team?
1. It is mindful of the current stage of development of the subsystem and acts accordingly - meaning high collaboration with stream-aligned teams during the exploration and development phases.
2. Once the subsystem has stabilized, it should focus on reducing interaction and focusing on the subsystem interface and feature evolution and usage during later stages.
3. It correctly prioritises and delivers upcoming work respecting the needs of the stream-aligned teams that use the complicated subsystem.
4. When you have a complicated subsystem team, delivery speed and quality for the subsystem are much higher if it is done by the stream-aligned team.
To summarize, a complicated subsystem team in a team topologies-driven organization is essential for managing highly specialized components like blockchain microservices or advanced algorithms. This team offloads the cognitive load from Stream-Aligned Teams and focuses on technical expertise rather than shared component management.
Platform Team
Everything runs on a platform. Sometimes it's just more low-level - like infrastructure or networking, but sometimes it's higher-level CI/CD, security or shared libraries and frameworks. But overall the goal of the platform team should focus on DevEx and serving its customers who are stream-aligned teams.
The platform team output should be easily consumable by other teams. They should serve their customers and make their lives easier. We should treat it as a commercial product and provide different levels of services taking into consideration things like downtime, scaling, recovery, versioning etc.
Depending on your organization's size you might want a complex platform team composed of other smaller teams (enterprise level). The trick here is to avoid silos where you'd group platforms by functions i.e:
QA / UX / Architecture / ETL. Those would serve better as enabling teams.
On the other side of the spectrum, we can find the thinnest viable platform - which could be a list on a wiki page with underlying components or services used by consuming software. We should always try to balance it, as software developers love to build platforms! :)
Platform Team - Expected Behaviour
What is the expected behaviour from an effective platform team?
1. It should understand its customer need - stream-aligned teams.
2. It relies on fast prototyping techniques and fast feedback loops with its customers to build what's needed.
3. Has a strong focus on usability and reliability for its services (treating the platform as a product).
4. Regularly assess if the services are still fit for purpose and usable.
5. Leads by example - using services they provide internally (when they can) and consuming other platform teams' work (when possible).
To summarise, the platform team should focus on improving DevEx, and treat their work as a live product or service and its consumers as customers. It should try to reduce the cognitive load from stream-aligned teams by providing streamlined services like CI/CD, security or other shared libraries. The team's structure varies with the organization's size, and its effectiveness is marked by understanding customer needs, prioritizing usability, and continuous service improvement.
Summary
And this is it. Hopefully, this has given you a good insight into Team Topologies.
You can also visit Quality Fastlane if you want to get a FREE transformation map.