{"id":1497,"date":"2023-12-03T11:35:31","date_gmt":"2023-12-03T11:35:31","guid":{"rendered":"https:\/\/blog.thomarite.uk\/?p=1497"},"modified":"2024-03-03T11:22:36","modified_gmt":"2024-03-03T11:22:36","slug":"team-topologies","status":"publish","type":"post","link":"https:\/\/blog.thomarite.uk\/index.php\/2023\/12\/03\/team-topologies\/","title":{"rendered":"Team Topologies"},"content":{"rendered":"\n

I am reading this book<\/a> as part of a book club at work. <\/p>\n\n\n\n

The summary for the first part (chapters 1-3)<\/p>\n\n\n\n

1 The problem with organization charts:<\/h2>\n\n\n\n

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\u2019s law: \u201cOrganizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.\u201d<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Cognitive load can be a powerful tool for deciding on team size, assigning responsibilities, and establishing boundaries with other teams.<\/p>\n\n\n\n

Dan Pink\u2019s three elements of intrinsic motivation: autonomy<\/strong> (quashed by constant juggling of requests and priorities from multiple teams), mastery<\/strong> (\u201cjack of all trades, master of none\u201d), and purpose<\/strong> (too many domains of responsibility)<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

2 Conway\u2019s Law and Why It Matters<\/h2>\n\n\n\n

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\u2019s ability to work with it. Important to define \u201cteam interfaces\u201d to set expectations around what kind of work requires strong collaboration and what doesn\u2019t (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).<\/p>\n\n\n\n

3- Team-First Thinking<\/h2>\n\n\n\n

Follow: team-first architecture. Examples:<\/p>\n\n\n\n

-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)<\/p>\n\n\n\n


Maximize trust between people on a team, and that means limiting the number of team members. Adding new people to a team doesn\u2019t immediately increase its capacity (Fred Brooks – The Mythical Man-Month)
<\/p>\n\n\n\n

The best approach to team lifespans is to keep the team stable
<\/p>\n\n\n\n

Every part of the software system needs to be owned by exactly one team: no shared ownership<\/p>\n\n\n\n

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 \u201cvalue add\u201d thinking lies).
team needs the space to continuously try to reduce the amount of intrinsic and extraneous load<\/p>\n\n\n\n

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

Limit the Number and Type of Domains per Team: simple, complicated, complex. Complex only one team,<\/p>\n\n\n\n

Design the system and its software boundaries to fit the available cognitive load within delivery teams.<\/p>\n\n\n\n

To increase the size of a software subsystem or domain for which a team is responsible:<\/p>\n\n\n\n