Chapter 2 of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais is a deep dive into Conway’s Law both forward and backward (the reverse Conway). Conway’s Law states simply: the way people are organized influences software architecture. One of the common themes in agile and lean communities is that organizations need to organize to facilitate the flow of value to their customers. The movement can be encapsulated by the phrase “moving from projects to products.” Despite the hoopla, in 2023, silos are still the predominant organization structure. Any type of silo resists architecting software for end-to-end flow. Re-architecting to support moving toward a product perspective requires a Herculean force of will in organizations wedded to this form of structure.
A significant portion of the readers of Re-read Saturday work in environments where software architecture, in the short-term, is fixed. Whether through past decisions, implementations of packages, or inherited from SaaS applications. In order to unwind inefficiencies of architecture requires an understanding of Conway’s Law. When unwinding the sins of the past using Conway’s Law backward makes sense. This is called the Reverse Conway Maneuver. This approach suggests organizing people to match the architecture you want in the future. This generates the energy needed to mold the architecture so that it conforms to the vision and enhances flow. Several years ago I worked with a number of firms that were re-building their flagship products, creating what they called their “Next Generation.”. Nearly each of these firms squandered the chance to organize their people for flow. In every case, the status quo of siloed specialties rebuilt the new software in their image. While the platforms were upgraded to the newest and shiniest technology, the flow of value to the customer was no different than it was in the 1980’s and 90’s. Organizational structure creates inertia, once in place, teams are remarkably hard to change. Each team defends its knowledge base not trusting outsiders to act in their best interest. Matrix management is a tacit nod to the difficulty of forming long-lived cross-functional teams once siloed specialties have established themselves in the architecture of the software or product. Vincent Hendersen (SPaMCAST 676) was one of those brave leaders that swam against the tide and delivered extraordinary results. The amount of organizational politics and angst he had to absorb was huge.
The topic that struck me the hardest as I read this chapter for the second time was the idea of cognitive load. I think it is easy to demonstrate cognitive load at an individual level. Try juggling, doing long division of large numbers in your head while dodging lego left on the floor by someone. The outcome will be less than optional. Just putting a problem aside to work on another problem doesn’t totally dismiss the first. Only completing things and dismissing them from our minds for good completely reduces the load. Teams are a collection of people. Teams face the same issue (complicated by the fact that everyone’s ability to tolerate cognitive load is different). Architectures that don’t allow work to flow through teams smoothly to completion increase the cognitive load on the team. This can trigger a team overload/death spiral where work piles up waiting to be completed. A team in this position will need to expend more and more of their time tracking and reporting on what isn’t being done rather than on getting things done. Everyone is busy but no one is being productive. Tracking and reporting is a tax on teams levied by cognitive load. Organizational re-design with Conway’s Law in mind is a productive answer to this problem.
Buy a copy and upgrade your coaching skills – 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
