Books for software engineers and managers

Team Topologies

Team Topologies

Organizing Business and Technology Teams for Fast  Flow

by Matthew Skelton and Manuel Pais

Engineering Manager,
Startup Founder

How strongly do I recommend Team Topologies?
8 / 10

Review of Team Topologies

Team Topologies gave me a fresh perspective on classifying teams and relationships between teams. Although I have thought about team behaviors and interactions, prior to reading this book I had not considered common patterns and anti-patterns.

Team Topologies pairs well with Doing Agile Right, both providing practical considerations for growing teams, organizational restructuring, and underperforming teams.

Because of Conway’s Law, anyone deciding team structures is also deciding system  architecture

Team structures are too often decided by executives disconnected from the daily work. This situation becomes especially problematic when those execs do not understand the system architecture implications of their decision.

Actual lines of communication do not resemble the org  chart

People communicate to get work done but those communication paths do not follow an org chart. I think this makes the manager’s job easier – you aren’t responsible for funneling all communications. But it also increases the need to train and provide feedback to your staff on cross-functional communications.

There exist three interaction modes between teams: collaboration, X-as-a-service, and  facilitating

The authors distinguish between team types and interaction modes between those teams. Where your team interacts with another team you should ask, “What is the current interaction mode and what should it be?”

You may find that collaborations which currently feel like dependencies or blockers can be transformed into X-as-a-service or facilitating relationships.

Similarity of team mental models of the software is a good predictor of  performance

Your team members should have a similar mental model of the software system you’re building together. This shared mental model arises and strengthens as you put teams at the forefront of your software boundaries, dividing the work and systems not by technology but by business domain.

To increase delivery effectiveness, ask which dependencies on other teams you should eliminate vs.  accept

Dependencies on other teams kill production speed. Producers also find those dependencies frustrating and demotivational.

Building software is a sociotechnical activity, not an assembling line  factory

Non-technical managers and junior engineers often make the same mistake of optimizing for batches and economies of scale because they perceive software development like an assembly line.

They mistakenly focus on efficiency where they should focus on effectiveness.

DevOps teams are an anti-pattern that encourage hard  dependencies

In many orgs, DevOps teams are just a rebranding of system admin teams. Rather than facilitating enabling other teams, they inject themselves in the critical function path and function as a blocker.

There are four team types in software companies: stream-aligned, enabling, complicated-subsystem, and  platform

The authors go into great detail on the four team types and suggest that all teams should gravitate toward one, not float between types.

  1. Stream-aligned: Cross-functional teams focused on a single valuable stream of work like a product, feature, or user persona
  2. Enabling: Specialists that help bridge a technical or product domain gap
  3. Complicated-subsystem: Builders and maintainers of a system depending on highly specialized knowledge
  4. Platform: Provide APIs, tools, services, and knowledge which function as an internal product

Stream-aligned teams focused around business domains are more effective than technology focused teams like Frontend, Backend,  etc.

The authors refer to the division points as “fracture planes” and identify most technology based teams as an anti-pattern that ultimately impedes the flow of work because no team can complete work front to back – collaboration is always required and cross-team dependencies are high.

Intermittent collaboration is often more effective than constant  interaction

There is such a thing as too much collaboration. We should aim to collaborate as necessary but no more because collaboration is expensive and slows the flow of work.

Team Topologies