If you want your company to be agile, then your organizational chart is critically important to your ability to execute.

(This is assuming you believe in Boyd’s Law: “Speed of iteration beats quality of iteration”.)

But why does the Org Chart matter?  What does that have to do with an organization’s agility?

Let’s start with a few core tenets.

Tenet 1: Over time your organization’s process flow will align with your org chart

This is what Harvard calls “The Mirroring Hypothesis”, also known as Conway’s Law.

Tenet 2: The maturity and agility of an organization can be measured by the speed with which it communicates

I can’t remember where I read this. CMMI training maybe? But this makes sense because your ability to change (“pivot”) depends upon your communications speed. On my team, we can huddle up and change what we’re doing RIGHT NOW if need be. But if it involves another team?

Let me ask you this, how easy is it to communicate with someone on your team? Probably pretty easy. What about someone on another team? OK, you might have a personal relationship with someone so its easy, but structurally and in larger bureaucracies its probably pretty hard.

Now synthesize all these things. What it tells you is,

Your ability to execute depends STRONGLY on your org chart.

Plain and simple.

OK, so….let’s think about the product lifecycle. From requirements to deployment and sustainment. Within this specific lifecycle you’ve got Dev, and you’ve got Ops. And typically at some point you have to transition your product from Dev to Ops. So, if you have on your org chart, those two teams separate, you have purposefully built in a limiter to your velocity.

So the simple solution? Reorg, and put those teams together. You’ve now allowed the product lifecycle to speed way up. In fact, in many cases (like CI/CD) its so fast its not even recognizable as a transition from dev to ops anymore.