I’ve floated the idea of an Inverse Conway’s Law in previous posts before, but only in passing. So today I want to fully describe the concept, because I believe it is a useful way to understand some of the current challenges in martech — and why it may drive a major shift in marketing software in the AI Era.
Conway’s Law (broad interpretation)
To understand Inverse Conway’s Law, you first need to understand Conway’s Law. It’s named after Melvin Conway, an early computer scientist who in 1967 observed, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
The classic example of Conway’s Law is if you have three teams build a software app, the app will have three parts that relate to each other in a way that mirrors how those three teams interacted. The boundaries and hand-offs between the teams will be reflected in the way the software works.
I actually believe in a broader interpretation of Conway’s Law: the design of a software app will reflect the way the company that built it works — its organizational structure, beliefs, culture, and philosophy. The app is not just a mirror of the organization’s communication structure. It is the embodiment of how that firm thinks and operates.
Product managers sometimes talk about “opinionated software” that takes a point of view in how people should use it. But that’s just being conscious of this. All software is opinionated by the people who built it.
If you have 100 companies build even a moderately complex software app to accomplish the same high-level goal, you will get 100 different implementations. (This helps explain why the martech landscape has so many products that “kinda all do the same thing — but not really.”)
Inverse Conway’s Law is what happens downstream
But there’s an interesting corollary for commercially packaged software. A product reflects the organization of the vendor who built it. It does not, however, necessarily reflect the organization of a company who buys it. At least not initially. Very often a company that buys a non-trivial software app must adapt its own structure, processes, and experiences to fit the “opinion” of that software.
This is what I’ve coined as Inverse Conway’s Law: adopting a commercial software app often requires a company to adapt the way it works to fit the design of that software app.
Now, that’s not inherently a bad thing. Particularly if a buyer’s company needs to shift the way it works to adapt to new changes in the market. Being “shaped” by a software product that brings new processes and experiences to how the company operates is a feature, not a bug. You’re paying for software, but what you’re really buying is business transformation.
The history of martech brims with examples. Consider the roles and responsibilities of your current marketing operations team, their workflow, their relationships with other teams and each other. How much of your martech stack is mapped to your flow vs. how much is your flow mapped to your stack?
Differentiation drives firms back to Conway’s Law
Depending on the maturity of your marketing operations team, you may have answered that last question differently. Less mature teams are more likely to map their work to the design of the software they use. That out-of-the-box structure is a real benefit to them. They follow the sheet music and play the cover tunes. And it’s danceable.
More mature teams, however, start to improvise. They make the music their own. They want to perform originals, not covers.
Musical metaphor aside, mature marketing ops teams are more likely to have developed their own preferred workflows, customer journeys, employee experiences and customer experiences. They map the tools in their stack to their vision, rather than the other way around.
Inevitably then, they want to bend their software to that vision.
They are no longer are satisfied to simply consume an app. They’ll work to configure it, but may chafe against the constraints of what was made configurable or not configurable by the original developer. This will lead them to customize the app, where possible. But they are limited to the extensions points the vendor opened up to enable such customization.
This is when teams start composing their own apps. “Apps” may be overstating it, as initially these compositions are more workflows and automations using tools such as Workato and Zapier that cross app boundaries. They may use no-code tools such as Airtable and Webflow to assemble small database apps or web apps from templates and components. More advanced teams with more complex requirements may use low-code platforms such as Microsoft Power Apps.
Here they start to cross the boundary into creating software apps completely tailored to their needs. They become more likely to engage in open-ended programming with Python or JavaScript — albeit drawing upon a universe of software libraries and open-source frameworks to accelerate and simplify their development. At a technical level, this “create an app” stage gives companies the maximum degrees of freedom in crafting their digital operations.
But now we’ve come full circle. By building their own software, a company’s home-grown apps will be subject to Conway’s Law — the design of those apps will reflect the company’s structure, beliefs, culture, and philosophy. Which is exactly what they want.
As shown in the illustration above, moving along this spectrum — consume, configure, customize, compose, create — takes you from the dynamics of Inverse Conway’s Law to the dynamics of Conway’s Law. You gain more degrees of freedom. But the cost in required expertise and software development lifecycle (SDLC) overhead increases too. Is it worth it? It depends on the value your own business can unlock with a differentiated software app for a particular purpose.
Most businesses will have a mix of apps along this spectrum in their tech stack.
The future of martech software in the AI Era
Last week, I proposed a thought exercise to consider 3 possible scenarios for the future of martech in the Age of AI.
Would AI result in a massive expansion of the commercial martech landscape? Or will AI tools enable more companies to build their own apps, resulting in a shrinking commercial martech landscape but a massive explosion of custom-built software?
Or would AI consolidate all software into a small number of ultra-powerful super apps — Skynet for Marketers, if you will?
There has been some healthy discussion on LinkedIn around these scenarios. But most people believe the future will have more apps, not fewer. Sorry, Skynet, not today. The debate really revolved around whether we’ll see more commercial apps or more custom ones. (Or both, which is probably the most likely scenario.)
As you contemplate those alternatives, you can map the “more commercial apps” scenario to the left side of the spectrum above and the “more custom apps” scenario to the right side.
Will one dominate the other?
