So what is it? Who is Mr Conway and why should you care about this?
A New System Appears
Have you ever worked with a new computer system?
Does it work the same way as your old system?
Does it do everything you need it to do?
Perhaps it does most of what you expect but that final, vital piece of the puzzle is buried somewhere else or completely missing?
Does this leave you pulling your hair out?
Your System is Dumb
When coming to a new system you bring your knowledge and expectations built up over many years. Your new system however is dumb.
It doesn’t know you.
It doesn’t know how you work.
It was probably created by someone that you never met.
The person who created this system had a different set of expectations, instincts and thoughts in their head. Perhaps they even just guessed how it should work?
You have undoubtedly made no detailed contract with them about exactly how the system should work. Now you’re confronted with a system that is forcing you to change your way of working or worse still doesn’t allow you to do what you need.
That is not much fun. It can be both a highly frustrating and highly expensive business to fix these issues.
What is Conway’s Law?
Your expectations are not magically baked into any new system. A developer, marketer or product manager somewhere will have made assumptions about how you work to shortcut the contracting or delivery process. A project manager may help you understand what gaps exist and suggest improvements but all of this requires a high level of knowledge and attention to detail.
Conway’s Law describes why projects often deliver questionable results and can be more expensive or take longer than they should.
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” — Melvin E. Conway
Melvin Conway is a software engineer who made this statement back in 1967. Since then many others have restated it, reworked it, giving it extra relevance but the essence remains.
In some ways, Conway’s Law is a warning but also an opportunity.
What it says is that from inception, the system you build or the project you run to build that system, is essentially going to be a mirror of your organisational layout.
You cannot avoid the human factor. It’s in all aspects of your computer system from inception to delivery.
Conway’s Law, also known as the mirroring hypothesis, shows how organisational communication pathways, arrangements and structure will always be reflected in the system that is delivered.
This can happen even if your project managers, your developers, your analysts and testers are 100% on their game. You may still get a poor copy of what you had before.
All of the sign-off, authorisation and administrative functions that are in your organisation can become represented in your new system. You may end up with a finance module, a marketing module, a customer support module, a membership system and the way you use them will mirror the human pathways in the org and also the assumptions made by your integrators or developers.
Therefore the tendency is for any new system to not improve or streamline your processes. It instead bakes them into a newer more brittle form.
The system become a formalisation of your existing working practice.
Due to Conway’s Law and due to inattention to detail you’ve built something that firstly isn’t quite yet as useful as your old system and secondly works in exactly the same way as your old system.
Does it need to be this way?
Although Conway’s Law is inevitable there are things you can do to avoid its effects.
View your digital transformation – your new software project – as a human exercise rather than a technological exercise.
Ask yourself what people are involved in the process now? How do you want them to be involved in the future? Ensure that you dispassionately design something which will do the job you want to do and not the job you’re doing right now.
The rest will flow from there.
Just remember to say thank you to Mr. Conway.