You're in charge of change, and now you need to talk about DevOps hater Robin
So many good reasons not to get with the program
Here you are, doing the DevOps so hard you've broken the spine of your DevOps Handbook, but Robin won't get with the whole "culture thing".
Robin sits in the stand-up meeting, arms crossed, each morning mumbling "Well, I wrote some code" and then takes that long, loud sip of tea.
And who's going to have to do something about it? You.
Perhaps Robin has it right. This round of transformation might be the same squiggly pit of offal as the ones that came before. Throughout their career, the Robins have been force-marched through several searches for excellence and are now ready to ensconce themselves in a lovely, little cottage curating their model-train collection. Change is tiring, especially if every five minutes you have to change again because the old system didn't work.
How did they get this way?
Sure, DevOps (and the broader meatware of agile and lean software) emphasise continuous learning, change, and adaptation as part of the process. That might make you assume that past improvement initiatives were static – as is often the positioning of The New Methodology. To be sure, whatever the process du jour, an organisation tends to calcify, cementing in tickets and change advisory boards like rebar. However, it's not like anyone who comes up with an IT methodology sets out to make a crappy one. ITIL doesn't kill good software, people do.
Empathy is an important tool – high performers of DevOps say so, and most general management hands would concur. Who wouldn't identify with the issues behind the attitude? Your organisation's "Robins" likely had one incident, if not many, of transformation betrayal and have since learned the proper way to ride the stack-ranked wave without drowning. They have no reason to trust that it'll work this time and be worth the risks of trying something new.
Using a trick from the ancient tome of transformation, Leading Change, look at the alignment of your HR policy: "Performance appraisal. Compensation. Promotions. Succession planning. Are they aligned with the new vision?"
If not, it's an indicator that Robin is justifiably crotchety. A recent Forrester study shows that performance appraisals mismatches are widespread. Improving your software capabilities is largely about improving customer satisfaction, but the study found that "only 20 per cent of individual developers use customer satisfaction to measure success".
People are rational – if they sniff out that you're a facile change agent, singing the praises of a new way and then doing nothing to change the compensation system, they'll wrap themselves in a coat of many tickets.
Many organisations also use a volunteer model, which sets up a new organisation and only takes volunteers for the first handful of projects.
Jon Osborn describes this tactic at Great American Insurance Group: "We used the volunteer model because we wanted excited people who wanted to change, who wanted to be there, and who wanted to do it. I was lucky that we could get people from all over the IT organisation, operations included, on the team... it was a fantastic success for us."
The theory here is that businesses are immutable: once you put a system in place, it can't really be changed. If that system can't be changed, you can't change the incentives and rules of the game, meaning you can't change how people behave. Setting up a new organisation gets around that problem, potentially addressing the paranoia of those like Robin. The volunteer model also allows people to self-select and stay behind. There are plenty of ERP systems to manage, after all.
About that model-train collection
There's a good chance that change, even after all that, could be hard coming.
Executives tell me that anywhere between 30 and 70 per cent of staff will have difficulty shifting to a new way of doing IT. One manager grimly told me – literally, in a poorly lit parking garage – that they should have ditched more. Of course, training and hiring replacements is a huge problem. Cutting heads should be the last resort, lest the grave you're digging for them turns out to be yours.
While it's fine to, you know, actually care about the mental well-being of people, making sure staff are happy increases your chance of success. "Research has shown that 'companies with highly engaged workers' grew revenues two-and-a-half times as much as those with low engagement levels," as the recent DevOps book Accelerate summarises a 2012 study.
The answer? Ultimately, it's best to first be empathetic and humane, even using people like Robin as a canary in the change coalmine. There will be some that are fixed in mindset and can't be helped, but most of them will likely help you find and fix systemic problems, getting you one step closer to improving how your organisation creates and uses software. ®
We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.