Team Topologies Quotes

“Organization design and software design are, in practice, two sides of the same coin,”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“anyone who makes decisions about the shape and placement of engineering teams is strongly influencing the software systems architecture.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

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

“organizing team structures to match the architecture they want the system to exhibit rather than expecting teams to follow a mandated architecture design.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“the imbalance between formal organization structures and the way work actually gets done.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Systems thinking focuses on optimizing for the whole, looking at the overall flow of work, identifying what the largest bottleneck is today, and eliminating it.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“treating teams as collections of interchangeable individuals that will succeed as long as they follow the “right” process and use the “right” tools,”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“In many organizations, poorly defined team interactions and responsibilities are a source of friction and ineffectiveness. A team may have been told it is autonomous and self-organizing, but team members find they have to interact with many other teams in order to complete their work; and this feels frustrating. Another team may have responsibility for providing an API or service, but they don’t really have the experience to do this effectively.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“A good test for DevEx is how easy it is to onboard a new Developer to the platform.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“In order to be as effective as possible, we need to consciously design our teams rather than merely allow them to form accidentally or haphazardly.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“With stable, long-lived teams that own specific bits of the software systems, we can begin to build a stable team API: an API surrounding each team.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Requiring everyone to communicate with everyone else is a recipe for a mess.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Instead, teams should view themselves as stewards or caretakers as opposed to private owners. Think of code as gardening, not policing.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Team ownership helps to provide the vital “continuity of care” that modern systems need in order to retain their operability and stay fit for purpose.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“By team, we mean a stable grouping of five to nine people who work toward a shared goal as a unit.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“in the words of Ruth Malan: “if we have managers deciding . . . which services will be built, by which teams, we implicitly have managers deciding on the system architecture.”11”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Conway’s law tells us that we need to understand what software architecture is needed before we organize our teams, otherwise the communication paths and incentives in the organization will end up dictating the software architecture.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“an organization that is arranged in functional silos (where teams specialize in a particular function, such as QA, DBA, or security) is unlikely to ever produce software systems that are well-architected for end-to-end flow.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“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

“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

“However, it is not sufficient to simply choose a team boundary a single time and expect no further changes; instead, organizations must anticipate the need for evolution of team patterns to meet business, organizational, market, technological, and personnel needs.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“mature”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“building and running software systems is a sociotechnical activity, not an assembly line in a factory.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Site Reliability Engineering is an approach to the operation and improvement of software applications pioneered by Google to deal with their global, multi-million-user systems. If adopted in full, SRE is significantly different from IT operations of the past, due to its focus on the “error budget” (namely defining what is an acceptable amount of downtime) and the ability of SRE teams to push back on poor software.”
― 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

“We like to think that Team Topologies is another piece of this puzzle—in particular, having clear and fluid team structures, responsibilities, and interaction modes.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“it recognizes that building and running software systems is a sociotechnical activity, not an assembly line in a factory.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“In a fast-changing and challenging context, teams are more effective than groups of individuals.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“The Agile, Lean IT, and DevOps movements helped demonstrate the enormous value of smaller, more autonomous teams that were aligned to the flow of business, developing and releasing in small, iterative cycles, and course correcting based on feedback from users.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Explicitly thinking about cognitive load can be a powerful tool for deciding on team size, assigning responsibilities, and establishing boundaries with other teams.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow