Why Winning With DevOps Means Cutting Your Losses

Every DevOps collective should really be worried about losing business, customers and opportunity.

Imagine the scene in a glitzy Vegas casino. People are gambling: some are winning; and some are losing. How do they feel if they’ve won or lost a hundred bucks on the spin of a roulette wheel? Interestingly, psychological studies have shown that losses are twice as emotionally powerful as gains—people hate losing more than they love winning.

It’s these insights into behaviors and cognitive bias that helps casinos profit. It’s also something that can influence any change related initiative in business technology—including DevOps.

In business technology, professionals working in software development are under the pump to release a new application update. Deep down they know there might be the odd performance or quality issue, but the thought of holding back the deployment is unpalatable. So like a casino gambler they take a risk; rolling the ‘release and be damned’ dice to avoid a sure loss. Hopefully that nagging feeling doesn’t turn out to be a serious flaw that’ll compromise the business. But what’s the chance of that, when just like in Vegas the odds are always stacked against you?

Would DevOps with its focus on closer collaboration with development to prevent production problems hold much weight if it compromises regular and expected cash—the kind of green that’s been paying a mortgage or putting the kids through college?

— Peter Waterhouse, Senior Strategist, CA Technologies

Many IT Pros Fear Loss More Than Change

The problems associated with loss aversion aren’t only limited to software development. They also include IT operations and service management. Here teams may have spent untold hours customizing the life out of change management functions and developing elaborate review boards. Rigid perhaps, but difficult to give up when maintaining and supporting them is what’s shaped a career and guaranteed job security.

While some might be troubled with change, the fear of loss is often much stronger. Take a systems administrator for example, who for years has been well compensated (financially) for after hours and on-call support. Would DevOps with its focus on closer collaboration with development to prevent production problems hold much weight if it compromises regular and expected cash—the kind of green that’s been paying a mortgage or putting the kids through college?

It’s Hard to Let Go—Even the Crappy Stuff

Loss aversion can be influenced by other tech behavioral nuances, especially the IKEA effect. Named after the Swedish ‘assemble-it-yourself’ furniture powerhouse, this basically describes a condition in which people place more value on things they build themselves. This is great in development where professionals should be taking pride in their software, but can be damaging if they become so overprotective of their creations that they push back on improving them when necessary. It’s like keeping an old IKEA cabinet with the wonky leg. It should have been replaced years ago, but its owner is too emotionally invested to let it go.

This phenomenon doesn’t only occur within the domain of development. In operations, IT pros slavishly protect tools and methods to support specialization in discrete areas; taking pride in complex, over-engineered process self-assembly to the detriment of much needed change.

How can organizations embarking on DevOps protect against the adverse effects of loss aversion? How can they ensure staff aren’t taking unnecessary risks because they fear the consequences?

  • Take the gambling out of development. Traditionally QA and testing teams are relied on by development to find bugs and defects. Now, however, adopting techniques like test-driven development means that when tests don’t complete, code won’t be delivered and coders have immediate feedback into software quality. Add to this newer tools like service virtualization to remove testing constraints, and that means quality can be established much earlier in the software lifecycle with no unnecessary risk taking and inevitable technical debt.
  • Rediscover the art of craftsmanship. In an age of agile style development, many older processes designed and built to ensure compliance and resilience may now act as innovation circuit breakers. To address this, many development teams take on a “shadow ops” function, adopting new tools to bypass IT operations. Rather than resist, teams should be encouraged to apply their expertise in areas beyond the confines of the organizational structure. This enables critical but often neglected elements like application supportability and a high-quality customer experience to be “crafted” during design and development.
  • Incentivize according to business outcomes. It’s going to be a tough ask for support staff to relinquish financial rewards, so care should be taken. But rather than compensating staff on ‘outputs’ (for example, lines of code, number of problems fixed), consider systematically introducing a series of metrics whereby staff can be measured and incentivized according to how their activities improve business outcomes. Ideally, these should be applicable to all groups so as to encourage knowledge sharing, feedback and cross-functional improvement strategies.

It’s too easy to put problems down to a change-resistant culture, but it mustn’t be forgetten that culture is shaped by behaviors. With any change, it’s natural for people to fear losing many things, including relevance, skills, career and money—fiercely pushing back when these are threatened. So as much as DevOps and tooling is about building high performance and resiliency into our software applications, it’s also about establishing these qualities into the people that build and nurture them.

Then and only then can organizations start channeling these very human conditions into addressing what every DevOps collective should really be worried about losing—business, customers and opportunity.

Peter Waterhouse
By Peter Waterhouse | June 14, 2016