Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton

Ideally, teams should be long lived and autonomous, with engaged team members.

Niels Pflaeging, author of Organize for Complexity, identifies not one but three different organizational structures in every organization:2 Formal structure (the org chart)—facilitates compliance Informal structure—the “realm of influence” between individuals Value creation structure—how work actually gets done based on inter-personal and inter-team reputation

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

I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework.

Dunbar found fifteen to be the limit of the number of people one person can trust deeply.5 From those, only around five people can be known and trusted closely.6

The same can be applied to training budgets. With a team-first approach, the whole team rather than each individual gets a single training budget. If the team wants to send the same person to six or seven conferences during the year because they are so good at reporting back to the team, that should be the team’s decision.

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

The DevOps Topologies catalog, originally created by Matthew Skelton in 2013 and later expanded by Manuel Pais, is an online collection of team design and interactions patterns and anti-patterns that work well for kick-starting conversations around team responsibilities, interfaces, and collaboration between technology teams.

Why Stream-Aligned Team, Not “Product” or “Feature” Team? In the past, many software-delivery frameworks used the terms “product team” or “feature team” to refer to teams with a remit to deliver valuable end-to-end software increments, but these days there are many reasons why talking about streams makes more sense than talking about products or features.

Converting Architecture and Architects The most effective pattern for an architecture team is as 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.

With three very disparate technologies (mobile, cloud, and IoT), an organization must decide on an approach to fracture planes that makes sense based on the cognitive load and the change cadence in each area.

“someone who claims to be an Architect needs both technical and social skills. . . . They also need a remit that is broader than pure technology—they need to have a say in business strategies, organizational structures, and personnel issues, i.e., they need to be a manager too.”9

Trigger: Software Has Grown Too Large for One Team Symptoms A startup company grows beyond fifteen people (Dunbar’s number). Other teams spend lots of time waiting on a single team to undertake changes. Changes to certain components or workflows in the system routinely get assigned to the same people, even when they’re already busy or away. Team members complain about lack of system documentation.