I first heard about Conway’s Law from reading the “DevOps Handbook” (an excellent read, by the way, if you want to dive head-first into DevOps). I was intrigued by how this idea came from slightly left field, yet seemed to have big implications for businesses on their journey to increased efficiency.
In this blog, I will share my understanding of what Conway’s Law is and how it is relevant for your business, whether you are in the middle of a DevOps transformation or just taking your first steps.
What is Conway’s Law?
In 1967, Dr Melvin Conway submitted a paper to Harvard Business Review. It stated the following observation: “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
This statement was later dubbed “Conway’s Law“.
What Conway’s Law Means for the DevOps Journey
Conway’s Law explicitly mentions the system design and communication structure. However, this idea can also be extended to include team structure, which is usually aligned either to systems structure or communication channels.
When it comes to delivering streamlined and efficient change, Conway’s Law suggests that we should align all these areas to the overall business model. This is a concept that also sits at the heart of DevOps, and is a cornerstone for improving efficiency and overcoming delivery bottlenecks.
The Importance of Alignment
Alignment between these four areas is critical for becoming truly agile and thriving in today’s online and digital world. Without it we will hampered by heavyweight handoffs, conflicting team goals, and resistance to change.
The larger the organization and the more siloed the teams, the more pronounced the constraint described by Conway’s Law is. However, organizations with more nimble, collaborative teams are free to design their systems in the most efficient way, not restricted by inefficient wasteful processes.
Dealing with Misaligned Team Structures
In IT, with its constant flow of new projects and requirements, we are always improving our systems in response to changing strategies and directions from the business. So why shouldn’t we have the same mindset when thinking about our team structures?
If our team structures aren’t evolving to meet the current needs, then we are inadvertently constraining ourselves to only deliver solutions that fit in with our existing team structures. This makes innovation difficult. Similarly, we need to mold our communication and collaboration structures into the right shape for our systems, based on business goals. This will, in turn, define how we organize our teams.
With knowledge and understanding of Conway’s Law, we can actively design systems, team structures and communication channels to avoid the pitfalls of misalignment.
Overcoming DevOps ROI Barriers
DevOps is an incredibly powerful approach to IT. But for DevOps to provide value to your organization, you need to address team silos and collaboration gaps. If you cannot align collaboration channels with your business needs, then no amount of automation or DevOps change will help your business to achieve agility.
For some businesses, team structures may need to change dramatically. For others, it may just be a case of increasing collaboration between specific teams, or creating ways to improve the efficiency of handoffs and reduce wastage in processes.
Aligning Teams to Business Goals
Overall business success isn’t siloed, and team/department success shouldn’t be either. Sharing KPIs and dashboards is one important way of ensuring that teams stay aligned to business goals by improving staff mindset and reducing distraction.
So what do fully aligned teams look like? In businesses delivering IT change, teams will be aligned to products or market sectors. This means each team will be as autonomous as possible, without cumbersome handoffs.
Often aligned teams will incorporate all speciality skills (such as information security, infrastructure and DBA) within their own team. However, it is becoming more common to solve the alignment problem by improving the efficiency of interactions between teams through self-service. For example, self-service environment provisioning enables delivery teams to function independently throughout the delivery life cycle without any environment requests or delays.
The Art of Collaboration
We are currently seeing a big shift in culture across many organizations, powered by the fast uptake of new collaboration systems. Tools such as MS Teams, Slack and HipChat remove barriers between teams and improve communication, making it easier to align collaboration channels with your business goals.
However, just using a shared collaboration tool does not guarantee streamlined business delivery. While it may be quick and easy to create a new channel or chat group, creating a culture where collaboration evolves alongside business needs is much more difficult.
The key to a collaborative culture is trust. Everyone needs to know that the entire team is working toward the same end goal, with shared responsibility for the results.
Closing Thoughts
When staff are in heavily siloed teams, they can be easily diverted away from the business goals. Staff might also resist change as they haven’t got the business view. But when teams, systems, and collaboration channels are fully aligned to the business goals, all employees will understand their impact on the business—and measure their success against the business success.
I hope this insight into DevOps from the perspective of Conway’s Law was useful, and you have some ideas to foster greater collaboration and efficiency in your business.
