More on this book
Community
Kindle Notes & Highlights
“There is nothing more fundamental to management than how you structure your organization and what behaviors you encourage.
Conway’s law suggests major gains from designing software architectures and team interactions together, since they are similar forces.
Choose software architectures that encourage team-scoped flow.
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 te...
This highlight has been truncated due to consecutive passage length restrictions.
having teams adopting cloud and infrastructure-as-code can reduce the time to provision new infrastructure from weeks or months to minutes or hours. But if every change requires deployment (to production) approval from a board that meets once a week, then delivery speed will remain weekly at best.
Formal structure (the org chart)—facilitates compliance Informal structure—the “realm of influence” between individuals Value creation structure—how work actually gets done based on inter-personal and inter-team reputation
Pflaeging suggests that the key to successful knowledge work organizations is in the interactions between the informal structure and the value
creation structure (that is, the interactions between ...
This highlight has been truncated due to consecutive passage length restrictions.
Design when there is a compelling reason. Develop options for deciding on a design. Choose the right time to design. Look for clues that things are out of alignment. Stay alert to the future.
Periods of technical and product discovery typically require a highly collaborative environment (with overlapping team boundaries) to succeed. But keeping the same structures when discovery is over (established technologies and product) can lead to wasted effort and misunderstandings.
Conway based his observation on organizations building early electronic computer systems. In his words, this “law” indicates the strong correlation between an organization’s real communication paths (the value creation structures mentioned by Pflaeging) and the resulting software architecture,
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).
Conway’s law (organizational design prevails over software architecture design),
Fernando Cornago, Senior Director of Platform Engineering, and Markus Rautert, Vice President of Platform Engineering and Architecture, explained their IT department went from being seen as a cost center, with a single vendor providing most of the software (requiring frequent hand-offs) and only a few in-house engineers (doing more managing than engineering), to a product-oriented team organization. Adidas invested 80% of its engineering resources to creating in-house software delivery capabilities via cross-functional teams aligned with business needs. The other 20% were dedicated to a
...more
“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 primarily around sales channels for different geographic regions unlikely to produce effective software architecture that provides multiple different software services to all global regions.
organizations should evolve their team and organizational structure to achieve the desired 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
By keeping things team sized, we help to achieve what MacCormack and colleagues call “an ‘architecture for participation’ that promotes ease of understanding by limiting module size, and ease of contribution by minimizing the propagation of design changes.”8 In other words, we need a team-first software architecture that maximizes people’s ability to work with it.
“if we have managers deciding . . . which services will be built, by which teams, we implicitly have managers deciding on the system architecture.”
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.
One key implication of Conway’s law is that not all communication and collaboration is good.
Thus it is important to define “team interfaces” to set expectations around what kind of work requires strong collaboration and what doesn’t.
Communication within teams is high bandwidth. Communication between two “paired” teams can be mid bandwidth. Communication between most teams should be low bandwidth.
If the whole team works on more than one part of the system by design (for example, a newer service and an older component), keep the team together.
“fracture plane”
Such tools ship all the logs to an external location, where they get processed and indexed together (and anonymized if need be), making it faster to search and correlate events than individual logs. Teams get access to the information they need while production security controls remain intact (other than ensuring logs are being transferred in a secure fashion).
Component teams—better called complicated-subsystem teams (see Chapter 5)—are occasionally needed but only for exceptional cases, where very detailed expertise is required.
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.
One key approach to achieving the software architecture (and associated benefits like speed of delivery or time to recover from failure) is to apply the reverse Conway maneuver: designing teams to match the desired architecture.
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.
We consider the team to be the smallest entity of delivery within the organization. Therefore, an organization should never assign work to individuals; only to teams.
In most organizations, an effective team has a maximum size of around seven to nine people.
Esto demuestra q tmb la ley de conway no inversa hace tender a q sea mas conveniente los equipos desarrollen microservicios
Dunbar found fifteen to be the limit of the number of people one person can trust deeply.5 From those, only around five people can be known and trusted closely.
High trust is what enables a team to innovate and experiment.
If an organization has engendered a very strong culture of trust, mutual respect, and acceptance of failure, teams might work at up to around fifteen people.
The limit on team size and Dunbar’s number extends to groupings of teams, departments, streams of work, lines of business, and so on.
A single team: around five to eight people (based on industry experience) In high-trust organizations: no more than fifteen people Families (“tribes”): groupings of teams of no more than fifty people In high-trust organizations: groupings of no more than 150 people
Divisions/streams/profit & loss (P&L) lines: groupings of no more than 150 or 500 people
when the number of people in a department exceeds fifty (or 150, or 500), the internal and external dynamics with other groupings will change. 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. This is an example of what we like to call “team-first architecture,”
Team-first software architecture is driven by Dunbar’s number. Expect to change the architecture of software systems to fit with the limits on human interactions set by Dunbar’s number. Approaches like microservices can help if applied with a team-first perspective.
Lo q comentaba respecto de la ley de conway no inversa
Typically, a team can take from two weeks to three months or more to become a cohesive unit.
“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),
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.
Outside teams may submit pull requests or ...
This highlight has been truncated due to consecutive passage length restrictions.
change to the owning team, but they cannot make ch...
This highlight has been truncated due to consecutive passage length restrictions.
