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
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
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
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
How can organizations embarking on DevOps protect against the adverse effects of loss aversion? How can they ensure staff
- 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,
codewon’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 takingand 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
andcross-functional improvement strategies.
It’s too easy to put problems down to a change-resistant culture, but it mustn’t be
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