More on this book
Community
Kindle Notes & Highlights
Businesses can no longer choose between optimizing for stability and optimizing for speed.
In an increasingly digital ecosystem world, you need both.
the White Space on the Organization Chart
Quite clever mental picture of what's really going on in an organisation. This is where change is most effective
“Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”
Conway's law, which is essential to know for any software designer
This homomorphic force tends to make things the same shape between the software architecture and team structures. In other words, 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.
The key takeaway here is that 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.
“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”
If we accept that the self-similar force (between architecture and team organization) described by Conway is real, then we also need to accept that anyone who makes decisions about the shape and placement of engineering teams is strongly influencing the software systems architecture.
Architects should be managers too. And managers in software companies need to be technologists too.
Reorganizations that ignore Conway’s law, team cognitive load, and related dynamics risk acting like open heart surgery performed by a child: highly destructive.
High trust is what enables a team to innovate and experiment. If trust is missing or reduced due to a larger group of people, speed and safety of delivery will suffer.
In high-trust organizations, people may change teams once a year without major detrimental effects on team performance. For example, at cloud software specialist Pivotal, “an engineer would switch teams about every 9 to 12 months.”13 In typical organizations with lower levels of trust, people should remain in the same team for longer (perhaps eighteen months or two years),
We like long-lived teams - but that's not the same as eternal teams!
Recent research in both civilian and military contexts strongly suggests that teams with members of diverse backgrounds tend to produce more creative solutions more rapidly and tend to be better at empathizing with other teams’ needs.
Change the management style by communicating goals and outcomes rather than obsessing over the “how,” what McChrystal calls “Eyes On, Hands Off” in Team of Teams.
“Minimize cognitive load for others” is one of the most useful heuristics for good software development.
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.
The key for the team to remain autonomous is for external dependencies to be non-blocking, meaning that new features don’t sit idle, waiting for something to happen beyond the control of the team.
Generally speaking, teams composed only of people with a single functional expertise should be avoided if we want to deliver software rapidly and safely.
Typically, little thought is given to the viability of the boundaries for teams, resulting in a lack of ownership, disengagement, and a glacially slow rate of delivery.
Most of our fracture planes (software responsibility boundaries) should map to business-domain bounded contexts.
“a concept may appear to be atomic just because we have a single word to cover it. Look hard enough and you will find seams where you can fracture that concept.”
Precisely due to the forces behind Conway’s law, the existing software architecture will initially “push back” against the new team structures.
“someone who claims to be an Architect needs both technical and social skills. . . . They also need a remit that is broader than pure technology—they need to have a say in business strategies, organizational structures, and personnel issues, i.e., they need to be a manager too.”
A successful modern organization needs to be able to shape-shift to deal with these changing circumstances by designing for adaptability.
the most important thing is not the shape of the organization itself but the decision rules and heuristics used to adapt and change the organization as new challenges arise;
Many organizations—those with unstable and ill-defined teams, relying on key individuals and (often) suppressing the voices of large numbers of staff—are effectively “senseless” in both meanings of the word: they cannot sense their environmental situation, and what they do makes no sense.
high-fidelity sensing is crucial for organizational survival,
Increasingly, software is less of a “product for” and more of an “ongoing conversation with” users.
