Team Topologies Quotes

“Organizations should be viewed as complex and adaptive organisms rather than mechanistic and linear systems. —Naomi Stanford,”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“If the desired theoretical system architecture does not fit the organizational model, then one of the two will need to change.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

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

“Time from code commit to deployment (cycle time)”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“The end goal of an enabling team is to increase the autonomy of stream-aligned teams by growing their capabilities with a focus on their problems first, not the solutions per se. If an enabling team does its job well, the team that it is helping should no longer need the help from the enabling team after a few weeks or months; there should not be a permanent dependency on an enabling team.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“These capabilities include (but are not restricted to): ​•​Application security ​•​Commercial and operational viability analysis ​•​Design and architecture ​•​Development and coding ​•​Infrastructure and operability ​•​Metrics and monitoring ​•​Product management and ownership ​•​Testing and quality assurance ​•​User experience (UX)”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“four fundamental team topologies: ​•​Stream-aligned team ​•​Enabling team ​•​Complicated-subsystem team ​•​Platform team”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Diane Strode and Sid Huff propose three different categories of dependency: knowledge, task, and resource dependencies.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“In other words, 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

“By empowering teams, and treating them as fundamental building blocks, individuals inside those teams move closer together to act as a team rather than just a group of people. On the other hand, by explicitly agreeing on interaction modes with other teams, expectations on behaviors become clearer and inter-team trust grows.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Cognitive load was characterized in 1988 by psychologist John Sweller as “the total amount of mental effort being used in the working memory.”22 Sweller defines three different kinds of cognitive load: ​•​Intrinsic cognitive load—relates to aspects of the task fundamental to the problem space (e.g., “What is the structure of a Java class?” “How do I create a new method?”) ​•​Extraneous cognitive load—relates to the environment in which the task is being done (e.g., “How do I deploy this component again?” “How do I configure this service?”) ​•​Germane cognitive load—relates to aspects of the task that need special attention for learning or high performance (e.g., “How should this service interact with the ABC service?”)”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Outside teams may submit pull requests or suggestions for change to the owning team, but they cannot make changes themselves.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Every part of the software system needs to be owned by exactly one team. This means there should be no shared ownership of components, libraries, or code.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“The best approach to team lifespans is to keep the team stable and “flow the work to the team,”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“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 fact, research by Google on their own teams found that who is on the team matters less than the team dynamics; and that when it comes to measuring performance, teams matter more than individuals.3 We must, therefore, start with the team for effective software delivery. There are multiple aspects to consider and nurture: team size, team lifespan, team relationships, and team cognition.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Mike Cohn, one of the originators of the Scrum product-development approach, asks these questions to assess the health of inter-team communication within an organization: “Does the structure minimize the number of communication paths between teams? . . . Does the structure encourage teams to communicate who wouldn’t otherwise do so?15”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Miguel Antunes, R&D Principle Software Engineer at OutSystems, a low-code platform vendor, relayed an example of this very challenge. Their Engineering Productivity team at OutSystems was five years old. The team’s mission was to help product teams run their builds efficiently, maintain infrastructure, and improve test execution. The team kept growing and took on extra responsibilities around continuous integration (CI), continuous delivery (CD), and infrastructure automation.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“The litmus test for the applicability of a fracture plane: Does the resulting architecture support more autonomous teams (less dependent teams) with reduced cognitive load (less disparate responsibilities)?”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts. This splitting of software is particularly useful with monolithic software.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Helping stream-aligned teams achieve this high rate of flow are enabling teams (which identify impediments and cross-team challenges, and simplify the adoption of new approaches), complicated-subsystem teams (if needed, to bring deep specialist expertise to specific parts of the system), and platform teams (which provide the underlying “substrate” on which stream-aligned teams can build and support software products and services with minimal friction).”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Change the team working environment to help teams succeed.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Managing cognitive load through teams with clear responsibilities and boundaries is a distinguishing focus of team design in the Team Topologies approach.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem. The goal of this team is to reduce the cognitive load of stream-aligned teams working on systems that include or use the complicated subsystem. The team handles the subsystem complexity via specific capabilities and expertise that are typically hard to find or grow.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Enabling teams and CoP can co-exist because they have slightly different purposes and dynamics: an enabling team is a small, long-lived group of specialists focused on building awareness and capability for a single team (or a small number of teams) at any one point in time, whereas a CoP usually seeks to have more widespread effects, diffusing knowledge across many teams. Of course, several enabling teams can also have their own “enabling-teams community of practice!”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“. After the new skills and understanding have been embedded in the stream-aligned team, the enabling team will stop daily interaction with the stream-aligned team, switching their focus to a different team.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“Enabling teams have a strongly collaborative nature; they thrive to understand the problems and shortcomings of stream-aligned teams in order to provide effective guidance.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap. Such teams cross-cut to the stream-aligned teams and have the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“​•​Stream-aligned team ​•​Enabling team ​•​Complicated-subsystem team ​•​Platform team”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

“In their 2012 paper, “A Taxonomy of Dependencies in Agile Software Development,” Diane Strode and Sid Huff propose three different categories of dependency: knowledge, task, and resource dependencies.14 Such a taxonomy can help pinpoint dependencies between teams and the potential constraints to the flow of work ahead of time.”
― Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow