Team Topologies is a useful idea described in a book, lots of talks, and has plenty of articles and downloadable resources too. This page highlights just a few bits of it. Slides are from the course mentioned in Team Topologies advice for platform teams.
The authors have worked with lots of orgs and done piles of research, and are keen to say: these are patterns and principles they’ve seen work very well, but other options are definitely possible (and may work better). As well as sharing effective practices, they hope to provide a bit of a standard language for the industry - as more and more people learn about Team Topologies, you can use it to aid description (e.g. “sort of like an enabling team, but…”).
Team Topologies is meant to provide clear patterns that are straightforward for many different teams and organizations to follow and interpret, not to dictate to outstanding players how to perform. We like to think of Team Topologies as a set of music parts for an orchestra or big band, not the melody for a top jazz trumpeter. Printed music for a large musical ensemble helps the group to succeed but does not dictate every aspect of performance; lots of detail is left for the ensemble to interpret to suit the occasion, venue, or mix of players. Likewise, there is huge value in agreeing to a coherent vocabulary…
If your team structure is at odds with your software/product structure, the team structure will win. The way you assign responsibilities to teams is important.
Team Topologies is to help achieve a rapid flow of change and rapid feedback from running systems. Relevant for pretty much every org.
The more painful handovers are between teams (synchronisation of schedules, prioritisation of work, one team becomes a gatekeeper of change) the more difficult fast flow is.
It’s not just the time it takes, it’s the knowledge that gets lost.
Poppendieck: roughly 50% of history gets lost when something’s handed to another team. Why did we make these decisions, what were we trying to achieve…
When considering whether a team has enough cognitive capacity to own a piece of software, you need to include operating and maintaining it.
3 types of cognitive load.