The impact of the Inverse Conway Manoeuvre is constrained by the flexibility of the system. A reorganisation can’t fix a broken design.
By
Mathias Verraes
Published on 23 May 2022
The Inverse Conway Manoeuvre is an organisational engineering device. It tells us to change our team and organisational structure to achieve the system design we want. More and more organisations reorganise based on this idea, and yet they don’t end up with the system they’d like. What are we missing?
There’s evidence of the Manoeuvre being applied. GitHub for example is a distributed company that built a tool for distributed collaboration using GitHub to build it. While systems do mimic their organisations’ structure, changing the organisation doesn’t seem to have the same effect. That’s because we’re not accounting for the properties of the system under design itself.
In his paper, Dr. Conway describes a “structure-preserving relationship [between] the linear graph of a system to the linear graph of its design organisation”.1 He uses a much a broader definition of “system” than just “software system”. His is more in line with Systems Theory, where (loosely defined) everything is a system and everything is part of a system. For example, Conway writes: “It may be less obvious that a theory is a system in the same sense.” His example involves investigators who form a theory of how a plane crashed. The investigators create sub-theories of different events leading up to the crash, based on their areas of expertise. The structure of the theory will mimic the communication structure of the investigators’ organisation.
A software system doesn’t live in a vacuum. It’s embedded in the organisation that produces this system. And it’s governed by the theories we have about the software: how it works, what it does, why it does that, how it’s all connected. We call these theories “models” and “architectures”. In some organisations, these theories exist only in people’s heads. Others express these in diagrams and documentation. It’s even better when they give continuous attention to collaborating and evolving these models, (for example, using Domain-Driven Design). But whether you have diagrams or not, everybody who uses or designs the system has some theory of that system. Without modelling these theories explicitly, we not only risk having a badly designed system, we risk having wrong beliefs about the system.
Over a decade ago I was consulting for a SaaS company. I discovered that the belief of how the system worked varied wildly between the CEO, the sales people, the customer success managers and trainers, the customers, and the engineers. If you immediately assumed that the engineers had the best theory: nope. They understood so little about the design (which was largely created by their predecessors), that they wiped and rebuilt the customer dashboard database nightly. It was the only way they could get some consistency in the results.
Another example is a client of Aardling, a B2B company operating in a domain with complex regulatory requirements. When founding the company, the CEO (a domain expert) and the CTO agreed that the CTO would not get engaged in the domain’s complexity. Instead, the technology would be built in a way that allowed the tech to remain agnostic of the domain. To do this, the engineers built a form builder, a rule engine, and a templating language. They hired (non-technical) domain experts and taught them how to use these tools to build customer-facing features.
Fast-forward to a few years later. This theory about how the company should work now permeated everything, from the system design to the product to the organisational control structures. But there’s only so much you can do with forms and rule engines. Features that could easily be built with those tools, had fast turnaround times, but everything else had to be done by the engineers. This required budgets and prioritisation, and was often done through shortcuts, which in turn made subsequent changes even harder. The whole setup was making it impossible to achieve certain growth goals. The teams had no autonomy, and required a lot of alignment to achieve anything. Could a reorganisation solve this problem? Even though the system design had mimicked the communication structures that were put in place in the early days of the company, the system was now too rigid to be affected by a mere shuffling of teams.
Advocates of the Inverse Conway Manoeuvre tell us that all we have to do is to reorganise teams to get a better system design. But, if the software itself, the sociotechnical environment that creates it, and the beliefs the people hold about the system, are all systems in their own right, and they’re all impacted by the organisation’s communication structure, then applying the Manoeuvre becomes a lot more messy. To intervene effectively in my two examples above, you’d have to address the organisation, the systems, and the theories the people hold about the organisation and the system.
Software is supposed to be soft, that is, malleable, easy to change. Often, it’s not, because these systems are usually deeply coupled and interconnected. Changing one component has ripple effects, not just in the software components, but in the entire ecosystem of the organisation and its customers. If this rigidness of our software is one of our main bottlenecks, you’d think we’d be eager to address it. And yet, a disappointingly low amount of software organisations give enough attention to deep structural improvement of their software.
Instead, they turn to reorganisations. And it is a tempting promise: change your organisation, get the system design you want. It even comes with a law, so it can’t fail! However, as a CTO at a client once told me, “We reorganised, but the system didn’t get the memo.” (There is a redeeming factor: managers can only impact the software system indirectly, and their only tools are meetings and reorganisations.)
Is Conway’s Law wrong? No, I don’t think so. It holds true when designing a system from scratch, which is what the paper describes. It holds true when working with a flexible system design, flexible enough to adapt to mimic the new communication structures. But it doesn’t transfer well to existing systems with rigid designs. I propose this:
The system design will mimic the communication structures of the organisation, but only as much as the flexibility of the design allows.
Dr. Conway commented: “I think of the relationship [between communication structure and system design] as a constraint and no more. What you can change by messing with one side or the other depends on their specific characteristics”2.
By consequence, the Inverse Conway Manoeuvre needs to be extended as well:
If the system is new or flexible, change the organisational structure to get the system design you want. If the system is rigid, emphasize design work.
Or, more aphoristically:
A reorganisation won’t fix a broken design.
Conway’s Law is undervalued when it comes to the design of new systems, but overstated when it comes to the redesign of existing systems. A greenfield project has unlimited flexibility. But as the design cements in more coupling and interconnectedness, it loses flexibility. We need to think about our organisational structure early and continuously, not only as an afterthought when the design has ossified. Preventing our systems from becoming rigid requires constant attention, from the thousands of small local design decisions to large scale architecture. To support and enable decision-making, we need good models or theories about the system, the domain, the product, the ecosystem it serves.
And when we do find ourselves with a rigid system, the Inverse Conway Manoeuvre is just one of the engineering devices we can use, not a magic wand.
In the end, good design is what leads to well-designed systems.
Thanks to Dr. Conway for encouraging me to publish this.
“How Do Committees Invent?”, Dr. Melvin Conway, April 1968 ↩
Dr. Melvin Conway, quoted with permission from private correspondence, May 2022 ↩