You Cant Escape the Long Arm of Conways Law

2015-22-April-No-Escape.jpg

You already know about Moore's law and how it describes the miniaturization of chips. You may know about Goodheart's law and how it describes human behavior regarding quantitative metrics. Have you heard about Conway's law and how it is constantly clashing with your efforts to bring customer centricity to the enterprise?

I Fought The Law and The Law Won

In 1968, an early computer scientist named Melvin Conway first introduced the law that drives either the organizational design, the software design or both for some of the world’s leading technology companies.

Often times when people hear Conway’s law, they think it's a humorous joke or a zen koan. But if you mention it in a discussion with technology architects, computer scientists or organizational theorists, you will find that most believe it to be a truism that cannot be overturned. And that, at first glance, looks like horrendous news for user experience designers everywhere.

Conway’s law states that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations." In software implementation land, this means that system interfaces will always mimic the communication and organizational structures of the teams that produced the system.

This one simple idea has API enthusiasts all over the world scratching their heads trying to figure out if they should a. let the law have its way with their designs, b. attempt to fight the law and come up with a new design methodology, or c. embrace the law and design their organizations to allow the desired architecture to naturally come into being.

The downside to Conway's law is that it essentially forces consumers of services and information into understanding the hierarchy and communication structure of your organization if they want to master your tools and engage with you. Almost everyone in modern society has to deal with these effects when they:

  • call a vendor or service organization for support and get sent to the dreaded IVR labyrinth. This pushes the caller into the multi-call-transfer game with different people representing different organizational units within an enterprise
  • are faced with a technical issue and have to navigate a hierarchy-driven funnel to fill out a web form. The form puts the description and categorization of the problem in terms that mirrors the support organization structure rather then how the user views his or her problem

Experience strategists, marketers and design philosophers recoil in horror from these effects. This law contradicts a basic paradigm for them: great experiences are conceived from the outside in and built from the inside out. For the service provider, this basically means that people inside a system must adopt the mindset and context of those they serve -- to force the reverse will never yield a great service experience.

It can be depressing, given that both Conway's law and the reasoning behind it sound pretty air tight, but UX practitioners have come up with a mechanism to bend the law: card sorting.

With a Card Up My Sleeve, What Would I Achieve?

Card sorting exercises emerged from cognitive psychology research in the 1950s to measure people's ability to apply abstract reasoning and problem solving adaptability. As information architecture began to take shape, specialists began using card sorting to identify common mental models and categorization schemes for sets of information and content, all from the point of view of the intended audience (i.e., the outside perspective rather than the inside perspective).

Card sorting exercises and interpretation of results require some technical knowledge, but the concept is fairly easy to grasp. The actual costs of the exercise are relatively low compared with other forms of research. The basic steps of card sorting are:

  1. Make a set of index cards representing each of the concepts and content objects you want to make available
  2. Have people representative of the intended audience sort and categorize the cards in whatever way makes sense to them
  3. Perform statistical analysis to find the most common mental models held by the audience
  4. Design your categorization scheme based on the exercise's findings

This exercise can be applied in API design exactly as it has been applied in designing navigational systems. The only real difference is that the audience in this case would be primarily a development community.

Once a series of audience-centric maps of business concepts have been identified, the remaining problem is how to take the intended design and apply it onto a siloed development organization with a different mental model of the system concepts.

The Long Arm of Conway's Law

The information scientist and search technologist inside me says, “This is a taxonomy problem. Multi-parent hierarchies are common, and findability can be solved with synonym rings, meta-tagging, controlled vocabularies, stemming and other enterprise search technologies.”

The enterprise architect and organizational behavior student inside me says, “Design your organization to drive the architecture you want.”

This is where the two perspectives meet and then diverge. The current trend for API architects and enterprise architects is to push for an organizational design based on a desired technical architecture. Information architects and UX practitioners would be OK with this as long as the desired technical architecture mirrored the predominant mental model of the consuming audiences. This would also have to include mechanisms to support multiple perspectives, including the point of view of someone who doesn’t know what they are looking for.

More often than not, this is where the bigger power steps in: finance. “Conway, Schmonway! Find out which way is cheapest to build and maintain, and design based on that.”

Given that most everyone wants to go home with a paycheck and that next to no one in either IT or UX has the power to drive organizational design like Werner Vogels, CTO of Amazon, most of us will have to settle for charting a multi-year roadmap and attempting to both steer clear of and be integrated with the long arm of Conway's law.

Creative Commons Creative Commons Attribution 2.0 Generic LicenseTitle image by  Sam Judson