On Risk

Risk is such a ubiquitous word in IT. It sits along side such words as mitigate and workflow. Process and change management. It is one of those concepts that has become so meaningless and hackneyed to be a positive detriment to quality..

What we don’t talk about is fear and courage.

We all know it is good to be fearful. To worry. The concerned sysadmin is the antithesis of the cowboy that makes spur of the moment decisions under pressure. But there is a point – and I would argue that point happens fairly early in a career – where we get stuck in the pseudo engineering just to avoid screwing up.

The thing is that most of us don’t know how to mitigate risk. There are so many unknowns and so many competing priorities that I for one give up and start talking about mitigation and rollback and my clients would nod sagely and look at each other and think they’re doing their due diligence as they collectively silently agreed not to look at my kludged workings.

And without a real measure of risk I’ve tended to make safe decisions. As I can’t honestly choose mathematically between risks I’ve chosen what experience has told me was the low risk position. Thinking I was prudent and grown up and professional and giving my clients what they were paying for.

I was just offered a role as a CIO, and, before making a decision I stopped and sat and introspected for about a month. I was crossing the table. People like me were going to sell me services and products and I was going to have to understand the risks as it was going to be me making the final decision.

So I’ve decided to take the job and to change my decision making process at the same time. I’m calling it Test Driven Decision Making (TDDM).  What I’m going to do is to is to build a series of outcome tests. And then try to measure their success or failure.

And I’ll blog about it as I go.