What are the core team types in Team Topologies?

Matthew Skelton and Manuel Pais - co-authors of the book Team Topologies - discuss the four core team types defined in the book Team Topologies and how these help to achieve a good flow of change and reduce cognitive load for people working on software systems.

Transcript:

Manuel Pais:

What we say in the book is that there are four fundamental types - a stream-aligned team which other people call a product team - but they can be aligned to a stream of work that is not necessarily a product. Definitely, they are one of the core types of team that are delivering value to the customers or to the users. Because they have more and more demands on them to be able to operate, test, release their systems and run the applications in production as well, they need some kind of help, they need some support because that's a lot of cognitive load, a lot of demand on them.

The other three fundamental types of teams are helping the stream-aligned team do their work. We have enabling teams, which are typically teams of experts in a specific area that will collaborate with stream-aligned teams to help them gain the capabilities that they are missing. It can be anything from test automation to build engineering architecture what-have-you, but they have an enabling role - they are they're helping bridge the gaps that the stream-aligned team might have in the way that they build and deliver software.

We also have complicated-subsystem teams. We had a hard time coming up with a name for this type of team. It's not just the usual component team that you're trying to share component between different teams - it's really those kind of sub-systems that need such deep skills, expertise - we're talking PhD level kind of things or many years of experience in a nishe technology, where it really doesn't make sense that the stream-aligned teams or product teams would embed that kind of expertise.

First of all, there aren't enough people and it would be very costly. It's where you can say and set a very clear boundary: this is a subsystem that requires such deep knowledge that we need a team responsible for that and interfacing with with the other teams that are going to use that subsystem to make that experience smooth and easy to use.

The final type of fundamental topology are platform teams which we are going to talk a little bit more about.

Matthew Skelton:

The interesting thing about platform is - it's maybe not the platform's of the past, because platforms of the past often in many organizations were great big great massive things, very difficult to use - black boxes and teams had to use them. It was mandatory to use these things and it was awful to use in many cases, not everywhere but often these platforms are just awful.

The platforms we're talking about have placed a strong focus on developer experience, they see other development teams as their customers effectively. They run the platform as a product or service, really thinking about what's their experience in using them. In fact, some organizations go so far as to use NPS - Net Promoter Score to rank how well the platform is behaving in terms of developer experience, which I think is great.

A platform itself might have a kind of fractal, or a bit like a Russian doll effect where inside the platform there are stream-aligned teams because that's part of a product you're building, so you use the same kind of topologies from higher up the organization level within the platform and that's something that is often missed in organizations - the way we should build a platform is software. We use software development techniques that we know about - TDD, but we also use agile software delivery inside that platform.

At the same time, we're not aiming to build a massive platform. We're aiming to build what we in the book call a thinnest viable platform TVP. This TVP could be just a wiki page if that's all you need for your platform - it says we use this cloud provider and we only use these services from a cloud provider and here's the way we use them. That might just be a wiki page - that might be your platform. If that's all you need don't build anything else, you're still running on a platform but you don't make it any thicker than necessary, so that's why it's kind of thinnest viable platform. Obviously, as your enterprise gets bigger and bigger or you've got more complicated challenges you'll need to build some stuff out, but the focus is always on stream-aligned teams as the customer: what's the developer experience, making sure we're using agile software delivery practices within the platform to build it itself.