Team Topologies Quotes

“All the examples we mentioned so far highlight the importance of thinking about teams’ capabilities (or lack thereof) and how that causes dependencies between teams.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“organization size (or software scale) and engineering maturity should influence which topologies are chosen in a DevOps context,”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“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? How easy will it be for a new team to get on board with our code and working practices? How do we respond to pull requests and other suggestions from other teams? Is our team backlog and product roadmap easily visible and understandable by other teams?”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“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?”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Broadly speaking, for effective delivery and operations of modern software systems, organizations should attempt to minimize intrinsic cognitive load (through training, good choice of technologies, hiring, pair programming, etc.) and eliminate extraneous cognitive load altogether (boring or superfluous tasks or commands that add little value to retain in the working memory and can often be automated away), leaving more space for germane cognitive load (which is where the “value add” thinking lies).”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“we need a team-first software architecture that maximizes people’s ability to work with it.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“This quote from Ruth Malan provides what could be seen as the modern version of Conway’s law: “If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“The key takeaway here is that thinking of software architecture as a standalone concept that can be designed in isolation and then implemented by any group of teams is fundamentally wrong.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Conway’s law: “Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”6”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Limiting communication paths to well-defined team interactions produces modular, decoupled systems.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Choose software architectures that encourage team-scoped flow.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Instead of choosing between a monolithic architecture or a microservices architecture, design the software to fit the maximum team cognitive load. Only then can we hope to achieve sustainable, safe, rapid software delivery. This team-first approach to software boundaries leads to favoring certain styles of software architecture, such as small, decoupled services.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“If we stress the team by giving it responsibility for part of the system that is beyond its cognitive load capacity, it ceases to act like a high-performing unit and starts to behave like a loosely associated group of individuals, each trying to accomplish their individual tasks without the space to consider if those are in the team’s best interest.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“However, in a highly collaborative context filled with uncertainty over outcomes, relying on the org chart as a principal mechanism of splitting the work to be done leads to unrealistic expectations.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“To stay alive in ever more competitive markets, organizations need teams and people who are able to sense when context changes and evolve accordingly.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Many organizations assume that more communication is always better, but this is not really the case. What we need is focused communication between specific teams.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Clarity of business vision: the executive or leadership provides a clear, non-conflicting vision and direction for the rest of the organization, with horizons at human-relevant timescales (such as three months, six months, twelve months) and clear reasoning behind the priorities, so people in the organization can understand how and why these were chosen.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“An obsession with “feature delivery” ignores the human-related and team-related dynamics inherent in modern software, leading to a lack of engagement from staff, especially when the cognitive load is exceeded.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“we must shift our thinking from treating teams as collections of interchangeable individuals that will succeed as long as they follow the “right” process and use the “right” tools, to treating people and technology as a single human/computer carbon/silicon sociotechnical ecosystem.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Ideally, teams should be long lived and autonomous, with engaged team members. However, teams don’t live in isolation. They need to understand how and when to interact with each other. And these team interactions need to evolve over time to support the distinct phases of discovery and execution that products and technology go through during their lifetimes. In short, organizations not only need to strive for autonomous teams, they also need to continuously think about and evolve themselves in order to deliver value quickly to customers.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Reorganizations that ignore Conway’s law, team cognitive load, and related dynamics risk acting like open heart surgery performed by a child: highly destructive.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“it is very ineffective (perhaps irresponsible) for organizations that build software systems to decide on the shape, responsibilities, and boundaries of teams without input from technical leaders.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Change the management style by communicating goals and outcomes rather than obsessing over the “how,” what McChrystal calls “Eyes On, Hands Off” in Team of Teams.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“While there is no formula for cognitive load, we can assess the number and relative complexity (internal to the organization) of domains for which a given team is responsible. The Engineering Productivity team at OutSystems that we mentioned in Chapter 1 realized that the different domains they were responsible for (build and continuous integration, continuous delivery, test automation, and infrastructure automation) had caused them to become overloaded. The team was constantly faced with too much work and context switching prevailed, with tasks coming in from different product areas simultaneously. There was a general sense in the team that they lacked sufficient domain knowledge, but they had no time to invest in acquiring it. In fact, most of their cognitive load was extraneous, leaving very little capacity for value-add intrinsic or germane cognitive load. The team made a bold decision to split into microteams, each responsible for a single domain/product area: IDE productivity, platform-server productivity, and infrastructure automation. The two productivity microteams were aligned (and colocated) with the respective product areas (IDE and platform server). Changes that overlapped domains were infrequent; therefore, the previous single-team model was optimizing for the exceptions rather than the rule. With the new structure, the teams collaborated closely (even creating temporary microteams when necessary) on cross-domain issues that required a period of solution discovery but not as a permanent structure. After only a few months, the results were above their best expectations. Motivation went up as each microteam could now focus on mastering a single domain (plus they didn’t have a lead anymore, empowering team decisions). The mission for each team was clear, with less context switching and frequent intra-team communication (thanks to a single shared purpose rather than a collection of purposes). Overall, the flow and quality of the work (in terms of fitness of the solutions for product teams) increased significantly.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“the ratio of stream-aligned teams to other kinds of teams should be between about 6:1 and 9:1.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“OpEx is a deliberate enabling constraint for us:”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“In this multi-channel, highly connected context, a “product” can mean very different things, making it hard to understand what the responsibilities of a “product team” are.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“there needs to be a split between the responsibility of designing the cloud infrastructure process (by the cloud team) and the actual provisioning and updates to application resources (by the product teams).”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Given our skills, constraints, cultural and engineering maturity, desired software architecture, and business goals, which team topology will help us deliver results faster and safer?”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow