Conway's Law, the Map, and the Territory

We've looked at why best practices don't seem to work and how to start detangling the resultant mess. Now we’ll have a look at the shape of the problem using a well-known axiom — Conway's Law.

In my discussion of best practices, I said "We make a big mistake when we try to solve our people problems with technology, or fix the software by restructuring the organization." Melvin Conway spotted this essential connection all the way back in 1967.

He wrote:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

It's one of those ideas that seems to have a resurgence every time we try to reckon with the big software design questions.

 Looking at how organizations have applied Conway's Law, you see phrases like:

•  "breaking down silos", 
• "creating transparency", and 
• "embracing new structures" 

There are a number of ways that Conway’s Law could be applied, but it's especially interesting that communication structure is the point Conway identified. Not the org chart that shows who you report to,  but who are you talking with?

Your technology stack has communication, too:

• Code components have inputs, outputs, even formal APIs. 
• The CI system has triggers, workflows that pass data to the next step, and hooks that listen for the result. 
• Your infrastructure stack is full of communication protocols. 

Many of the details are so embedded, we stop even thinking about them in these terms.

The industry-wide push toward microservices makes sense in this context. It's a lot easier to find the communication structure when looking at a set of discrete parts with clear boundaries. But human teams are never that straightforward. And we value the flexible borders between groups of people -- water cooler chats solve all sorts of problems.

Begin with the map

So when you know you need to change these intertwined systems, where do you start? It's important to know where the actual communication lines and interfaces are. You'll need some sort of map. Otherwise, you’ll get the kinds of re-orgs that seem to leave everyone worse off than when you  started. 

Some data could also help: how is the code currently organized? Who reviews the PRs, and who has commit access? 

Same goes for the infrastructure. Look at the people involved, but also actors like service accounts. Do the assignments make sense?

Refactoring teams and tech as one system

With your map in hand, you'll be able to start refactoring. When we refactor code, we generally don't delete it and start over. We add some tests, look for duplication, find things that can be simplified, document parts that are hard to follow. It's a little bit of this, a little bit of that, trying to move in a single direction. You have to be sensitive to the details: what looks like duplication could have subtle differences from different requirements.

Teams can be like that too, and they have more opinions about being moved around than the code does. We need to make thoughtful decisions about how to proceed. Software engineers hate wasted effort, so contributors probably already know where a lot of the pain points and bottlenecks are happening. If you're a manager and you're not regularly asking the team, "what would help you work more effectively?", these bottlenecks are  a great place to start.

What's the ideal endpoint of our efforts? It can't be static, because requirements change and technology continues to advance. We need to build up practices that facilitate effective change throughout the organization and technical stack. That could look like:

• more autonomy for individual pieces, or 
• more consensus-building, and  
• simply learning how to share actionable information. 

Remember to keep looking at the connections between things, not just the separate parts. That's what Conway's Law shows us.

Shameless plug: OpenContext will kickstart your effort to connect the dots between your technical stack and the people who work on it. Sign up for the beta and see what's really going on in your org.

‍

Photo credit: CC-BY #WOCinTech Chat