Beyond the Shades of Conway's Law - Strategy: Reversing the Law

Sep 20, 2026 • Thierry de Pauw • 12 min

The apparent contradiction between Yourdon and Constantine’s “organisation drives architecture” and Coplien and Harrison’s “architecture constrains organisation” resolves when we introduce time. At the outset of a greenfield system, the organisation drives the initial design. The very act of organising teams implicitly means that some system architecture decisions have been made. As the system grows, the design matures in couplings that constrain; it reverses this pressure. The system now begins to impose itself back on the organisation, narrowing our strategic options for structuring the organisation.

The Reverse Conway’s Law: The Legacy Reality

Organisations with long-lived systems will adopt a structure modelled on the system.

– Allan Kelly’s Reverse Conway’s Law, Continuous Delivery and Conway’s Law, 2014

For long-lived organisations with long-lived systems, it is the system that imposes itself on the organisation (“The Organisation must be compatible with the System”, Coplien and Harrison’s, 2004).

This is exactly what happens with COBOL organisations.

If we have a 3-tier system - frontend, backend and database - chances are, we will find a frontend team, a backend team and a database team inside the organisation. The system mirrors itself back on the organisation.

We see this with long-lived software in long-lived organisations. It might be a bit expensive. It might not be the most efficient way of working. But, hey, it works, and that is fine as long as it allows us to continue.

Where all problems start is when management decides to reorganise things. They send one of those layers to another country, or they decide we do not need a database team - the database is done, isn’t it? Or management decides to reorganise the organisation in such a way that it is no longer compatible with the architecture. However, the software will not allow that. It will reassert itself on the organisation.

We reorganised,

but the system didn’t get the memo 🤷

– a CTO, from Conway’s Law Doesn’t Apply to Rigid Designs, Mathias Verraes, 2022

With long-lived, rigid systems, we cannot just re-organise. Because of the Homomorphic Force — this structure-preserving mapping. The force creates a structure. But the force also preserves the structure. Over time, the system will try to reassert itself on the organisation. Both sides are going to push on each other.

This is where the Inverse Conway’s Manoeuvre fails, or more precisely, where people have the wrong expectations about the Inverse Conway’s Manoeuvre. We only have to reorganise, and all our problems will resolve. That is simply not true. This will clearly not happen. Especially not with rigid, long-lived systems because of exactly that Reverse Conway’s Law.

That is precisely the reality of mature organisations with legacy, long-lived systems. Yet, for leaders not aware of this physical reality, who assume they can “just” re-organise teams without rearchitecting the systems, it becomes a fatal trap.

The Inverse Conway’s Manoeuvre: The Greenfield Assumption

… organizations should evolve their team and organizational structure to achieve the desired architecture.

– Nicole Forsgren, PhD et al., Accelerate, 2018

The Inverse Conway’s Manoeuvre … is still an interesting concept, though. Introduced in 2010 by the folks from ThoughtWorks, Johnny LeRoy and Matt Simons.

Dysfunctional organizations tend to create dysfunctional applications. […] In what could be termed an “inverse Conway maneuver”, you may want to begin by breaking down silos that constrain the team’s ability to collaborate effectively.

– Jonny LeRoy and Matt Simons, Dealing with creaky legacy platforms, 2010

Before organising teams and defining the structure of the organisation, we should have a clear understanding of which software architecture we would like to achieve. It all starts from the system architecture (“The Organisation must be compatible with the System”, Coplien and Harrison, 2004). The system architecture drives the organisation to ensure the organisation stays aligned with the system.

This works for greenfield or flexible systems. Because the organisational structure defines the possible system designs at our disposal.

However, this cannot work for long-lived, rigid systems in mature organisations because of the Reverse Conway’s Law. We cannot simply reorganise. Once the system design matures, the system becomes long-lived and gains expressions in couplings that constrain; the system design imposes itself on the organisational design. Now it is the system that is a force on our organisation. This closes the option space for designing our organisation.

Here is the nuance. The Inverse Conway’s Manoeuvre is often sold as a universal silver bullet (“just re-org into feature teams or product teams”), when in truth it only works for greenfield or highly decoupled software products. In long-lived, legacy systems, applying this naively leads straight into the wall. This Greenfield Assumption warns of the danger, the delusion, of applying a greenfield technique as a blanket solution without doing the hard work of redesigning systems.

Having said that, in the case of greenfield, or flexible, highly decoupled systems, we should …

Architect the organisation to architect the system (“The System is isomorphic to the Organisation”, Yourdon and Constantine, 1979). The organisation creates the software design.

Organisational design is system design!

– Allan Kelly’s Corollary, Continuous Delivery and Conway’s Law, 2014

the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise.

– Melvin Conway, How Do Committees Invent?, 1968

Team assignments are the first draft of the architecture.

– Michael Nygard, Release It!, 2007

This means two things:

  • First, if we want separate modules, we need separate teams.

    If we have two distinct pieces of functionality, we should separate them into two distinct teams that produce two separate modules. Each team can optimise around its own module. This reconfirms Parnas’ Information Hiding (1972): separate teams can work independently on different modules.

    Conversely, if we ram two teams together, we find the modules and the functionalities become intertwined. This reiterates Baldwin et al. (2012) when comparing open source with closed source.

  • Second, collective code ownership leads to more integrated teams and code.

    This might be a good thing, or this might be a bad thing.

    If we want the code to be more separated, because we have two distinct pieces of functionality, we separate the teams.

    However, if we have lots and lots of layers, lots and lots of superfluous objects, we might be better off to bring the code together, and bring the people together. This will reflect in the software design.

But the inverse is also true!

Drafting a system architecture is already designing the structure of the organisation (“The Organisation must be compatible with the System”, Coplien and Harrison, 2004).

Conway’s Law also kicks in if we take an initial guess at the system decomposition, allocate subsystems to teams, and sally forth — the team boundaries will tend to become boundaries within the system.

– Ruth Malan, Conway’s Law, Feb 13, 2008

The Complexity Boundary: Viewing the Law Through the Lens of Cynefin

Before we can even apply the Inverse Conway’s Manoeuvre, we first need to understand the domain context. Using the Cynefin framework (Dave Snowden, 1999): Are we operating in a Clear, Complicated, Complex or Chaotic domain? Strategies change depending on the domain.

In greenfield or flexible, highly decoupled systems, cause and effect are related. We are in the Complicated domain. Cause and effect are somehow predictable, but not necessarily self-evident. Here, we can draft an ideal system architecture and organise teams around it using the Inverse Conway’s Manoeuvre. At this stage, the organisation and the system are still malleable. While the emerging system architecture influences the team structures, the organisation can nevertheless adapt to new system designs easily and quickly . The decision model here is sense - analyse - respond. Popular organisational pattern languages, such as Team Topologies, thrive in this domain because team boundaries and software boundaries can be cleanly aligned by design.

However, when organisations mature and carry long-lived rigid systems, we enter the Complex domain. Here, the organisation and system are tightly coupled by decades of implicit decisions and historical baggage, making the coupling mostly hidden and unnoticed for leadership. In that domain, we cannot simply execute an ordered top-down reorganisation — only by moving boxes around on an org-chart — and expect the system to magically redesign and decouple (“We reorganised but the system did not get the memo”, Matthias Verraes, 2022).

The naive, blind, mechanical application of Team Topologies without first decoupling the underlying legacy system architecture is a classic example of this wishful thinking. Leaders try to apply a complicated pattern to a complex legacy system. Any framework that assumes we can “just” reorganise people before addressing technical coupling will fracture against the Homomorphic Force.

Treating a Complex socio-technical system as if it were merely Complicated is a critical error. Cause and effect are only obvious in hindsight, producing unpredictable, emergent outcomes. The decision model in the Complex domain is probe – sense – respond. Rather than executing a big-bang reorganisation, which will naturally fail anyway. We must run safe-to-fail experiments instead of fail-safe designs. This is hard, time-consuming work, where we might lose track of the objective. The Improvement Kata (Mike Rother, 2009) — a continuous improvement framework for introducing large-scale organisational changes — will help to incrementally redesign and decouple the system architecture while iteratively reshaping team interactions.

Socio-Technical Alignment: Beyond Structure

The failure of a facile Inverse Conway Manoeuvre exposes a broader misunderstanding in management strategy: organisational design is not merely shifting team boxes on an org-chart. Simple, purely structural reorganisations fail routinely.

Yet, organisations can be deliberately designed by the people within them! Organisation design is an active, continuous process of adjusting to different key factors and variables as people develop and organisational goals evolve. The organisation design decisions should happen as routinely as budget cycles and scheduling (Galbraith, 1977).

Contingency Theory tells us that a. there is no one best way to organise, and b. not all the ways to organise are equally effective. We can observe a wide range of differences in effective organisations, but … these differences are not random. Context matters! Management style and organisation structure are influenced by aspects of the environment: contingency factors — the situational or environmental demands on the organisation. Then again, which contingency factors dictate the choice of a certain organisation structure? One primary driver is the nature of the organisation’s task (Strategy) — what we today call the organisation’s strategic goal (Galbraith, 1973, 1977) —, its complexity and uncertainty.

At the core of organisation design is the concept of uncertainty (Galbraith, 1977).

Uncertainty is the difference between the amount of information required to perform the task and the amount of information already possessed by the organisation.

– Jay R. Galbraith, Organisation Design, 1977, p.37

Uncertainty simply means the absence of information.

When an organisation lacks the required information to execute a task, it must acquire that information during the task execution, triggering repeated, real-time decision-making. The more uncertainty, the greater the amount of decision-making, and the more information needs to be processed. Because organisations only have a limited capacity to process information, variations in organisational structures are simply different mechanisms to make more decisions about unanticipated events, to manage uncertainty and handle greater complexity (Galbraith, 1977).

When uncertainty is low, traditional mechanisms — such as hierarchies of authority, standardised runbooks for anticipated situations, bringing decision points to where the work happens, and setting team goals aligned with organisational goals for decentralised decision-making — work fine (Galbraith, 1977). But when an organisation attempts to reorganise around a complex, highly coupled legacy system — which is what the Inverse Conway’s Manoeuvre undertakes — uncertainty goes through the roof. Teams encounter constant unanticipated situations or problems that standard procedures, such as runbooks, cannot handle. Galbraith terms these exceptions — decisions that cannot be made locally and bubble up the leadership hierarchy. As task uncertainty rises, more unresolved decisions escalate to leadership for guidance. This sheer volume of exceptions overloads the hierarchy.

When facing information overload, organisations have two fundamental strategic design choices (Galbraith, 1973):

  1. Reduce the need for information processing, e.g. introducing slack and creating truly autonomous, self-contained product teams around decoupled software systems.
  2. Increase information-processing capacity, e.g. building direct lateral communication channels using Communities of Practice and vertical information systems such as Deployment Pipelines and observability to enhance feedback loops.

Theorists have found a relation between task uncertainty and other organisation design variables. An effective organisation rests on five design variables (Galbraith, 1977):

  • Strategy — defines the organisation’s goal, the task, the domains and objectives.
  • Structure — establishes team boundaries and decision-making authority.
  • Processes — governs the flow of information, decision latency, and coordination mechanisms.
  • Rewards — aligns individual and team incentives with organisational goals to create motivation.
  • People — develops the skills, personality and collaborative mindsets required to execute the goal aligned with its level of uncertainty.

When leaders attempt a superficial Inverse Conway’s Manoeuvre purely by changing team structures, i.e., moving people into “feature teams” or “stream-aligned teams”, they manipulate only one factor (the Structure) without updating strategies, governance processes, collaboration or rewards. As task uncertainty overwhelms the new team boundaries and communication channels, the information-processing capacity collapses. The Homomorphic Force, acting as a path of least resistance, reasserts the legacy architecture onto the organisation, pulling the teams back into old communication patterns and functional silos. The reorganisation blatantly fails without anyone really understanding why, tempting leadership into the marvellous trap of repeating with even more conviction what did not work before … the same structural reshuffle.

Insanity is doing the same thing over and over again and expecting different results.

– Rita Mae Brown (falsely attributed to Einstein)

Conclusion

To successfully reverse the Law, structural changes must be accompanied by changes in information channels, decision-making authority, technical architecture, collaboration and reward systems. Rearchitecting the system and rearchitecting the organisation are not two separate initiatives — they are two sides of the same socio-technical act. Organisation and system must co-evolve.

Nevertheless, Galbraith still tries to fix a Design Principle 1 (DP1) structure — where coordination and control come from a level above where the work happens — with better information handling and better feedback. From Merrelyn and Fred Emery’s Open Systems Theory (OST) perspective (cited by Trond Hjorteland, 2022, 2025), optimising a DP1 structure by improving information processing has limits. The sheer volume of exceptions is only truly resolved by shifting to a Design Principle 2 (DP2) structure — where responsibility for coordination and control resides directly within the team doing the work by building redundant skills within people.

Therefore, reversing Conway’s Law is not just a matter of tuning Galbraith’s five variables. It requires moving from a DP1 (control-above) towards a DP2 (control-within) socio-technical structure, allowing the teams themselves to rearchitect both the organisation and the system together.

Acknowledgement

Trond Hjorteland to confirm my thinking and whisper an Open Systems Theory conclusion.

The Series: Navigating the Shades

Beyond the Shades of Conway’s Law series:

  • Foundations: The Origin & The Mirroring Principle - How the worlds of organisation and product design observed the same thesis independently.
  • Validation: The Research & Reality Check - Moving beyond the “hunch”, how researchers proved the Law in different industries, but especially in software.
  • Mechanics: The Mathematical & Geometrical Shades - The geometry of design: from mathematical isomorphism, homomorphism, congruence to compatibility.
  • Strategy: Reversing the Law - How the system ultimately forces the organisation to change versus deliberately changing the organisation.
  • Scale: Conway’s Corollary - The required organisational flexibility.
  • Dynamics: Conway’s Time Component - The “Engineer Half Life” and why architecture is “sticky” long after teams change.
  • Conclusion: The Different Lenses - A concluding look at how we perceive organisations and their systems.

Bibliography