'Do the DevOps?' No thanks! Not until a 'blameless post-mortem' really is one
Can't blame middle managers - they always get the stick
What drives organisations to change their ways? What's the match that lights the powder keg of actually doing something new and different in IT? That's the question I usually get from organisations that want their approach to software to be more "agile", who want to go through "digital transformation", and, yes, "do DevOps".
Despite glee about cleansing themselves with the buzzword of the week, they feel like they can't get their organisation to go along with it. While upper management might be pounding the table, shipping in crate after crate of DevOps Handbooks, the rest of the organisation languidly keeps to their old waterfall ways of doing software – maybe wagilefall, if you're lucky.
How do organisations that "go agile" actually motivate themselves to get out of bed in the morning?
Kick them in the pants
It's common to trickle down blame to individual staff and the so called "frozen middle" who keep existing processes in place. Higher level executives, though, aren't much better according to a recent Altimeter study. Of the 500 executives surveyed, only 37 per cent said their organisation was proactively investing in "digital transformation" (let's just assume that means "improving how we do IT around here to help run the business better"). Put another way, 63 per cent seemed content with their IT.
In my experience, most organisations who are looking to improve their software capabilities are motivated by a sudden, unexpected, often fierce competitor. Many insurance companies, for example, were spooked by Google's foray into car insurance. Fear motivated them understand what it would mean to have their market changed by companies like Google.
While the search giant decided to shut down the experiment after about a year, responding to this digital apocalypse premonition left several insurance companies with new capabilities and agile aspirations. They'd been given a kick in the pants that woke them up from their "if it ain't broke, don't fix it" stupor.
For most businesses, this kind of external threat is required to start any type of IT improvement plans, let alone something as high-falutin' as "digital transformation" or even DevOps with all its needs to radically change corporate culture. Without that well understood, and felt threat from outside, driving change can be too difficult for more organisations.
We fear change
Of course, simply kicking in a pair of well pressed slacks will only get you so far. There's the entire rest of the company that needs to put on their big boy and girl pants and find the will to change as well.
Below the higher levels of management, a more risk-averse culture thrives. Middle-management's job is to keep things stable, to keep the building from burning down. Which is all pretty easy if things never change, hence, "frozen middle". When looking at new ways of running IT, middle-management often sees only the possible downsides. Never mind all this "blameless post-mortem" stuff, I'm the one who'll get blamed and punished, they quickly realise.
Worse, in organisations that desperately do need to change from a large, multi-year delivery cycle for software (read: "waterfall"), the risks actually are huge. While big bang projects may seem like a gallant steed at first, with such long release cycle - on the order of years - these projects can easily blow up: they're liking using older infrastructure and application layer stacks and will also succumb to the trap of delivering perfectly the software that was specified three years ago and is no longer relevant today.
In such big batch projects, as one "change agent" put it: "A mistake could cost $100m, likely ending the career of anyone associated with that decision."
We can all agree that ending your career at middle-management wages is no good; unlike with executives, there’s no metallurgically coloured parachutes that land you safely in a lovely little chalet while the plane hurdles into the mountains.
Below that managerial permafrost, staff are full of anxiety as well. A recent survey of 1,000 managers in UK found that 49 per cent per cent of employees quake in their boots when “digital transformation” is mentioned. It’s little wonder given all the claims of how new technologies are going "optimise" staffing needs in IT, let alone how radically different all this new free-loving agile stuff is going to be.
As I mentioned a while ago, managers I talk with say anywhere between 30 to 70 per cent of staff "don't make it" to newly transformed organisations.
Stop hitting yourself
Based on the recent bevy of large orgs actually improving how they do software, clearly, there's hope for getting over all this trepidation. There are enough examples of large organisations switching over to a more agile, even "DevOps-y" approach to software.
What's clear is that in the best cases, senior management champions the change, often assigning an executive as "Chief Trouble Maker", as one executive described himself. These organisations also focus on creating safe spaces for innovation and change in process, usually over the course of several years. It's tempting to think that you'll figure out all this transformation overnight, but with a large org, it's better to temper expectations to reality. A misstep on managing the expectations of how long it'll take could easily kill moral and nuke your plans early on.
It's important to actually pay attention to winning the hearts, minds, and KPIs of actual individuals. As that fear of change and sense of nothing but downside shows, people need to build up trust in a new process. External cases and decrees of The Good DevOps News aren't going to help much. The most successful persuasion is building up a string of internal success stories – those skunk works teams that can then be marketed as "look – see – it does work here!"
Staffing those teams is tricky. On the one hand, as Brian Gregory told me back when he was heading up the switch to agile and DevOps at Express Script, you have to choose a team of mavericks who want nothing more than to try new things and take risks. On the other hand, if you create too much of a "10x developer" team, everyone will look at them and think "well, that’s fine for them, but I'm a normal." As a manager at an insurance company told me more recently, "when you get to the end of the pilot, you want co-workers to look at your team and see someone they can relate to."
Get ready to battle your own doubts
Finally, you, who'll be, let's face it, the "change agent", are going to go through some rough patches. You've got to line up some trusted peers and mentors who you can call to pick your sad-sack staff up off the ground when things go poorly. There's going to be more meetings with more smiling jerks than you've ever encountered. Few people will fight for you out of the good of their hearts and many will be looking for the right opportunity to slip a knife into your ideas. There's only so much of that annual bonus pool to go around, after all.
It'll feel like everything and everyone is against you. "You're in that valley of despair," as Opal Perry at Allstate told me earlier this year. Things seem dire, but with plodding success, she added, "then you start to come out". If you plan for the resistance to change, deploy some mind-hacking tricks, and start building up some proof of success from within your own business, well: if that doesn't work, there's always bimodal. ®
Sponsored: Beyond the Data Frontier