team-topologies
Best Thing: Reviewers praise "Team Topologies" for its clear and actionable frameworks that help organizations improve their team structures and communication, leading to enhanced collaboration and efficiency. Worst Thing: Some reviewers mention that the book can be overly theoretical at times, lacking practical examples or case studies that would help readers better understand how to implement the concepts in real-world scenarios.
Kindle Highlights: Team Topologies: Organizing Business and Technology Teams for Fast Flow
Highlights
four fundamental team types—stream-aligned, platform, enabling, and complicated-subsystem—and three core team interaction modes—collaboration, X-as-a-Service, and facilitating. Together with awareness of Conway’s law, team cognitive load, and how to become a sensing organization, Team Topologies results in an effective and humanistic approach to building and running software systems. — location: 496 ^ref-36706
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. Teams may use shared services at runtime, but every running service, application, or subsystem is owned by only one team. — location: 974 ^ref-27541
ownership of code should not be a territorial thing. The team takes responsibility for the code and cares for it, but individual team members should not feel like the code is theirs to the exclusion of others. Instead, teams should view themselves as stewards or caretakers as opposed to private owners. Think of code as gardening, not policing. — location: 978 ^ref-4143
organizations should not allow a software subsystem to grow beyond the cognitive load of the team responsible for the software. — location: 1029 ^ref-18210
stream-aligned team aims to produce a steady flow of feature delivery. A stream-aligned team is quick to course correct based on feedback from the latest changes. A stream-aligned team uses an experimental approach to product evolution, expecting to constantly learn and adapt. A stream-aligned team has minimal (ideally zero) hand-offs of work to other teams. A stream-aligned team is evaluated on the sustainable flow of change it produces (together with some supporting technical and team-health metrics). A stream-aligned team must have time and space to address code quality changes (sometimes called “tech debt”) to ensure that changing the code remains safe and easy to do. A stream-aligned team proactively and regularly reaches out to the supporting fundamental-topologies teams (complicated subsystem, enabling, and platform). Members of a stream-aligned team feel they have achieved or are in the path to achieving “autonomy, mastery, and purpose,” — location: 1827 ^ref-61755
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. This allows the stream-aligned team the time to acquire and evolve capabilities without having to invest the associated effort (in our experience, such efforts and their impact on the rest of the team also tend to be dramatically underestimated by ten to fifteenfold). — location: 1840 ^ref-33411
An enabling team acts as a messenger of both good news (e.g., “There’s a new UI automation framework that can reduce our custom test code by 50%.”) and bad news (e.g., “Javascript framework X, which we’re using extensively, is no longer actively maintained.”). This helps with management of the technology life cycle. — location: 1871 ^ref-62533
An enabling team acts as a messenger of both good news (e.g., “There’s a new UI automation framework that can reduce our custom test code by 50%.”) and bad news (e.g., “Javascript framework X, which we’re using extensively, is no longer actively maintained.”). This helps with management of the technology life cycle. — location: 1871 ^ref-62533
The critical difference between a traditional component team (created when a subsystem is identified as being or expected to be shared by multiple systems) and a complicated-subsystem team is that the complicated-subsystem team is created only when a subsystem needs mostly specialized knowledge. The decision is driven by team cognitive load, not by a perceived opportunity to share the component. — location: 1927 ^ref-17041
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)? — location: 2491 ^ref-35276
Promise theory as a way to design systems for team interaction. Promise theory—devised by technologist and researcher Mark Burgess—explains how and why it is preferable to construct inter-team relationships in terms of promises rather than in terms of commands and enforceable contracts. — location: 2843 ^ref-61137