Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton

team needs the space to continuously try to reduce the amount of intrinsic and extraneous load they currently have to deal with (via training, practice, automation, and any other useful techniques).

A simple and quick way to assess cognitive load is to ask the team, in a non-judgmental way: “Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?”

When measuring cognitive load, what we really care about is the domain complexity—how complex is the problem that we’re trying to solve with software?

Limit the Number and Type of Domains per Team

To get started, identify distinct domains that each team has to deal with, and classify these domains into simple (most of the work has a clear path of action), complicated (changes need to be analyzed and might require a few iterations on the solution to get it right), or complex (solutions require a lot of experimentation and discovery). You should finetune the resulting classification by comparing pairs of domains across teams: How does domain A stack against domain B? Do they have similar complexity or is one clearly more complex than the other? Does the current domain classification reflect that?

The first heuristic is to assign each domain to a single team.

The second heuristic is that a single team (considering the golden seven-to-nine team size) should be able to accommodate two to three “simple” domains.

The third heuristic is that a team responsible for a complex domain should not have any more domains assigned to them—not even a simple one.

The last heuristic is to avoid a single team responsible for two complicated domains.

Instead of choosing between a monolithic architecture or a microservices architecture, design the software to fit the maximum team cognitive load.

TIP “Minimize cognitive load for others” is one of the most useful heuristics for good software development.

The team API should explicitly consider usability by other teams: Will other teams find it easy and straightforward to interact with us, or will it be difficult and confusing?

Many of the behaviors and patterns that make a good team API also make for a good platform and good team interactions in general.

Two critical ways this can help teams build trust and awareness and learn new things are: (1) a consciously designed physical and virtual environment; and (2) time away from desks at guilds, communities of practice (a group of people who regularly get together on a voluntary basis to collectively learn and share knowledge about a domain of interest, internal tech conferences, etc.

Office design for effective software delivery should accommodate all of the following modes of work: focused individual work, collaborative intra-team work, and collaborative inter-team work. Having workspaces that clearly indicate the type of work going on also helps reduce disturbance and unnecessary interruptions.

At the end of the day, technology teams need to invest in proven team practices like continuous delivery, test-first development, and a focus on software operability and releasability.

Continuous delivery practices support hypothesis-driven development and automation, operability practices provide early and ongoing operational checks and discovery, testability practices and test-first development enhance the design and fitness for purpose of solutions, and releasability practices ensure delivery pipelines are treated as a first-grade product.

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