We fought the law
...and the law won.
There are some thoughts that have been elevated to the status of laws in software engineering. There’s Brooks’ Law (“adding software engineers to a late project will only make you later.”), Goodhart’s Law (“When a measure becomes a target, it ceases to be a useful measure”), Hofstadter’s Law (”it always takes longer than you expect, even when you take into account that it always takes longer than you expect”. The list goes on.
One law that’s often referred to but arguably causes more dysfunction than the rest put together is Conway’s Law.
Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.
In other words, software architecture tends to reflect the way in which work is organised in terms of team boundaries and communication pathways.
Ignore Brooks’ Law, and your late project will be even later. Ignore Goodhart’s Law and you end up with meaningless metrics. Ignore Hofstadter’s Law, and you’ll continue to fall foul of the planning fallacy.
Ignore Conway’s Law, and you can grind your organisation to a halt.
Around 70% of digital transformations fail. Forbes attributes this to organisations treating transformation as a technology project rather than a challenge of human adoption. This is Conway's Law writ large. You can’t change the system architecture without changing the communication architecture.
Inverse manoeuvres
The reverse is also true. Changing the organisation chart or reporting lines without also investing in addressing underlying technological patterns will lead to failure. Moving people around to address the next problems your organisation faces makes complete sense when you’re a startup. When you’re a scale-up, or an enterprise, doing this without accounting for the technical landscape you’ve already built is a recipe for disaster.
This is how most re-orgs also fail. Changes get made to team structures, new projects get divvied out. Little attention is paid to the ownership and technical debt the teams are currently contending with. A monolithic architecture persists while software teams are ‘agile,’ following the ceremonies of Scrum but receiving no benefit from it due to the anchor of the pre-existing software it has to support. This architectural dissonance is a blind spot that prevents organisations from reaching their potential.
Orchestral manoeuvres
If we’re going to overcome this dissonance by design, we’re going to have to organise both sides of the organisation simultaneously. We can’t let digital transformations happen without bearing in mind the organisation structures that birthed them. Equally, we shouldn’t be blithely assuming that moving team members around, or changing reporting lines, is going to result in a re-architecture of our software unless we’re intentional about it. Conway’s Law imposes taxes on re-orgs.
In Team Topologies, Matthew Skelton and Manuel Pais draw out how this dual approach should work. The book treats team design and software architecture as inseparable. They propose a methodology for structuring teams to match the desired software architecture, and then doing the work to evolve both together. It’s a must-read for any leader faced with the question “How do we best organise ourselves?”
All too often, the response falls into a predictable pattern. Teams get re-organised. Maybe the language of Team Topologies is used. A platform function gets created to support product teams, those teams that do boring work that nobody understands are referred to as complicated subsystem teams.
However, the hard work of mapping this new structure against the existing codebase and ensuring clear lines of ownership is rarely completed. Clean reporting structures often disguise dysfunctional approaches to system architecture. At best, there’s a Frankenstein’s monster quality to the organisation, as the mis-matches between the code architecture and the organisation structure make themselves felt. At worst, zombie code wanders the halls, searching for an owner, degrading the organisation’s security posture. Whenever an upgrade is needed or someone needs to change that code, everyone is scared to tread into the danger zone, for fear of what they find, and for fear of becoming responsible for it.
A re-organisation can be a sensible response to challenges the organisation faces as it tries to scale, or get better at launching new products, or any of a thousand decisions it faces. Without mapping desired organisation changes to code ownership, though, the re-org is condemned to, if not failure, then certainly underachievement. Every time the organisation reinvents itself where it doesn’t grapple with this issue, it makes it worse. It only takes a few of these shallow re-orgs to create a challenge that has grown by an order of magnitude.
Wrestling manoeuvres
If the code still couples teams together, then your teams are still tightly coupled, whatever the re-org might say.
Every re-org that ignores the codebase adds a layer of scar tissue. Every unowned service is a future incident. Every domain boundary that exists on a slide but not in the code is a tax on the teams that have to work across it. The compound interest on this debt can turn a scaling challenge into an organisational crisis.
Conway’s Law will assert itself whether you plan for it or not. The only question is whether you’d rather design your way through it or be surprised by it again in your next re-org.