[Reading time: 1 minute 30 seconds]
Org charts are mysterious things anyway, steeped in ceremony and suffused with mysterious power.
Here’s the mystery’s mystery, just for you: shadow org charts.
Freeeaky.
I can picture your raised eyebrow, though. What am I going on about?
Well, it’s something you’ve doubtlessly encountered many times: there’s the published org chart, and then there’s how things are actually done.
There’s perhaps a respected engineer who has at least as much influence on the architecture as the architect, although she’s nowhere to be seen on the org chart.
There might be a secret CI team: those people everyone asks for help when they need advice or work done on Jenkins.
Or the database team is actually two teams, because one part focuses MongoDB, and the other on Postgres. And they support entirely different teams.
This, of course, comes as no surprise to anyone who knows Conway’s law.
The shadow org chart is what’s called the “reverse Conway”: instead of the organisation shaping the product, the opposite thing will also happen.
What both have in common, though, is that it doesn’t feel right.
There’s an obvious mismatch. And inevitably it leads to frictions, inefficiencies, wasted effort, perhaps even office drama.
Here’s the thing: the more you adopt DevOps practices and DevOps tools, the more your organisation will change shape.
You can either pretend like your org chart is still perfectly fine, and live with the friction and awkwardness.
Or you can work with it, actively shape the change that’s taking place, and reap the benefits. The change may be startling at times, but in my opinion there’s really no alternative to it.