More on this book
Community
Kindle Notes & Highlights
Read between
January 17 - February 27, 2022
Managing cognitive load through teams with clear responsibilities and boundaries is a distinguishing focus of team design in the Team Topologies approach.
boundaries and loose coupling (known as the reverse Conway maneuver, and described herein).
We explain how to use the Team Topologies approach to create a sensing organization that responds to the market and user demands, and
accounts for the implications this has for hiring and skills.
Throughout the chapters, we have included figures and callouts to highlight information we think is helpful to know and/or reference.
Businesses can no longer choose between optimizing for stability and optimizing for speed.
The good news is that it is possible to be fast and safe with the right mindset and with tools that emphasize adaptability as well as repeatability, while putting teams and people at the center.
At the same time, we need to ensure that teams are intrinsically motivated and are given a real chance of doing their best work within such a system.
Most organizations want or are required to have a single view of their teams and people called the “org chart.”
For example, having teams adopting cloud and infrastructure-as-code can reduce the time to provision new infrastructure from weeks or months to minutes or hours.
The Team Topologies approach adds the dynamic and sensing aspects required for technology organizations that are missing from traditional organization design.
Team Topologies: A New Way of Thinking about Teams
We’ve mentioned the importance of Conway’s law as a driver for team design and evolution. But what is this law exactly?
This neglect is problematic because the team is still required to fix and enhance existing services.
pattern. Monolithic databases couple the applications that depend on them and become magnets for small-business logic changes at the database level (more on this in Chapter 6).
Adidas invested 80% of its engineering resources to creating in-house software delivery capabilities via cross-functional teams aligned with business needs.
“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
There is, of course, no guarantee that the organization will find and use the designs we want, but at least by shaping the communication paths, we are making it more likely.
Let’s say that four independent teams, each comprised of front-end and back-end developers, work on different parts of a system and then hand over to a database administrator (DBA) for database changes.
If we want our data store to be aligned with the business domain, then we need to avoid having a single “fan-in” database person or team (perhaps by adding a data capability within the application-development team).
Software Architectures that Encourage Team-Scoped Flow
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.”
Organization design and software design are, in practice, two sides of the same coin, and both need to be undertaken by the same informed group of people.
“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.”13
Reorganizations that ignore Conway’s law, team cognitive load, and related dynamics risk acting like open heart surgery performed by a child: highly destructive.
On the other hand, the speed of software delivery is strongly affected by how many team dependencies the organization design instills.
In software development specifically, the speed, frequency, complexity, and diversity of changes needed for modern software-rich systems means that teams are essential.
If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level.
As Fred Brooks points out in his classic book The Mythical Man-Month, adding new people to a team doesn’t immediately increase its capacity (this became known as Brooks’s law).
Teams should be stable but not static, changing only occasionally and when necessary.
Awareness of and ownership over these different time horizons helps a team care for the code more effectively.
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.
This may be unfamiliar to some people, but with the right coaching and time to learn, many people adapt.
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.
These people are “team toxic” and need to be removed before damage is done.
“collectively oriented team members were more likely to attend to the task inputs of other team members and to improve their performance during team interaction than egocentric team members.”
Having established the team as the fundamental means of delivery, organizations also need to ensure that the cognitive load on a team is not too high.
One of the least acknowledged factors that increases friction in modern software delivery is the ever-increasing size and complexity of codebases that teams have to work with.
Cognitive load was characterized in 1988 by psychologist John Sweller as “the total amount of mental effort being used in the working memory.”22 Sweller defines three different kinds of cognitive load:
At the same time, the team needs the space to continuously try to reduce the amount of intrinsic and extraneous load they currently have to deal with (via training, practice, automation, and any other useful techniques).
“Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?”
When measuring cognitive load, what we really care about is the domain complexity—how complex is the problem that we’re trying to solve with software?
plenty of tools for continuous delivery—it’s not difficult.”) in order to “fit in” more domains with a single team will only lead to failure.
Because such domains are quite procedural, the cost of context switching between domains is more bearable, as responses are more mechanical.
In this context, a simple domain for a team might be an older software system that has only minor, occasional, straightforward changes.
However, there is a risk here of diminishing team members’ motivation due to the more rou...
This highlight has been truncated due to consecutive passage length restrictions.
Because this team interaction is outside the everyday building and running of the main software systems, Conway’s law plays a much less obvious role, and a freer cross-association between teams can take place.
However, different people need different environments at different times to be productive.
