Breaking Conway’s Law
Conway’s Law states that:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
Eric Raymond summarized memorably as “If you have four groups working on a compiler, you’ll end up with a four-pass compiler.”
This law is usually viewed in the negative — with “constrained” often replaced with “doomed”. However, the truth is that for large software projects, you have to have some organizational structure. A key part of technical management is the iterative process of working through both the technical design of the system and the design of the organization. If you freeze either too soon, you end up too constrained — or doomed.
I stated above that you have to impose some organizational structure. Is this really inevitable? Why not have a nice flat hierarchy without arbitrary organizational boundaries impacting the product design? Certainly various matrixed or “swarm”-based organizational practices try to reduce the management friction involved in resetting the organizational structure to match the problem being solved. It is critically important to reduce the friction and establish the right culture necessary to be able to go through this iterative technical and organizational restructuring process with a minimum of overhead.
This is still just mitigating the basic problem. The key practical problem you always run into is the operational challenge of how to deliver on a set of priorities given a set of resources. You want the largest possible set of resources operating under a consistent prioritization framework, but as you increase the number of resources, the harder it is to have the necessary information and judgment to actually allocate those resources effectively. So you have a larger set of resources but you make worse decisions.
This is the essence of why we break up the organization and empower smaller teams to execute on part of the problem — so their detailed and deep understanding of the problem space they are accountable for lets them make the right trade-offs with the resources they have available. It is the smart trade-offs in allocating resources against priorities that is the essence of the hard challenge in building a large product. The smartest decisions are made where you maximize the combination of a deep understanding of the problem space and a solid grasp of the priorities. A healthy team typically maintains a certain amount of flexibility so as they work the design and development problem they can readjust structure and resources in an iterative way.
One problem you always run into is that there is no perfect organizational factoring. Different dimensions of the design problem argue for different organizational structures. This can lead to the birth of the universally loathed “v-team” or virtual team.
Office faced this problem right from its inception and learned some valuable lessons about how to organize for these cross-cutting concerns. The main organizational structure is by app (the “Word” team, the “Excel” team) and then there are shared teams that are responsible for horizontal elements like user experience (e.g. ribbons and task panes) or performance and security. There are several critical aspects to how these shared teams operate.
Shared teams have end-to-end accountability. We sometimes talked about this as “L-shaped” teams. The vertical part of the L represents accountability for an end-to-end outcome in the product (in at least some subset of the apps). The horizontal part of the L represents scaling out the basic infrastructure (code, tools, processes, documentation, training) so that the entire organization is empowered to execute against the priority. Having end-to-end responsibility means the team really needs to lead and “be accountable” that their resource decisions can achieve the end-to-end goal even if ultimately they need the help of the rest of the organization. The L-shaped structure provides flexibility as the team can either provide more or less end-to-end coverage across the entire suite (changing the width of the vertical part of the L) or provide a more complete set of tools for teams to scale out (changing the thickness of the base). This prevents the shared team from being a choke point. You start with both end-to-end accountability as well as a scale-out model which allows more resources to be applied without having to reorganize.
Taking real end-to-end ownership is always hard (e.g. for some deep issue like performance) because inevitably it really does require work and participation by everyone on the team. But it is crucially important to have someone clearly identified as the leader and fully accountable for the outcome.
Shared teams have real resources. One failure pattern is to have a team that is mostly project or program management and tries to fill a coordinating rather than execution role. Shared teams need to bring real resources to the table, which means they need to be actually building some significant part of the solution. In some cases this was part of the engineering system rather than the delivered product. By having accountability over resources, the shared team can flexibly fill gaps in the end-to-end story (allocate resources against priorities), which radically reduces friction as inevitable trade-offs come up during the course of the project.
Shared teams create new communication pathways. “Boots on the ground” also means that the shared team is connecting and working with teams across the organization in a deep way. This cross-cutting organizational connective tissue breaks down silos and ensures that information doesn’t need to flow up and down through increasingly filtered organizational communication channels. The alternative leads to dreaded “exec reviews” with data that is filtered to “red/yellow/green” or worse case “thumbs up/thumbs down” (1 bit!).
Shared teams have explicit and visible leadership support. In the case of the Office suite, you had Word and Excel as the pre-existing 800-pound gorillas. This is a frequent pattern where you are creating a bigger organization by pulling together multiple large existing teams and it starts to make sense to coordinate and optimize horizontally across them. Office 365 sees the same thing with Exchange and SharePoint as the gorillas there. Inevitably, pulling out these horizontal responsibilities is a painful process and needs full leadership support that clearly communicates the importance for the business and the technical arguments for executing this way. In the case of Office, the shared teams reported directly to the VPs of dev, test and program management and the leadership continually reinforced how important the work to turn the different applications into a real suite was for our business.
Shared teams use common processes. A key strategy we followed was to use common processes for tracking progress against this shared work. The core of the process was breaking down the work into granular elements that reflected the real work being done on a day to day basis (bugs found and fixed, work items completed, scenarios working) so that progress could be tracked transparently and consistently across all the work with an absolute minimum of custom project management and reporting. The hard work for a new area was typically not how to roll things up but how to break things down so that the granular accounting was an accurate reflection of overall progress. Agile continuous delivery makes some elements easier to track but solutions to hard problems often still need to be delivered in stages over time and require some explicit way to measure progress.
The key operational challenge is still how to optimize how you decide to allocate resources against your priorities. If you’re not focused on optimizing that, you are focused on the wrong problem.
