When you’re sitting down to design a business process, it can sometimes be challenging to find a way to cut across the company’s organizational structure. Breaking down company silos to re-engineer a business process isn’t easy. Therefore finding efficiencies isn’t easy either.

It turns out there’s a reason.

As far back as 1967—yes, almost half a century ago—a programmer named Melvin Conway was writing about software development when he noticed a funny thing: You could tell a lot about an organization by the kind of computer programs it designed.

The classic example was that a program with n modules or passes had n+1 guys on the project—one guy for each one, plus another guy to manage them. In other words, with a five-person team, the project would typically be divided into four pieces.

Conway wrote up his observation for Harvard Business Review. “HBR rejected it on the grounds that I had not proved my thesis,” he writes. Instead Conway published it in Datamation. It became a classic, and spawned dozens of variations and corollaries.

Ironically, in 2008, Harvard Business Review did publish a study of Conway’s Law, and the study demonstrated that Conway was right.

“Their study found that the often co-located, focused product teams created software that tended more towards tightly-coupled, monolithic codebases,” writes Sam Newman of ThoughtWorks. “Whereas, the open source projects resulted in more modular, decomposed code bases.”

Eventually, the observation was codified into “Conway’s Law” in the seminal software project management book The Mythical Man-Month, by Frederick Brooks (the guy who explains why throwing more people at a project doesn’t get it done faster). Brooks defines it as: “Organizations that design systems are constrained to produce systems that are copies of the communication structures of these organizations.”

You might say, who cares how many modules the program has? The problem is that even if people inside the company understand how it works, people outside the company trying to interact with the program might have trouble.

“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,” writes Stephen Fishman in CMSWire. Think of how difficult it can be to work your way through a voicemail system or customer support website, he explains.

Conway points out, too, that Conway’s Law isn’t limited to programming or software engineering, but to just about any process designed by just about any organization.

But there is a way to work around Conway’s Law. Fishman suggests a variation on the “sticky note” technique that is common when getting started with workflow He calls it “card sorting”:

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

The thing to remember is Conway’s Law can be used the other way, too. If the program or business process you’re designing seems disorganized and convoluted, chances are it’s because your company is disorganized and convoluted, too.

In fact, you may find that you need to reorganize the company to be able to develop business processes and programs more efficiently.

“How we organize defines how we think collectively, and thus what we make collectively,” writes programmer and author Pieter Hintjens. “How we organize is more important than who we are. Smart people in bad structures produce trash. Ordinary people, well organized, can produce precious gems.”

As a corollary, if you’re trying to develop software using the Agile methodology and your organization is large and hierarchical, you might have trouble.

If nothing else, once you develop a more streamlined business process, the company should at least consider the notion of reorganizing to support it. After all, if it’s more efficient for the process, isn’t it more efficient for the company, too?

“If the system design is to be free to change, the organization must be prepared to change,” Brooks writes. Or, as open source programmer Jesse Toth puts it: “We should model our teams and our communication structures after the architecture we want.”

Maybe we should call it Toth’s Law.