Dr. Mario's 2nd 🧠

📖 Team Topologies

4 min read

Why did I want to read it?

I read it first while in Mercadona Tech building up the Data team, getting inspiration of right 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

organizations which design systems (…) are constrained to produce designs which are copies of the communication structures of these organizations (p. xv)

The four fundamental team topologies

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)

Charity Majors says it more bluntly in Architects, Anti-Patterns, and Organizational Fuckery – charity.wtf.

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 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):

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 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)

Graph View

Backlinks