The boundaries of teams are shaped by a huge number of pressures ranging from corporate politics and specialism to architectural structure. Inspecting the majority of team boundaries it would seem that boundaries are the outcome of a random walk because they reflect all of these pressures over time. The result is that poor team design impacts architecture and flow. It is rare to have the ability to design teams from day one or even to press the hard reboot button.
Several items struck me during this read of Chapter 6. The first is that sins of the past haunt the present and the future. Decisions about how to organize people have a way of entrenching themselves. This happens at both the architectural and organizational levels. Making changes in structure at an individual team level leads to local optimization at the expense of the teams around the team that is changing. Goldratt made this point in The Goal. Perhaps it was the mood I was in during this re-reading of this chapter, but the unwritten subtext I keep seeing is “go big or go home.’ If you are considering embracing the idea of product, product lines, and value chains, make the organizational changes needed to accelerate flow from idea to product delivery. Reorganize teams so they leverage the appropriate topology and don’t suffer under a debilitating cognitive load.
The second idea in this chapter links the metaphor of fracture plates, boundaries where rock (or bone) can more easily split, to identify patterns to simplify monolithic architectures.. Consider an example in which a team is part of a functional silo. The team in the functional silo is part of a group of teams that focus on the same technology even though the teams in the silo have little to no interaction with each other. Related teams outside of the silo support a common value stream to achieve a common goal. These teams are stream-aligned. Work bounces between the team in the functional silo and the stream-aligned teams. Flow is a problem. There are several fracture planes that can be considered (business context and stakeholders to name a few) to group all of the related teams so that flow is better. If the flow of value is important the silo’ed team needed to be “fractured” and pulled away from the silo so that it can be integrated with the stream-aligned team.
The patterns in the chapter suggest a number of ways to break down monolithic applications. I would like to suggest pushing aside the word monolith for a moment. The ideas of reducing the size and cognitive load on teams are useful regardless of whether you are working with a monolith or not. Any time I see a “team” that is larger than ten people or hear stories of people chronicling being overloaded I begin to consider how the team could be reshaped to make life better.
In discussions of earlier chapters, we considered the impact of Conway’s Law and the cognitive load that teams carry. They provide us with the why and the how teams look like they do while this chapter begins to address the question of how to reshape team structures when they get a chance to hit reset.
Buy a copy and read along! – Team Topologies: Organizing Business And Technology Teams For Fast Flow
Previous Installments:
Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4
Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf
Week 3: Conway’s Law and Why It Matters – https://bit.ly/3muTVQE
Week 4: Team First Thinking – https://bit.ly/3H9xRSC
Week 5: Static Team Topologies – https://bit.ly/40Q6eF2
Week 6: The Four Fundamental Team Topologies (Part 1) – https://bit.ly/3VUI7EB
Week 7: The Four Fundamental Team Topologies (Part 2) – https://bit.ly/3I70dxa
