Team Topologies Assessment

From chapter 5 of Domain-Driven Platform Engineering (Ajay Chankramath and Eamonn Ryan), on Team Topologies and platform as a product. The chapter’s assessments give me a repeatable way to read a team I’ve just joined: what kind of team it is, where its boundaries are, and what each relationship with another team should be.

The three questions

1. The team. Which type is it, and how heavy is its cognitive load? (Team Topologies’ four types: stream-aligned, platform, enabling, complicated-subsystem.) A stream-aligned team carrying too much infrastructure is the usual smell.
2. The boundaries. Does the team own a whole slice of the domain, or does work need hand-offs to ship? Boundaries should follow the domain (bounded contexts), not tools or the org chart.
3. The interactions. For each neighbouring team, which mode fits right now, and for how long?
   • Collaboration: working closely for a while to discover something new. Costly, so time-box it.
   • X-as-a-service: consume a capability through a clear interface (an API, a golden path; see Golden Paths). The goal state for most platform relationships.
   • Facilitating: one team helps another build a skill, then steps away (an enabling team, or a lead coaching a team into new territory).

Platform as a product

The platform team treats other teams as customers: discovery, a roadmap, and adoption that’s measured, not mandated. Success is what it enables, not what it provides (The Platform Relevance Gap, Internal Developer Platform).

Where I’d use it

• First 90 days in a new role: map my team, its neighbours and the current interaction modes. Then agree with the product manager which relationships should move, e.g. from collaboration to X-as-a-service once a contract is stable.
• A team changing shape: a front-end-heavy team taking on backend services needs facilitating for a while (backend skills, on-call, service ownership), then X-as-a-service from the platform, so the new cognitive load doesn’t land all at once.