More on this book
Community
Kindle Notes & Highlights
Read between
September 20 - September 26, 2021
Teams that have the right size, the right boundaries, and the right level of communication are poised to deliver value to the company and satisfaction to the team members.
The basic thesis [ . . . . ] is that organizations which design systems [ . . . . ] are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.1
Managing cognitive load through teams with clear responsibilities and boundaries is a distinguishing focus of team design in the Team Topologies approach.
Stream-aligned teams are the primary team form. These are teams that are optimized for flow, with all they need to effect continuous delivery of value and be fully responsive to the associated feedback cycles. This means that system design seeks not just loose coupling but a decomposition that supports flow and lowers dependencies and coordination needs between stream-aligned teams. Complicated-subsystem and platform teams reduce load for stream-aligned teams, where the latter are internal customers of the former’s subsystem or platform capabilities (supporting all phases of development,
...more
[Modern] organisational design . . . is about designing for collaborative technologies, for the voice of the customer. —Naomi Stanford, Guide to Organization Design
Ideally, teams should be long lived and autonomous, with engaged team members.
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.
an organization is the interaction between people and technology.
Conway’s law suggests major gains from designing software architectures and team interactions together, since they are similar forces. Team Topologies clarifies team purpose and responsibilities, increasing the effectiveness of their interrelationships. Team Topologies takes a humanistic approach to building software systems while setting up organizations for strategic adaptability.
Organizations are constrained to produce designs that reflect communication paths. The design of the organization constrains the “solution search space,” limiting possible software designs. Requiring everyone to communicate with everyone else is a recipe for a mess. Choose software architectures that encourage team-scoped flow. Limiting communication paths to well-defined team interactions produces modular, decoupled systems.
The team is the most effective means of software delivery, not individuals. Limit the size of multi-team groupings within the organization based on Dunbar’s number. Restrict team responsibilities to match the maximum team cognitive load. Establish clear boundaries of responsibility for teams. Change the team working environment to help teams succeed.
“the organizational structure must coordinate accountabilities to support the goals of delivering high-quality, impactful software.”
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.
We need to rely instead on decoupled, long-lived teams that can collaborate effectively to meet the challenge of balancing speed and safety.
In practice, people communicate laterally or “horizontally” with people from other reporting lines in order to get work done. This creativity and problem solving needs to be nurtured for the benefit of the organization, not restricted to optimize for top-down/bottom-up communication and reporting.
Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers.
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.
Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions, and achieve fast and safe software delivery.
Much like a software architecture document gets outdated as soon as the actual software development starts, an org chart is always out of sync with reality.
by explicitly agreeing on interaction modes with other teams, expectations on behaviors become clearer and inter-team trust grows.
Team Topologies provides four fundamental team types—stream-aligned, platform, enabling, and complicated-subsystem—and three core team interaction modes—collaboration, X-as-a-Service, and facilitating
Conway’s law: “Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”
building software requires an understanding of communication across teams in order to realistically consider what kind of software architectures are feasible. If the desired theoretical system architecture does not fit the organizational model, then one of the two will need to change.
“If you have four groups working on a compiler, you’ll get a 4-pass compiler.”
Team structures must match the required software architecture or risk producing unintended designs.
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.
When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.
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).
It turns out that grouper fish and moray eels, seemingly unrelated species (silos, anyone?), explicitly collaborate (via signals) to hunt down smaller fishes that hide in crevices. The eel sneaks into the crevices and scares off smaller fish, which are then forced to come out and become easy prey for the grouper.
[Conway’s law] creates an imperative to keep asking: “Is there a better design that is not available to us because of our organization?”
We’ve come a long way after all: microservices, the cloud, containers, serverless. In our experience, such novelties can help teams improve locally, but the larger the organization, the harder it becomes to reap the full benefits. The way teams are set up and interact is often based on past projects and/or legacy technologies (reflecting the latest org-chart design, which might be years old, if not decades).
“strong evidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization in which it is developed.”2
“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”
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.
Our research lends support to what is sometimes called the “inverse Conway maneuver,” which states that organizations should evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without requiring high-bandwidth communication between teams.
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.
“Team assignments are the first draft of the architecture.”
Loose coupling—components do not hold strong dependencies on other components High cohesion—components have clearly bounded responsibilities, and their internal elements are strongly related Clear and appropriate version compatibility Clear and appropriate cross-team testing
we need a team-first software architecture that maximizes people’s ability to work with it.
Keeping things decoupled and team-scoped should be a key, ongoing organization test because, as John Roberts says in The Modern Firm, “real gains in performance can often be achieved by adopting designs that adhere to [a] disaggregated model.”
Don Reinertsen, author of The Principles of Product Development Flow, says “we can also exploit architecture as an enabler of rapid changes. We do this by partitioning our architecture to gracefully absorb change.”
“if we have managers deciding . . . which services will be built, by which teams, we implicitly have managers deciding on the system architecture.”
Given that there is increasing evidence for the homomorphism behind Conway’s law, 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.
More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology—they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.
“departments and divisions, systems, and business processes . . . can be designed independently as long as interfaces and boundaries with the wider organization form part of the design.”
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. We need to look for unexpected communication and address the cause;
we can achieve low-bandwidth communication—or even zero-bandwidth communication—between teams and still build and release software in a safe, effective, rapid way, then we should.
If the organization has an expectation that “everyone should see every message in the chat” or “everyone needs to attend the massive standup meetings” or “everyone needs to be present in meetings” to approve decisions, then we have an organization design problem.
More communication is not necessarily a good thing.
