I recently had the privilege of catching up with a former colleague, Erin White, who works as an Information Architect for GovTech and was previously the Head of Technology for the library where we both used to work. (Interestingly, Erin was my first hire as a new manager – let’s just say they had a lot of patience with me 🤪 Thanks Erin!)
We talked about teaching IA, and both mentioned Conway’s law, which made me a bit nostalgic for our program in Information Science. Way back in 2006, we both wanted to break down siloed navigation on the library website, moving it from an organizational and departmental view to something more user-oriented. It’s funny because, since that time, I’ve been in a number of organizations that still rely heavily on the old hierarchical organizational chart to design new processes, lines of business, products, services, and more. I chuckled to myself after Erin and I spoke while also shaking my head and musing over how one seemingly benign document can so negatively affect experience design (XD)! Note: When I reference experience design in this post, I mean all aspects of CX/UX/EX/Service Research & Design.
After chatting with Erin, I started thinking about what advice I would offer new XD strategists or designers entering the field without business knowledge (and probably any knowledge of enterprise silos and their impact on XD). My advice is simple: deeply understand the business, the people/employees, and how decisions are made across an organization. Over the years, I have come to the realization that one of the biggest challenges in an XD career has less to do with research and design – yes, obviously those are important and you need to intimately know your stuff – rather, the challenges you’ll face working in an enterprise or really any complex system are driving designs through organizational silos and persuading others to change.
What is Conway’s Law?
Conway’s Law, named after Melvin E. Conway, states that “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” In simple terms from Wikipedia, this means that complex products, systems, and projects often resemble the organizational structure in which they were conceived.
I learned about Conway’s Law in grad school, which was made famous among software engineers in ‘The Mythical Man Month,’ by Fred Brooks, Jr., a renowned computer scientist from UNC Chapel Hill. Brooks, often referred to as the father of the IBM System/360, wrote about software project management in the ’60s and ‘70s. Although I obviously didn’t pursue software development as a career, Brooks’ words left a lasting impression on me as I expanded my career in experience strategy and design at both large and small organizations.
Conway’s Law in Practice
Conway’s Law has been referenced over the past 30 years in a wide variety of software development, DevOps, Agile, and Design articles. Even Dr. Conway himself expanded upon his original definition, stating:
Conway’s law was not intended as a joke or a Zen koan but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.
Martin Fowler, a software architecture thought leader and guru, used Conway’s Law to describe design systems in this simple, yet elegant diagram effectively showing how organizational communication structures create design silos.
Sketchplanations has an incredible overview for visual folks, outlining Conway’s law for software architecture. As they note in their article, this concept can be applied to a variety of settings and projects: “cruise ship design, car design, space shuttle design, heck maybe even governments and law. “
The accounting software organization, Xero, wrote about how they use Conway’s law to organize their teams effectively and improve communication across the organization. They note, “Conway’s Law, which simply put, means the architecture of a system is a reflection of the communication patterns between the teams that built it.”
And, Atlassian also published a fantastic case study about the Australian Centre for the Moving Images that covers how the organization broke down silos to create seamless experiences in their physical and digital spaces. They also implemented an organization chart redesign led by their staff, resulting in improved employee and customer interactions and experiences.
XD as a catalyst for organizational change
Throughout my own personal journey in XD, Conway’s Law deeply affected how I operated. The adage challenged me to learn deeply about any business I was a part of, to listen more intently, and to better understand stakeholders in each department across an organization. I learned (over 20+ years) that in order to craft truly distinctive and unique experiences that surpass an organization’s internal structures, you need XD teams who can simultaneously consider the inner workings of an organization and think innovatively about what exists beyond its walls.
Designers need to have a deep understanding of the complex intricacies of business, people, and culture to drive forward changes in the experience. This requires them to get under the hood, understanding internal challenges and cultural norms, silos, personalities, organization structure, communication flow, and politics. XD teams make a difference by transforming business and human understanding (and even organization charts) into something useful for employees, users, and customers.
Creating change on this scale and ensuring that your experiences are not a replica of your internal organization cannot be done by designing products or services screen by screen, micro journey by journey. Rather, it requires XD teams to possess effective communication across teams, departments, and divisions, and a willingness to work horizontally in an organization.
Working in this way is neither an easy task nor for the faint of heart. It requires convergent and divergent thinking. It requires determination and grit. It requires patience, listening, and a huge amount of communication and change management skills. Teams also need an organization whose culture is flexible and willing to accept that teams need to work cross-functionally.
Where to start
As a new XD strategist or designer, start first by learning about any silos that exist in your organization and how Conway’s law affects your XD, your team, your stakeholders, and ultimately your customers. Think about: What departments exist in your organization? Who runs them? What makes those people tick? What opinions and beliefs do they have about design, your customers, your users, and your products? Finally, pull up the org chart that lives in the land of infinite cubbyholes (your intranet). As Seb Chan, the first Chief Experience Officer (CXO) at the Australian Centre for the Moving Images advises:
Look at a company’s organizational chart to figure out what they care about. You can see through the reporting lines where things get stuck and why the visitor (or customer) experience gets janky. Maybe your digital team is part of the IT team, so everything’s looked at through an enterprise lens rather than a user-experience lens. Or your digital team reports to marketing, which means they might be accountable for social media and data capture through narrow marketing.
Understanding nuances about your internal organization prevents replicating its structure to your external customers and users through your communications, content, design, and experiences.
What are your thoughts?
How has this adage affected your projects in your organization? How has it affected your service, products, or experience designs?
Learn more
- Wikipedia – Conway’s Law: https://en.wikipedia.org/wiki/Conway’s_law
- The Mythical Man Month: Essays on Software Engineering https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959
- Mel Conway’s Website: https://www.melconway.com/Home/Conways_Law.html).
- Martin Fowler on Conway’s Law: https://martinfowler.com/bliki/ConwaysLaw.html
- Xero – How we used Conway’s Law to create high-performing teams. Making sure domain knowledge resides in the collective, rather than individuals https://medium.com/humans-of-xero/how-we-used-conways-law-to-create-high-performing-teams-41f94700ef5b
- Conway’s Law: the little-known principle that influences your work more than you think https://www.atlassian.com/blog/teamwork/what-is-conways-law-acmi
- Convergent vs Divergent Thinking: https://practicalpie.com/convergent-vs-divergent-thinking/
- Sketchplanations, Conway’s Law:https://sketchplanations.com/conways-law