Notes on "Team Topologies" by "Matthew skelton" & "Manuel Pais"

Teams as the mean to delivery

The problem with org charts

• Org charts doesn't reflect the real communication structure.

• Search for teams that aren't related to each other but communicate

• You should align your teams structure with the software architecture structure

• Multiple quotes of the Conway law.

Conway's law and why it matters

• If software system reflect the way people communicate, then we should design the teams scope and responsabilites to reflect the software Architecture we want

• When designing the teams you should have IT experts with you

• You should be looking for high communication inside teams, low to no communication between teams

• Antipattern : everyone communicating with (or knowing about) everyone

• If two teams are coupled/paired, then they should reach for similar tools (IT). Otherwise you shouldn't impose the same tools to everyone

Team First Thinking

• You should think in term of teams, when assigning work you assign it to teams not to people

• Teams should be small and long lived, you don't disband teams that work well

• Teams should not be more than 5 - 8 peoples, exceptionnaly in high trust organisation they go up to 15 peoples

• The team owns the software, so there is no shared repository The tragedy of the commons

• Tools shouldn't be imposed to the team

• You should work with a teams first mindset. The goal of the team is more important than the goal of peoples composing it

• You should not make compromise on "Team first" approach

• Studies have shown that diversity in teams help creativity

• Since the smallest work unit in the company is the team. You should reward the team, not the individual

• People come and go, the team stays

• Restrict team responsabilities to match team cognitive load

• Cognitive load is coupled to domain complexity

• Teams should have dedicated space and time to share and learn things

• Your teams should use fondamental engineering practices : CI - CD - Lean UX - TDD - Etc..

Dunbar numbers

• Your organisation group size should respect dunbar numbers

Build a Team "API"

• Code produced by the team

• Versionning log of the team Code

• Wiki and Documentation for the team (not for the whole company !!)

• Practices and principales the way the team work

• Communication guidelines

• Work information

• Etc...

Team topologies that work for flow

Static team topologies

• Teams should be form around domain problem

• A Team should have ownership of her domain from DEV to LIVE

• DevOps helps teams to put code into production, and monitor whats happening on live

• A feature team, is a team who has ownership on the "feature" from specification to production and monitoring. Team members need a high engineering maturity and trust.

• A feature team shouldn't have depenciencies to other teams

• A product is like a feature team but for all features of a production

• DevOps is a philosophy not a team, each Dev teams should have DevOps capabilities

Team antipattern

• Team adhoc, that respond to a production issue, for example : A database crash, then you create a database team to respond to this issue

• Teams with a short lifespan

The four fondamental team topologies

• Stream aligned

• Enabling

• Complicated subsystem

• Platform

Stream aligned

• No depenciencies to other teams

• Work on a product / service / domain.

• Has full responsability on the flow from A to Z (Research UI/UX - Dev - Production / Monitoring / etc..)

Enabling team

• A cross team that help stream aligned teams on specific problematic

• These team make possible for stream aligned teams to learn things they empower them and shorten the time needed to resolve a problematic.

• For exemple they could evangelise the TDD methodology, or the IaC.

• They are always at the state of the art helping other team achieve and resolve blocking point

Complicated subsystem

• Take responsability for a particularly complicated topic, for example video codec.

• Help reduce cognitive load on stream aligned teams

Platform

• Help stream aligned team to deliver work

• Create and maintain platform abstraction

• A platform is composed of other types of teams

Choose Team-First Boundaries

• Find where the monolith and coupling are : Application, database, release, model, etc..

• Find fractures plan you can apply : Bounded context, regulatory, change cadence, performance, user persona, etc..

• A fracture plan is a delimitation that will help you divide the monolith

Evolving Team Interactions for Innovation and Rapid delivery

Team Interaction Modes

• Collaboration
• X-as-a-service
• Facilitating

Collaboration

• The collaboration mode is when two teams (A & B) works close to each other to solve a problem.

• They might book a meeting room, Team B open PR on a repository own by team A, etc..

• Collaboration requires high communication & high trust.

• Collaboration is good for innovation and discovery

• Collaboration is bad for clear Boundaries

• Collaboration is a 1 to 1 relationship

X-as-a-service

• The x-as-a-service is when a team provide a service via an interface (API, UI, Platform, etc..) to n teams

• X-as-a-service has a low comunication. slower innovation.

• X-as-a-service should be treated has a product (the service). Therfore there is a promise ("SemVer") that things won't get broken (Major, minor, patch).

• The boundaries (and interface) are clear in this mode a communication

• Cognitive load is reduced for team that consume the service, (thank to clear interfaces)

Facilitating

• The facilitating should be viewed has active mentoring

• Helps team aligned to best-practices, and discovers new ways of doing things

Conclusion

You should aim for a long lived "Team first" approach. When you design teams, have in mind the topologies and the communication they will used. Teams should adapt, exactly as a code that can't evolve and adapt is a dead codebase, a teams that can't adapt his topology or communication is a dead team. You can refactor code, you can also refactor teams. Have in mind your team API ("documentation, onboarding, methodologies, "way to organize", etc.."). Make the Conway's law work at the company advantage