DevOps - When Two Worlds Collide

(I know that it was a while since my last post, but I promised to explain why we had our silo-organization in the first-place: Very simple answer: This is how Enterprise IT traditionally looks in 99% of organizations.)

I believe that organizational structure with its silos and associated processes is the ultimate embodiment of corporate culture. And what is the main driving forces behind a culture? What is the only force than can change an organization in the end?

People of course! They way of working, their sense of self-worth and of course their ambitions and dreams.

“It’s about people, stupid!”

In all my talks about DevOps during the last years I always repeat the mantra: It’s about people first, processes second and tools last.

And a lot of the people I talk to readily accept that changing silos/organizations is hard – but we rarely discuss about the reason why that is so hard and what we really need to do about it. I have zillions of discussions on processes and tools but very few on this topic.

I was puzzled by this at first but now I think I understand this: For the person, I talk to it is very clear what needs to be changed – and most of the time it is the other girl/guy.

I want change – I want stability

Once I realized this I started to explain how the “other girl/guy works” and thinks. I call this “The Dev and the Ops in DevOps”-story and it is of course grossly over-simplified. It goes like this:

A developer superstar is usually the girl/guy who has magic coding hands and can deliver new features the fastest (of course with a certain level of quality but that is a topic for another post).

Her/his KPI is rate of change.

The operations superstar is usually the girl/guy who has the magic repair hands and can fix broken things the fastest – the person you call at two o’clock at night when everything is hitting the fan. She/he has learned time after time that 80% of outages are caused by changes. Because everybody in Ops knows the golden rule: Never touch a running system.

Her/his KPI is keeping the lights running = stability. For the Ops person Dev = Change = Bad.

On the other hand, the Dev person has learned that if she/he needs a quick change, she/he needs to find a way around the Ops person and all her/his pesky processes like ITIL Change Management. This is theory of course, in reality no one would dare to do such a thing, but …

If men are from Mars and women are from Venus, then Dev is from Mercury and Ops from Pluto.

And herein lies the fundamental challenge in any DevOps transformation: We expect frictionless delivery by people and their organizations who have a different ethos, a different way of working, a very different educational background, a different professional history and conflicting “best practices” and KPIs.

If you think introducing Agile was tough, be prepared for Agile++ - since this is what DevOps really is in the end.

So here are some pointers to help you go forward on your DevOps journey:

1.     Talk to colleagues in the “other” departments. Maybe even do a short internship there. See what they see, do what they do, understand how they tick, maybe even share their professional dreams? It will an eye-opener every time.

2.    Read a good book on Agile transformation and Organizational Change Management.

3.    Get help from somebody who has done this before. DevOps sounds like a simple concept (just like Agile) but transforming any organization is simply not simple.

4.    Stay realistic. If you can’t change the Dev & Ops organizational set-up (most people can’t), focus on what you personally can change (see Point 1).

Thank you for reading and have a safe, fun & good start into the New Year!

This is Post 2 in my DevOps series. The first post is DevOps – It is a culture shift, not a technology!