#BlogElul Day 20: Dare
I’ve never been at a company that openly said “We’re risk averse here. We would prefer you don’t try anything new. No innovation unless you absolutely can’t avoid it.” No, most of the time the message is “We’re a company of risk takers! Dream big, dare to try new things!”.
But in the IT world, being “daring” is a double-edged sword.
On the one hand, taking a risk can result in a huge payoff – savings to the company, improvements to services, or a true competetive edge in business.
But it can also be the ultimate career-limiting (or ending) choice. I have seen more than one person escorted to the door because their “daring behavior” violated security, change control, or some other corporate policy which was considered inviolable.
But even with that risk, IT professionals are a daring bunch. Most of us got into this type of work because we had a vision of how things could be better.
So I wanted to share a story that I heard recently during my discussion with SolarWinds CTO Joel Dolissy on ways that IT professionals can do a better job of “selling” their request for new software, hardware, and projects (you can see my discussion here).
Near the end of our talk, Joel and I were discussing ways we can respond to having our request turned down. Joel proposed going out and doing a small prototype anyway. In fact, ASKING to be allowed to do a proof of concept, as a response to being told “no”.
Pretty daring stuff.
But Joel doubled-down and told me about a particular engineer at Amazon. It seems this guy had an idea for recommending products based on what was in the user’s shopping cart at that moment. Leadership heard the proposal but was concerned that having such recommendations would distract a buyer for completing their purchase, and so they refused.
The engineer would not be deterred, and implemented the code on just a couple of Amazon’s massive farm of servers. Then he collected the data on how buying behavior changed. Faced with the overwhelming evidence that “Recommended Purchases” drove sales higher, leadership revised their thinking and agreed to develop the code fully and implement it system-wide.
Nothing ventured, nothing gained.
