Team Topologies

I am reading this book as part of a book club at work.

The summary for the first part (chapters 1-3)

1 The problem with organization charts:

The software tends to match the organization charts (top-down) and that is not a good approach for software development because that doesnt cover (current) good software practices (devops, agile, lean, etc). This is based on Conway’s law: “Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”

So instead of using org charts, move to a “teams” organization approach that authors call “team topologies”: adaptive model for technology organization design that allows businesses to achieve speed and stability. Focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery.

Cognitive load can be a powerful tool for deciding on team size, assigning responsibilities, and establishing boundaries with other teams.

Dan Pink’s three elements of intrinsic motivation: autonomy (quashed by constant juggling of requests and priorities from multiple teams), mastery (“jack of all trades, master of none”), and purpose (too many domains of responsibility)

Personally, I think the org chart still has a point from HR perspective, at least I want to know who is who.And disagree when they say “there is a strong focus on the more immediate automation and tooling adoption, while cultural and organizational changes are haphazardly addressed”. People dont change tools that easily. And company culture hardly is checked out.

2 Conway’s Law and Why It Matters

The idea to become a high-performing organization is to reverse Conway law as a team-first software architecture. Then you need things team sized. The size needs to maximizes people’s ability to work with it. Important to define “team interfaces” to set expectations around what kind of work requires strong collaboration and what doesn’t (some type of communications are not needed). Tools selection is important, one doesn’t fit all. Unnecessary re-org (without any proper justification)/cut headcounts are bad (obviously).

3- Team-First Thinking

Follow: team-first architecture. Examples:

-US Army have adopted the team as the fundamental unit of operation. Based on scaling by Dunbar (5-7 people max)
-google: teams matter more than individuals.
-aws: team of size to feed with 2 pizzas)


Maximize trust between people on a team, and that means limiting the number of team members. Adding new people to a team doesn’t immediately increase its capacity (Fred Brooks – The Mythical Man-Month)

The best approach to team lifespans is to keep the team stable

Every part of the software system needs to be owned by exactly one team: no shared ownership

You need in the team:
– Team-First Mindset
– Diversity
– Rewards teams, no individuals
– Restrict Team Responsibilities to Match Team Cognitive Load more space for germane cognitive load (which is where the “value add” thinking lies).
team needs the space to continuously try to reduce the amount of intrinsic and extraneous load

Measure the Cognitive Load Using Relative Domain Complexity: mastering a single domain -> mission is clear, less context switching.

Limit the Number and Type of Domains per Team: simple, complicated, complex. Complex only one team,

Design the system and its software boundaries to fit the available cognitive load within delivery teams.

To increase the size of a software subsystem or domain for which a team is responsible:

  • team-first work env
  • minimize distractions
  • goals and outcomes (good) vs how (bad)
  • dev-exp

Teams need a team API and well-defined team interactions (aws: everything is an API): code, version, wiki/doc, principles, communication/information

As well, provide time, space, and money to enable inter teams collaboration

Explicitly Design the Physical and Virtual Environments to Help Team Interactions: I think the physical site is kind of clear (there are good notes) but for the virtual env they just mention group chats.

physical: office layout, whiteboards, standing desks?, noise, clear desk (lockers)
(squads -> tribes)

Summary: Limit Teams’ Cognitive Load and Facilitate Team Interactions to Go Faster