More on this book
Community
Kindle Notes & Highlights
Started reading
October 6, 2020
Malan reminds us that the organization is constrained to produce designs that match or mimic the real, on-the-ground communication structure of the organization.
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.
“Given any [particular] team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist.”5
Communication paths (along formal reporting lines or not) within an organization effectively restrict the kinds of solutions that the organization can devise.
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.
At a conceptual level, software architectures should resemble the flows of change they enable; instead of a series of interconnected components, we should be designing flows on top of an underlying platform (we will cover platforms in Chapter 5).
‘architecture for participation’ that promotes ease of understanding by limiting module size, and ease of contribution by minimizing the propagation of design changes.”
We do this by partitioning our architecture to gracefully absorb change.”10 Architecture thus becomes an enabler, not a hindrance, but only if we take a team-first approach informed by Conway’s law.
There is a logical implication of Conway’s law here, 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
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.12
What we need is focused communication between specific teams. We need to look for unexpected communication and address the cause; as Manuel Sosa and colleagues found in their 2004 research into aircraft manufacturing, “managers should focus their efforts on understanding the causes of unaddressed design interfaces . . . and unpredicted team interactions . . . across modular systems.”14
if, logically, two teams shouldn’t need to communicate based on the software architecture design, then something must be wrong if the teams are communicating.
Furthermore, the relationship between cross-team tools and communication is often missed or ignored, but such tooling can be a powerful driver of self-similar design.
Conway’s law tells us that an organization is constrained to produce designs that are copies of its communication structures.
The tool can help or hinder communication flow and, therefore, the effective interaction of teams.
don’t select a single tool for the whole organization without considering team inter-relationships first.
To put this in the strongest way, regular reorganizations for the sake of management convenience or reducing headcount actively destroy the ability of organizations to build and operate software systems effectively.
Summary: Conway’s Law Is Critical for Efficient Team Design in Tech
On the other hand, the speed of software delivery is strongly affected by how many team dependencies the organization design instills.
Fast flow requires restricting communication between teams. Team collaboration is important for gray areas of development, where discovery and expertise is needed to make progress. But in areas where execution prevails—not discovery—communication becomes an unnecessary overhead.
apply the reverse Conway maneuver: designing teams to match the desired architecture.
isomorphic force at play, which converges the software architecture and the team design.
Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy.
Relying on individuals to comprehend and effectively deal with the volume and nature of information required to build and evolve modern software is not sustainable.
There are multiple aspects to consider and nurture: team size, team lifespan, team relationships, and team cognition.
By team, we mean a stable grouping of five to nine people who work toward a shared goal as a unit.
organization should never assign work to individuals; only to teams.
Allowing teams to grow beyond the magic seven-to-nine size imperils the viability of the software being built by that team, because trust will begin to break down and unsuitable decisions might ensue. Organizations need to maximize trust between people on a team, and that means limiting the number of team members.
Organizational groupings should follow Dunbar’s number, beginning with around five people (or eight for software teams), then increasing to around fifteen people, then fifty, then 150, then 500, and so on.
This, in turn, means that the software architecture needs to be realigned with the new team groupings so that teams can continue to own the architecture effectively.
Team-first software architecture is driven by Dunbar’s number.
The best approach to team lifespans is to keep the team stable and “flow the work to the team,”
However, in recent years, research by people like Pamela Knight has found that this model is not quite accurate, and that storming actually takes places continually throughout the life of the team.14 Organizations should continually nurture team dynamics to maintain high performance.
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.
Team ownership also enables a team to think in multiple “horizons”—from exploration stages to exploitation and execution—to better care for software and its viability.
Horizon 1 covers the immediate future with products and services that will deliver results the same year; Horizon 2 covers the next few periods, with an expanding reach of the products and services; and Horizon 3 covers many months ahead, where experimentation is needed to assess market fit and suitability of new services, products, and features.
The danger of allowing multiple teams to change the same system or subsystem is that no one owns either the changes made or the resulting mess.
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.
Outside teams may submit pull requests or suggestions for change to the owning team, but they cannot make changes themselves.
teams should view themselves as stewards or caretakers as opposed to private owners. Think of code as gardening, not policing.
If we follow this team-first approach, we need to ensure that the people within our teams also have (or develop) a team-first mindset.
For teams to work, team members should put the needs of the team above their own. They should: Arrive for stand-ups and meetings on time. Keep discussions and investigations on track. Encourage a focus on team goals. Help unblock other team members before starting on new work. Mentor new or less experienced team members. Avoid “winning” arguments and, instead, agree to explore options.
Good Boundaries Minimize Cognitive Load
Restrict Team Responsibilities to Match Team Cognitive Load
With a team-first approach, the team’s responsibilities are matched to the cognitive load that the team can handle.
organizations should not allow a software subsystem to grow beyond the cognitive load of the team responsible for the software.
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?”)
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).
Many organizations do not consider the cognitive load on teams when assigning responsibility for parts of a software system, instead assuming that by adding more teams to the problem, the cognitive load will be shared across the teams. Instead, the teams will suffer from similar communication and interaction strains as mentioned in Brooks’s law.
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.
