Matthew Skelton and Manuel Pais open Chapter 1 with a quote from Naomi Stafford, Guide to Organizational Design. The quote:
“Organizations should be viewed as complex and adaptive organizations rather than mechanistic and linear systems”
Naomi Stafford
The quote set the tone for Team Topologies: Organizing Business And Technology Teams For Fast Flow. Chapter 1 is titled The Problem With Org Charts. In this chapter, the authors point out problems in how organizations describe and organize themselves.
There are several interesting points in the chapter. The first is that organizations (the authors use the term businesses, I rather believe the issue is broader) can no longer “choose between optimizing for stability and optimizing for speed.” One of the classic sayings is that change in large organizations happens with all of the haste of steering a supertanker – in other terms, it takes a long time. We can recognize the level of dynamics in the business environment. The term dynamic equates to a need to adapt.
One of the problems every change agent faces at some point in their career is that if every part of the system adapts independently, then the probability of the outcome having a significant impact is low. This is the oft-discussed topic of local optimization. Change requires taking a system-thinking approach. When teams or organizations try to wrestle with a more holistic approach to change they find the org chart rarely mirrors the flow of value. Rather they are an engineered view of the formal communication patterns. At one level, the org chart reflects how the organization thinks communications should flow. This perception influences how products and tools are built which then reinforces the org chart structure. This formal structure is often at odds with the way the value flows. The friction caused by the perceptions of how communication should flow formally, informal flows and the communication supporting the flow of value reduces the effectiveness and efficiency of any change initiative. Read that as it costs teams money, and time, and reduces their resilience. The goal is to find a way to cope with change and reduce friction.
The authors introduce the 4 types of team 3 modes of interaction that are the framework for Team Topologies. For the sake of introduction (we will discuss in later chapters), they are:
Team Types:
- Stream-aligned
- Platform
- Enabling
- Complicated-subsystem
Modes of Collaboration:
- Collaboration
- X-as-a-service
- Facilitating
As a bit of foreshadowing, once you learn to recognize the team types you will look at every team differently.
The two areas that struck me when re-reading this chapter were the concept of a Reverse Conway (designing an organization’s communication structure to mirror your intended architecture) and Cognitive Load. Chapter 2 delves into Conway’s Law in a deeper manner so I will reserve the majority of my comments on the topic until then. In the interim, look at the teams around you and the architectural structure of the software (or other product) they support. Do the teams map to the architecture or does the architecture map to the teams? Then ask yourself why we care which is true. We will return to this thought experiment next week.
The second area I found critical in Chapter 1 was the consideration of cognitive load. At an individual level, I think we would all agree cognitive load is undeniable. The more we have on our plate, the more diffuse our attention. The more our attention is spread out the more all sorts of bad things ensue. If you are interested in arguing the matter first try juggling while writing an email to your CEO. If you hit enter before you re-read the email I hope someone has a sense of humor. What has given me several dog-walks worth of contemplation is that teams and organizations are subject to the same forces. The more stuff a team has to do the more they have to juggle mentally. The tactic of saying yes to everything and then putting work on hold doesn’t reduce the cognitive load on a team. Organizing teams so that they are chronically overloaded reduces flow and increases technical debt (to name a few problems). For example, I recently was able to observe two teams. The first team began the provisioning process, then passed the work to a team that checked the software licenses (and procured them if they did not have enough) then passed the work back to the first team to go onsight and complete installation. Not only was the process grossly inefficient the flow of work made sure that team one was always overwhelmed starting new work, completing returned work, and checking on items they had shipped to team 2. This is one type of problem team designs create.
Buy a copy and upgrade your coaching skills – Team Topologies: Organizing Business And Technology Teams For Fast Flow
Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4
