What is the Complicated-Subsystem Team pattern?
Some components need expertise that few people have and that product teams cannot realistically learn: a fraud model, a real-time video pipeline, a search ranking engine, an identity provider. A complicated-subsystem team owns one such component and offers it to product teams as a service or library with a clear interface.
What problem does the Complicated-Subsystem Team pattern solve?
Spreading deep specialist work across product teams either overloads them or produces a shallow version of something that needs depth. Giving it its own team keeps the expertise together and lets product teams use the result without carrying the complexity.
How do you implement the Complicated-Subsystem Team pattern?
- Create one only when the specialist knowledge is genuinely scarce and hard to learn.
- Give the team a clear interface, such as an API, events or a library, designed for the product teams that use it.
- Treat product teams as its customers and plan its work with them.
- Keep the subsystem small and focused, so it does not grow into a general-purpose team.
- Review the need over time. When the specialism becomes common, fold it back into product or platform teams.
When should you use it?
- A component needs expertise that most engineers do not have, such as mathematics, media or security protocols.
- Several product teams depend on the same specialist component.
When should you avoid it?
- The work is complicated but learnable. Product teams with an enabling team's help may be enough.
- It is really shared infrastructure. That belongs to the platform.
What do you gain?
- Specialist knowledge stays concentrated
- Product teams avoid unnecessary complexity
- A clear owner for a high-risk component
What does it cost?
- Another team to depend on
- Its roadmap can block product teams
- Hard to staff
What are common mistakes with the Complicated-Subsystem Team pattern?
- Creating one for every hard problem, turning the organisation back into component teams.
- An interface so specialised that only the subsystem team can use it.
- Product features that wait on the subsystem team's priorities.
Complicated-Subsystem Team in practice
Cinder Payments
Five product teams each built their own fraud checks. None of them had fraud expertise, and losses kept rising while two data scientists were spread across the teams.
The data scientists and two engineers formed a fraud team that owns a scoring service with a simple API. Product teams call it at checkout and no longer maintain fraud rules of their own.
Further reading: Team Topologies key concepts
Example decision record
- Context
- Several teams depend on a component that needs scarce specialist knowledge, and each has built a weak version of it.
- Decision
- Give the component to a dedicated team of specialists that offers it through a clear API.
- Consequences
- Expertise is concentrated where it matters.
- Product teams depend on another team's roadmap for that component.
Test yourself on Complicated-Subsystem Team
Five product teams each tried to build their own fraud detection. All five versions are weak, and the company has two data scientists with fraud expertise. What structure fits?
2 questions involve this pattern. Practice all of them →
Saved in this browser only. See your progress →