In this article, I’ll show you how Conway’s law exposes the dire need for having a tech strategy. Having a vision and overall strategy for your software business is essential to its future stability and growth!
Conway’s Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
http://melconway.com/Home/Conways_Law.html
The software that a business builds is going to mimic how that company is organized.
More specifically, it will mimic the communication patterns of a company.
Let’s begin by having a look at Conway’s law in practice.
Dictatorships
In many smaller companies, you will find a structure similar to this:
It looks like the IT Manager, for example, is responsible for the work that the developers are doing.
It might also look like the Sales Manager is responsible for the work that the Sales Agents are doing.
After-all, does it make sense for the CEO to be telling everyone what to do? Hiring employees who are specialists in their fields (sales, IT, etc.) means that the CEO can delegate not only busywork but also thinking, strategy, project management, etc.
The CEO’s job should be to steer the ship. It shouldn’t be to cook the food, make the beds, row the oars, etc.
It shouldn’t even be to tell the master chef how to cook. Otherwise, why hire a master chef? Isn’t he/she the specialist? Didn’t you hire him/her because they are better than you at cooking?
Sadly, many times this is what happens:
This dictatorship might be by proxy through the manager. This might be by the CEO directly limiting what options the teams/manager have.
It could be by dictating what specific software developers will work on.
It might be by mandating what technologies will be used.
Perhaps they decide what the software development process to be used will be.
Or by forcing what sales tactics and methods will be employed.
Conway’s Law Applied
In this example, what kind of software structure (e.g. architecture) would we expect to find?
- A structure that is well modularized?
- One that helps developers able to work on their own and avoid conflicts?
- A system is easy to maintain?
- One where the system is flexible and can be extended easily?
Nope.
We should expect the opposite.
Conway’s law states that the system, in this case, will look like it was built by one person – the CEO.
Why Does That Happen?
There are many reasons how and why this is the result.
The CEO, in this example, might have no idea how the software is actually structured (because he/she is not directly involved in the software code).
Yet, all his/her’s decisions are approaching the system from his/her’s incorrect understanding. They might be optimizing certain business ideas or features. Or even “suggesting” certain software development approaches that they are familiar with.
And, of course, this leads to poor software code quality, poor software architecture, poor development practices, lack of team’s sense of accomplishment, etc.
It’s kind of like having your landlord tell you where your furniture should go. If that’s the case, don’t be surprised if your house is arranged the same way as your landlord’s house (due to Conway’s law)!
People And Teams
We looked at an example within the context of a small company. What about a large company?
Let’s take our diagram and, instead of having individual people, we’ll have entire departments represented:
In this example, the C-Suite is acting like the dictator CEO. It’s just a group of dictators now.
You can see, it’s not about individual people or even teams. It’s about how work is assigned, communicated, processed, etc.
The Organizational Dysfunction Messiah?
Well-read and experienced IT professionals recognize this.
Many articles and books talk about this.
The solution is often introduced as employing cross-functional or “product” teams:
In this example, the C-Suite isn’t telling each product team how to build something.
By virtue of creating a product team altogether, they have already decided what will be built (e.g. “product 1” and “product 2”).
The C-Suite has entrusted the responsibility of all the details to the respective teams.
Add A Bit Of Time!
This is a revolutionary idea for many people and businesses.
But it’s also not the entire solution.
The topic is often left at this: Cross-functional teams save everything.
But they don’t.
The fact is: organizational structures change over time.
People in the company change over time.
Teams change over time.
Take this example:
The interesting question is what if we applied Conway’s law?
Conway’s law is true but we often simplify how complex real-life can be.
Conway’s law applies throughout time!
The implications of this are huge.
Systems Over Time
Anyone who’s worked on a piece of software that’s been around for a number of years knows all about this:
New Developer: “Why is this part of the software code written so strangely?”
Knowledgable Developer: “Well, that’s because Bob (who’s since been fired) decided he would build that on his own. He thought it would be cool to apply some new programming patterns he was learning.”
New Developer: “Ok. So, why is product A using a different programming language than product B?”
Knowledgable Developer: “Well, product A was originally written by our technical founder and CEO. Since then, our developers have built product B using more modern programming languages.“
New Developer: “Ok. So… what is this project? Is this project used anywhere?”
Knowledgable Developer: “Well, a while back one of our previous teams decided to re-write the entire system. Since then, some of those members quit, were fired, etc.
By the time everyone from that team left – no one else knew how to use that project or how it was even supposed to work. So we abandoned it!”
Sound familiar?
What type of system comes out from this?
Often, you’ll find software systems that have many “odd” and “custom” ways of doing things…
The Need For Tech Strategy And Vision
These scenarios (and realities) highlight the essential need for tech strategy and vision.
Tech businesses cannot expect to apply Conway’s law at one point in time and assume that everything will be fixed.
Employees leave.
Teams are disbanded.
New people join teams with different perspectives.
Business goals, products and focuses change over time too.
Change is the only constant.
Stability Through Change
Parts of the human body will regenerate themselves over a period of days or years, depending on the organ and type of cell.
Isn’t that strange?
Your bones, according to this link, will completely renew themselves over a period of ten years.
What about your software business?
Most software developers will leave their place of employment way before 10 years.
Many businesses will not be the same in even 2 years.
How do you ensure that your software systems are stable and the goals you were shooting for are still able to be reached? Even if you have an entirely different team of software developers and employees?
You need a strategy.
Tech Strategy
Let’s say that your business has decided to re-write one of its software products.
What will happen without a strategy is that, over a few years, the company may lose one or two key members of the team.
Most of the strategic knowledge is lost because it was never captured, to begin with.
By losing these key software developers, you’ve potentially lost the entire project.
No else on the team may have the technical savvy to hit the next milestone – let alone even know what the next milestones should be!
In this case, a basic strategy could save the project.
What A Basic Tech Strategy Looks Like
What would that tech strategy include?
- How are we going to split the project into smaller chunks and what do they (roughly) look like?
- What techniques are we going to use to re-write these chunks?
- Which chunks are quick-wins? Should we tackle those first?
- Are there any major milestones throughout the entire process?
- If so, what will the overall structure and architecture look like at each milestone?
- If we need to hire/re-hire, what skills and experience ought we value the most for this project?
- Are there milestones where, based on Conway’s law, we might need to consider re-organizing our company structure?
- Will we face any major risks? If so, what are some approaches, techniques, strategies, etc. to mitigate them if they occur?
One of my favourite introductions to “splitting up” a system is a presentation by Sam Newman about monolith decomposition.
Also, using the domain-driven concept called bounded contexts will help to facilitate splitting up an existing “messy” system.
Next Steps
If your software company has struggled with some of these issues, then you might want to consider solidifying a tech strategy and vision.
If you want to keep going on this topic, then take a look at ThoughtWorks’ Technology Principal Consultant Sarah Taraporewalla’s article about what defining a tech strategy document might look like and include.
Like Sarah, I believe that teams should adopt an evolutionary approach to software architecture, among other things.
Having a well-defined and effective software strategy and architecture can mean releasing that next big product in one year instead of never, helping to onboard new technical staff members and giving the team a sense of direction and safety.
One reply on “Conway’s Law Is Temporal: Why Tech Strategy & Vision Matters”
[…] for the moment or building out that new product users have been waiting for? They will have to build some sort of strategy for the […]