- Tags:: #đź“šBooks , [[Data team topologies|Data Team Topologies]], [[My management principles values and practices|My Management Principles Values And Practices]]
- Author:: [[matthew-skelton|Matthew Skelton]], [[manuel-pais|Manuel Pais]]
- Liked:: 6
- Link:: [Team Topologies](https://teamtopologies.com/)
- Source date:: [[2019-09-17]]
- Finished date:: [[2021-10-01]]
- Cover::
![[cover_team_topologies.png|100]]
## Why did I want to read it?
I read it first while in [[Mercadona Tech|Mercadona Tech]] building up the Data team, getting inspiration of right [[Data team topologies|Data Team Topologies]], and now [[2023-01-04]] revisiting it because I remembered it had very good guidance on platform teams.
## What did I get out of it?
I'll focus more on platform teams since it is what I've been managing for quite some time now.
## Core thesis: the [[Conway law|Conway law]]
> organizations which design systems (...) are constrained to produce designs which are copies of the communication structures of these organizations (p. xv)
^3d7b6c
## The four fundamental team topologies
![[Qrc Team Topologies 200525 V1.0 1]]
These are:
- stream-aligned: your typical "squads"
- enabling: specialists in some area that temporarily provide guidance (not execution) to stream-aligned teams.
- complicated-subsystem: only when it needs mostly specialised knowledge.
- platform: I will focus on this later as I currently manage two.
As opposed to these, you have some anti-pattern teams (p. 104):
- Infrastructure teams: should be turned into platform teams. That is providing services to dev teams rather than e.g., deploying stuff for them.
- Component and tooling teams should become platform or enabling teams (if there is value in spreading their knowledge).
- Support team members should be embedded in stream-aligned teams.
- Architecture teams:
>The most effective pattern for an architecture team is a part-time enabling team (if one is needed at all). The team being part-time is important: it emphasizes that many decisions should be taken by implementing teams rather than left to the architecture team (p. 109) ^46c8e7
[[Charity majors|Charity Majors]] says it more bluntly in [Architects, Anti-Patterns, and Organizational Fuckery – charity.wtf](https://charity.wtf/2023/03/09/architects-anti-patterns-and-organizational-fuckery/).
### Platform teams
#### Purpose: increase stream-aligned teams productivity
>The **purpose** of a platform team is to enable stream-aligned teams to deliver
work with substantial autonomy. The stream-aligned team maintains full
ownership of building, running, and fixing their application in production.
 The platform team provides internal services to **reduce the cognitive load** 
that would be required from stream-aligned teams to develop these 
underlying services (p. 92)
>[[jutta-eckstein|Jutta Eckstein]] has a suitable recommendation: "Technical-service teams should always regard themselves as **pure service providers** for the domain teams." (p. 92)
Since we are focused on DevEx:
>A platform team uses strong collaboration with stream-aligned teams to understand their needs. (p. 94)
>The use of cross-functional, stream-aligned teams has a very useful side effect (...) Solutions that require deep expertise in one area are likely to lose against simpler, easier-to-comprehend, (p. 100)
>How-to guides and other **documentation** will be comprehensive (but **not verbose**) (...) and focused on achieving specific tasks, **not documenting every last corner and niche of the platform**. (p. 102)
Never hand off ([[La tiranĂa del thinker|La TiranĂa Del Thinker]]):
>Sometimes a particular area is so complicated that a dedicated complicated-subsystem team is needed (...) But such teams never sit in the flow of change; instead, they provide services to stream-aligned teams. **Work is never handed off to another team for a later stage in the flow** (p. 100)
#### Less is more
>In practice, platform teams are expected to **focus on providing a smaller number of services of acceptable quality rather than a large number of services with many resilience and quality problems** (p. 93)
> ... we should aim for a ***thinnest viable platform (TVP)*** and avoid letting the platform dominate the discourse. As [[allan-kelly|Allan Kelly]] says, "software developers love building platforms and, without strong product management input, will create a bigger platform than needed" (p. 101)
>As with commercial products, the platform can **provide different levels of service** If all the stream-aligned teams ask for "premium level" (...) then it will likely become impossible for the platform team to cope with demand (p. 93)
### Platform needs Product too
> Too often, a platform is left to former system administrators to build and run without using well-defined software development techniques (Agile practices, TDD, continuous delivery, product management, etc.); or it receives so little funding and attention from the organization that it never helps other teams, only hinders them (p. 101)
A platform is a live system with users...
>So, how do we manage a live software system with well-defined users and hours of operation? By using software-product-management techniques. (p. 103)
> Crucially, **the evolution of the platform "product" is not simply driven by feature requests from Dev teams; instead, it is curated and carefully shaped to meet their needs in the longer term** (...) A platform is not just a collection of features that Dev teams happened to ask for at specific points in the past, but a holistic, well-crafted, consistent thing that takes into account the direction of technology change in the industry as a whole and the changing needs of the organization (p. 104)