After the modest success of my last DevOps Story Time post on getting out of your own way, I feel like it’s time for another. This time, on the value of taking risks, and taking away a win even when you realize one of the risks you were afraid of.
Easter weekend 2018, for my 30th birthday, my girlfriend and I went to Banff, AB to do some hiking. When we got there, she surprised me with my “real” gift: that we were going to go visit a wolf sanctuary in Golden, BC, and go on a hike with some real, actual, not-fooling-around wolves. Obviously, I was beyond excited.
When you get there, before you go on your walking with wolves adventure, you sign some waivers which include some items about releasing rights to photos, but also include some very specific, lengthy sections to the tune of “These are wild wolves. Although they’ve been imprinted on humans (aren’t afraid of humans like a normal wolf, this is why they’re in the sanctuary), these aren’t like visiting your friend’s Labradoodle. These are wolves, and wolves can be dangerous and unpredictable.”
Now, you’re out there with (excellent, knowledgeable, informative) guides, and this part of the sanctuary is definitely a tourist attraction, so there’s a pretty good feeling of safety that sets in quickly. We understood, and of course, accepted the risks that we’d been made aware of, and embarked on our walk.
For the most part, you and your small group walk through an area the guides are familiar with as the wolves do wolf things and dart around. They weave through the group plenty, you can pet them if they come up to you, and play and pose while people take pictures. At a certain point, the guides will find a good spot to take pictures of the guests in close proximity with a wolf. You don’t have to do it if you’re scared, but by this point, we felt really comfortable and were definitely not going to pass up a once in a lifetime opportunity to take a picture with a real, live wolf.
This was absolutely one of the coolest moments I’ve ever experienced, and a completely unforgettable memory. However, remembering that wolves can be a little unpredictable sometimes, she got a bit excited climbing all over me, and I came away with a pretty good scratch.
This is why you sign a waiver. And the scratch wasn’t really so bad. I cleaned it out, and took care of it, and will heal up just fine. This pic was taken when we got back to our car immediately after the hike. Pardon the toque hair.
What does this have to do with IT?
Believe it or not, there’s a DevOps related lesson to be learned here, and I’m not just bragging about my cool birthday experience, and subsequent Bond-villain-esque facial wound (maybe just a little).
I normally consider myself a pretty risk adverse person. If you saw my stock portfolio, you’d probably agree. When it comes to your IT department, most traditional enterprises consider themselves “risk adverse”, too. The thing is, though, people too often throw around the term “risk adverse” as a reason not to take a risk. Being adverse to risk isn’t a blanket excuse to never take any risks ever for any reason. By definition, it just implies a certain amount of (hopefully healthy) skepticism to avoid undue risks.
Don’t let anyone immediately dismiss an idea, whether its disruptive or not, simply on the grounds of being risk adverse. Every risk has an impact and likelihood (how severe it is, and how likely it is to actually happen), and if someone wants to dismiss an idea based on risk, it should be based on the impact and likelihood being too high.
Urge your stakeholders to identify a risk tolerance. They’ll give you a non-zero number. Make it out of 25. “On a scale of 0 – 25, what would you say our appetite for risk is?” Say they come back with 10. That’s somewhat risk adverse, right? Well, using the risk impact/likelihood model, give both the possible impact and likelihood a score out of 5. Multiply the two numbers to get a score out of 25, and compare that to your stakeholder’s risk tolerance. If a certain change comes with a risk that carries an impact of 2 out of 5 (if the change fails, users will experience a partial outage for 4 hours – but the company’s reputation will remain intact, no business will be lost, it’s really just an inconvenience) and a likelihood of 2 out of 5 (pretty unlikely, but possible), the risk score is 4/25. This is well below the identified risk tolerance level of 10, and this is leverage for you to go ahead with your change.
The scores are obviously subjective. A partial four hour outage for users may be a catastrophe if you’re an internet service or cellular provider, instead of an inconvenience in our scenario. It’s up to you to add reasoning to your scores so that your risk evaluation is more meaningful and valuable. Include mitigation plans that describe how you plan to lower the likelihood of a risk being realized and the impact if it is. Be sure, at some point to underscore the benefit of taking the risk. Actions can still be beneficial even if a risk is realized.
I strongly urge you to use this model and line of reasoning to combat the “well we are pretty risk adverse so it’s going to be a no” blanket excuse. Rather than letting people’s comfort zone drive your IT strategy, force a more thoughtful, well-reasoned decision. You might still get a “no”, but at least it will be one that’s thought out, rather than impulsive.
Bringing it together
Like I mentioned, I am pretty risk adverse, but I also don’t want to live a life without any fun and interesting experiences. I used the information that was available to me to enumerate the different risks of going out on a hike with wolves, the impact (mild disfigurement) and likelihood of those risks being realized (pretty low), including the mitigating factors of the guides, and weighed that all against my appetite for risk and the benefits of accepting the risk and doing it anyway.
Even though one of the risks was realized (my face is a little less pretty until this scratch heals up), the reward and benefit of the decision was still absolutely enjoyed. I had an amazing, once in a lifetime experience that will always be special to me. You can do the same in your own career, and at work. The road to success isn’t always well-paved.