Goals that show success, but don’t define it

I was reading an article the other day about the dangers of making one-sided judgements about risk (tl;dr: always consider risk and reward together) and in the comments underneath someone suggested a perhaps-controversial idea: eliminate the risk function. They were proposing getting rid of those people who specifically “manage” project and enterprise risk. Is that really possible? Is it sensible? Surely we’ll just lose all understanding of the problems we’re likely to face, and end up in all sorts of trouble.

To me, this idea is similar to one that I sometimes propose to software teams, and which often gets a similar response—aim to go from one release a fortnight to several releases per day, I say. Some people like this idea, but often the response is that a single fortnightly release already involves lots of process (packaging, testing, sign-off,…) and doing it several times a day will either involve excessive bureaucracy or throwing all sense quality out of the window. To them, it seems like madness.

In both cases the push-back is due to a misunderstanding. The aim is to be able to achieve this thing without losing the good things that come with it. Getting rid of the risk function is about first ensuring that everyone understands and can manage the potential problems with their decisions, as well the potential rewards. Releasing a system several times a day is first about putting processes in place that eliminate the need for the end-of-fortnight bureacracy. The thing we’re aiming for (no risk function, continuous delivery, etc) is the measure of success elsewhere, not success it in its own right.

In both cases we take a discrete process and make many wider, smaller, changes that render the original process unnecessary. It’s almost true to say we’ve replaced process with culture. And that is surely a very good thing for any organisation.

Photo by Caffeinatrix