You’ve probably heard the phrase “we ship our org chart” or something similar. It was first observed in 1967 by Melvin Conway, and the adage is referred to as “Conway’s law”. There are various corollaries to the law, and the observations have held true for over 50 years. The structure of our technology systems reflects that of our organizational structure and our organizational behaviors. This phenomenon works in both ways. We not only reflect our org in our systems, but then once established, our systems have the same effect on the organization.

That mirroring, and repeated mirroring from org to system and then system to org, gets down to the root of what makes change hard and why seemingly innocuous technology decisions can have lasting, intractable effects.

There is only one truth in a computer system and that’s the code. Okay, fine, it’s the code and the data. The code and the data don’t lie, and they represent the structure and behaviors of the organization.  

From an archeological approach, there is no better way to understand the history of an organization than to look at the legacy technology landscape:

• The names of long-ago initiatives championed by executives long departed from the organization.  
• The project that ran out of funding half-way through implementation with layer upon layer of band-aid fixes applied.
• The grand rewrite in the sky, and then the grand-rewrite of the grand-rewrite.  

That’s a hell of a lasting effect.

Over time this type of landscape becomes an unforgiving system. Trying to touch or change one tiny piece of it becomes a chain reaction of “what about” discussions that lead nowhere and keep the organization stationary, and the unforgiving system even more entrenched.

The business wants and needs change and innovation, but the systems are structurally preventing that from happening. That’s why breaking the cycle happens with how we start approaching our technology, our modernization, and our loosening of the unforgiving system. To do that we have to start behaving differently, at an organizational level, and we have to continue to reflect that in our systems over the long haul.  

If we aspire to be an innovative organization, a forward-thinking organization, a change-oriented organization, and we’re not seeing it in our product, then we are just paying lip service. We have to do it, and not as a grand rewrite in the sky. It’s the concerted effort over time. The little changes that add up. It sounds trite and cliché, but it’s been proven again and again that’s how lasting change happens.

Ok, great, but WHAT do we actually do. Seams, and Constraints.

Look at whatever that thing is that you’ve decided to do differently this time. How smooth is it? Don’t accept the dependencies, break them. Don’t keep branching on tangents, stop and prune them. Your organization is designed for one thing and one thing only, to resist change. Your systems have evolved over time to reflect that resistance. So, with this next initiative, or project, ask your architects thigs like:

• What are the things we want to evolve?  
• Where can we introduce seams to allow us to change?
• What’s the core business domain we want to protect?
• Are there any vendor details that have leaked out into our domains? How do we eliminate them in the very near future?

Look at your Delivery Value Stream. Do some quick (like whiteboard sketch quick) Value Stream Mapping and find the constraints. Measure it and eliminate it. Antiquated policy? Get an exception (or deprecate it).

As the systems now become more flexible and easier to work with, the vendor details are hidden, and change becomes easier. The unforgiving system tied to the unforgiving organization is now able to move again.

Whether you realize it or not, you’ve now started to influence your systems AND influence your organization.  

You’re shipping your org-chart whether you like it or not. Do it intentionally and be proud of it.

For more on becoming a Frictionless Enterprise, download the book.