Conway’s Law gets misquoted a lot, and that could hurt your organization

If you’re not familiar with Conway’s Law, it comes from Mel Conway who wrote the seminal paper. The law in one form reads:

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

It often gets misquoted by saying the structure will follow the organization’s team structure, or that you will whip your org chart.

The truth is, if your communication structure doesn’t match your desired architecture, it’s your communication structure that’s going to win. There’s a technique in organization/system architecture called the “Reverse Conway Maneuver” where you know what architecture you want, so with the old one still in place, you reorganize your teams to support and enable your desired architecture.

I don’t see another practical way to actually make the changes you want, but there’s a huge risk if you take adopt the misquoted version of the law. You could structure your teams to perfectly match the architecture, but within the teams, they still communicate in the legacy communication patterns.

For example, suppose you have a 3-tier system, and you had your tier-1 team, tier-2 team, and tier-3 team. You recognize that every feature you ship cuts across all three of those tiers, so you shuffle people around into teams aligned along the value you want to deliver to your customers.

Only trouble, the legacy system still exists, and the teams don’t step up and assume cross-functional ownership of their new parts. The members of the new teams who were previously tier-1 keep taking all the tier-1 work and only work closely with each other, not building the bridges and shared understanding of that tier among the rest of the team. And the other tiers do the same thing.

Here’s the deal, y’all. Getting to the new system you want is hard Half-measures won’t cut it. People will revert to familiar patterns. It’s what we do.

You as a manager are the only thing that can enable the change. People fall into familiar patterns because that’s what they’re measured by. You have to lead the charge, saying, “We know we’re changing a lot, and that’s going to mess up everything you’re familiar with. It’s okay. You won’t be punished, and you’ll get the support you need as we adjust to this realignment.”

An architect can’t do that for you, and no Batman is going to emerge to do it for you either. You’re the leader.

This is your job.


Like this message? I send out a short email each day to help software development leaders build organizations the deliver value. Join us!


Get the book!

Ready to learn how to build an autonomous, event-sourced microservices-based system? Practical Microservices is the hands-on guidance you've been looking for.

Roll up your sleeves and get ready to build Video Tutorials, the next-gen web-based learning platform. You'll build it as a collection of loosely-coupled autonomous services, developing a message store interface along the way.

When you're done, you'll be ready to contribute to microservices-based projects.

In ebook or in print.