If you’re a bank or other financial organisation and you’re releasing software in production, you’re not supposed to take risks. Forget the fact that our entire financial industry is based on risk, software is supposed to be safe as houses, and not put the business ‘at risk’.

In my mind, there are two problems with this approach:

• Comprehensive risk mitigation is impractical, if not impossible in the majority of real world situations.
• We tend to treat ‘risk’ as binary (black or white), whereas really, it's just shades of grey.

Take the simple decision about methods of travel; this is a very real example of a debate I used to have with my mother about air-travel. You want to go from point A to point B and you decide that you should take a plane. Now, the chances of you being on a plane at the time of a catastrophic failure is less than 1 in 1×10⁹ flight-hours. That's a long time, but unfortunately it does happen on rare occasions. Boeing and Airbus spend more effort reducing the chances of these catastrophically failure events than they do ensuring the landing lights are 99.999% available.

In short, it’s a matter of scale and as I kept telling my mother (with little success), flying is the safest form of travel, statistically.

Risk therefore, is the product of probability and impact: We should be tolerant of minor problems occurring frequently, but very alert to catastrophic failure events.

An aircraft can handle no landing lights on a frequent basis, but falling out of the sky is a one time life limiting catastrophe.

I have been inspired to write this piece after an exchange over the past few weeks with a COO client about the risk function. He used the analogy that sometimes interacting with the risk community was like finding yourself drowning in the Atlantic ocean. As you look up you see a boat. On the boat you see your first and second line of defence risk stewards and they are pointing at you saying “you’re drowning you know, are you aware?”

How many of you have been in the ocean?

I think the problem is with the term itself. We see the word ‘risk’ as inherently bad. If we instead think of risk as ‘the probability of something negative happening versus something positive’, everyone calms down a bit. It should be a trade-off, not an absolute.

Anyway – back to your bank; there is risk in your new service going into Production: It could be hacked, there could be critical bugs, vulnerabilities. Your bank has an entire security organisation dedicated to keeping the bank safe, to ensuring nothing gets into your prod environment that isn’t secure and ‘100% risk-free.’

But as I’ve said above: comprehensive risk mitigation is impractical. Yet this is, in effect, what security has been tasked to deliver: make it secure (not ‘reasonably secure’). This is not their fault necessarily. They are doing what their brief is; I just think the brief is wrong.

As an aside: when challenging (in my view) draconian security obligations, the answer is always ‘You can never be too secure.’ This is rubbish. My house would be considerably more secure if I boarded up all the windows and doors and placed the house within a compound, situated in Cuba, surrounded by US Special Forces: it would also, however, be considerably less useful as a home.

So, if you’re building a new product or service, what’s the real (relative) risk in testing an app with ‘friends and family’ if you can limit the maximum exposure to 10 quid? This – I have argued – doesn’t have to be as secure as a full bank with tens of thousands of customers and millions of pounds in deposits, where a breach could be  financially damaging. In the aircraft analogy, it’s less damaging than the bloke in 27D finding out that you’re out of chicken and “will fish do?”.

Compliance: a place where innovation goes to die

The problem is that most traditional banks are dealing with generations of legacy kit and processes. Departments of compliance and regulation, spun up in part to ensure there’s good practice and the customer and shareholders are protected. Nothing wrong with this per se, but this is a place where innovation goes to die and banks know this. Waterfall and big bang releases are the heroin fix for these types, not the agile, test, fail, repeat anti-patterns of today.

Most try to get around it with ‘innovation departments’ where empowered teams get to experiment, and shape the future. “Think like a fintech!” was the strapline of one leader in a bank 150 years old with 250,000+ employees globally; the trouble is that in most cases, you can only innovate within an ‘innovation bubble’, and this bubble doesn’t include the path to live. Pointless, really.

So , WTF do we do?  Here’s what I’d be saying…

• Build small, low-risk services, and put them in the hands of small groups of real users.
• Get approval from the risk police to launch something ‘real’ with a pragmatic subset of the full ‘locked down’ production-readiness process.
• Get top cover, and involve empowered expert decision-makers (and when I say ‘involve’, I mean charge them with delivering – to prod).
• Aggressively start small in lots of places.
• Build lots of things, make lots of (relatively!) cheap bets. Not all will be successful, but some will.
• Embrace the failures and learn from them. Build them in such a way that, when something works, you can scale it, and have other systems reuse it.
• Put “runs on the board”, to quote an ex-boss of mine (you know who you are Moxey).

Finally, a very good friend of mine who sadly is no more once said to me that his risk department should be like the brakes on a Formula 1 car. They are there to make sure you go around the track in the fastest time to win the race, not there to make sure you never get out of the pits ’cause it’s scary out there!

Give it a go, and if you need some help, get in touch.