In my last Cortex newsletter, I discussed the history of Conway’s Law, and took a close look at how this erstwhile law can help us understand the reorganizations and deeper cultural shifts behind devops and digital transformation.
The law – “any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure” – is more of an observation of correlations between system designs and communication structures, rather than anything resembling a law.
Nevertheless, in the 47 years since computer scientist Melvin Conway inadvertently entered the techie lexicon, there have been various attempts at deriving causal principles from the law. And while causal relationships between our organizations and the software systems they create have plenty of examples, the true causal story – the why of such correlations – has largely escaped us.
That is, until now.
Party Like It’s 1967
Remember that Conway came up with his law in 1967, where newfangled software organizational concepts like Agile and Lean were little more than a gleam in his eye. Instead, his context was the traditional command and control lines of communication within a standard hierarchical organization.
Within such hierarchical organizations, the fundamental difference between one twenty-person team and four five-person teams, for example, are the differing decision making and enforcement structures.
Regardless of whether we have one large or four smaller teams, the resulting systems will clearly follow Conway’s Law – with the one large team creating a single system design, while the four smaller teams will end up producing modular, differing system designs.
When we look at the relationship between our software and our organizational structures within the context of digital and devops transformations, however, the Conway’s Law causal story gets decidedly murkier.
As I explained in the previous Cortex, the diversity within the continuous development, test, integration, and delivery toolchains that devops efforts use would contraindicate the cross-organizational cultural shift that devops represents.
Only if we recognize that the broader open source community is largely responsible for such toolchains, then we can look to the decision making structure of that community at large to indicate why such toolchains have a chance of working together properly. After all, only when our technology works as an integrated whole will Conway’s Law give us hope that we’ll be able to achieve the cultural change we desperately desire within our own organizations.
So too with digital transformation. If we take too narrow a view, perhaps focusing only on the fact that customers are demanding mobile interactions with companies, then Conway’s Law would suggest that the modularization of our system design around mobile technology will cause us to build mobile teams separate from other teams within the digital initiative.
Taking this modularized approach to digital initiatives, however, is a recipe for failure, as this view shortchanges the true nature of digital transformation. But many enterprises are falling into this trap nevertheless, as Conway’s Law would predict.
Self-Organization: The Missing Piece of the Puzzle
However, customers aren’t simply demanding mobile experiences. In reality, they desire omnichannel experiences – interactions with companies that cut across technology touchpoints and form factors to support coherent, long-term relationships – or customer journeys in digital marketing parlance.
Ideally, such omnichannel customer demand should drive crosscutting technology architectures, which in turn should drive crosscutting digital reorganizations. But if we understand Conway’s Law in terms of traditional command-and-control communication structures, we’ll inevitably end up with siloed technology that reinforces rather than breaks down our siloed organizations.
If we do away with such hierarchical thinking, however, an amazing thing happens. People will organize themselves into teams (if you even want to call them teams). Such self-organization, in fact, is behind the success of open source-driven devops toolchains.
The open source community at large is primarily self-organized, as individuals decide where and how to participate, based upon individual priorities and the priorities of the various projects – not 100%, as sometimes external forces drive the organization of such teams, but the community is sufficiently self-organized for sufficiently integrated toolchains to emerge.
Self-organization is also the key to digital transformation. If people self-organize around customer omnichannel priorities, then they will form cross-organizational communication structures that will drive end-to-end system architectures, as Conway’s Law predicts – but only in the presence of such self-organization.
Self-organization alone, however, is not a panacea. After all, in an environment of highly modular software, people are likely to organize by technical specialty around each package. To complement self-organization, therefore, we must introduce the appropriate constraints.
Such constraints should always include the strategic business priority, and should also include necessary governance and security limitations that any team, self-organized or not, must adhere to.
Perhaps the most important effect that establishing this model of self-organization within the context of external constraints is its fundamental adaptability. The constraints can be as dynamic as the situation requires, and people will naturally organize or reorganize as necessary to comply with those constraints – in marked contrast to the inflexibility of traditional command-and-control organizational structures.
Self-Organization, Emergence, and Complex Adaptive Systems
Self-organization within the context of external constraints isn’t a new idea – how Netflix delivers innovation and resilience is one example, and Zappos’ holacracy is another. But without a solid justification for such cutting-edge organizational models, enterprises rightly see them as little more than experiments.
Conway’s Law helps us move past this experimental context for self-organization. Once we have such inherently adaptable organizational structures, we will necessarily end up with inherently adaptable system architectures – the Agile Architecture I’ve been discussing in my research for years.
But most significantly, the shift from command-and-control to self-organization finally shines a light on the why of Conway’s Law: emergence.
The causal pieces to this story only fall into place once we realize the entire enterprise – people as well as technology – form a complex adaptive system. Depending on the constraints that govern the behavior and interaction of our component subsystems (the humans and their software), different emergent behaviors result – emergent in the formal sense of a property of a complex system that isn’t a property of its subsystems.
Furthermore, the nature of emergence explains Conway’s Law – giving us the answer to our basic why question, just as emergence explains why bees create hexagonal hive structures or why many galaxies are spirals.
And we can rest assured that Conway’s Law applies across the full spectrum of subsystem constraints, with traditional command-and-control at one extreme, and fully self-organizing teams at the other. Change the constraints, change the emergent behaviors.
The Intellyx Take: Turning the Agility Dial
In fact, we now have new insight into the usefulness of Conway’s Law, as it helps us understand how to turn the business agility dial on our organizations.
Do we want highly controlled, predictable behavior, well-suited for optimizing traditional business metrics? Turn the dial toward the traditional command-and-control we find in most enterprises today – but don’t be surprised if the systems we end up building are inflexible at best or fully dysfunctional at worst.
On the other hand, if we turn our dial toward self-organization, we’ll end up with technology systems that cut across now-defunct organizational silos, responding to changing business priorities and supporting strategic innovation goals.
A desirable outcome to be sure – but easier said than done, as we must relinquish our preconceptions about how to run a business. Are you ready?
Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Erica Joy.
Comments