Do your approvals processes make it easier to do nothing than to do something?

Photo credit: Marcus Reubenstein via Unsplash

Have you ever seen a project plan which is a victim of the approvals process?

You can usually tell when a plan has suffered in this way. There may be long gaps when nothing is happening, followed by frantic activity around a monthly or quarterly date. Or there may be design and planning work which is crammed into the plan far too early, in order to hit an approvals board. There may even be a whole part of the plan – and the team – dedicated to gathering data and writing requests for approval.

Technology people seem to hate approvals and love them at the same time. Nobody enjoys navigating their way through complicated and arcane processes where every signpost says, ‘Not this way,’ or ‘Try again.’ And yet we don’t seem to be able to stop ourselves from creating more processes: approvals to purchase, approvals to hire, approvals to release, approvals to change, and approvals to change the approvals process. I've certainly been guilty of implementing processes which seemed like a good idea at the time, but less so in practice.

There are lots of things wrong with most approvals processes: they are slow; they are complicated; they rely on humans making choices with minimal context; and they depend far more on hierarchy and positional authority than on experience and expertise.

But I want to focus on one aspect of approvals which is particularly relevant to the management of technology: they make it easier to do nothing than to do something, and the health of technology systems relies on us continuously doing something.

This is rarely the intent (most of the problems with approvals processes are unintended). Indeed, processes intended to ensure that only good changes make it through to production are usually full of lists of things that you should have done. Have you organised a penetration test? Have you rehearsed your failover arrangements? Have you stressed the system at high volumes? (Or, have you found the loophole in the process which lets you skip all these steps with sufficiently senior authorisation?)

However, the side-effect of all of these steps is that they make every change hard. It is not unusual, even in organisations which claim to have embraced the discipline of DevOps, to find a parade of changes stuck in limbo, circling backwards and forwards, gathering the evidence and exceptions that will finally release them from approvals purgatory.

Given this friction – and the implicit signal from the organisation that change is dangerous and something to be feared – it is rational to try to make fewer changes. There are two ways of doing this, both of which are bad. First, we can bundle changes together and release them in one go – increasing our chances of failure and decreasing the chance of telling which change caused a problem. Second, we can simply skip changes which don’t seem urgent. When it’s so hard to get basic feature releases done, do we really have energy to spare for patching, refactoring and other code quality improvements? Of course, every time we fail to make these changes, we deepen our technical debt – but that’s not something that most approvals processes care about.

Software is better when it is changed frequently: it keeps it current, helps the team get good at change, supports continuous improvement, and encourages good code quality. Approvals processes which discourage change don’t just get in the way: they actively degrade the quality of our systems.

This is a hard problem to solve: nobody meant for it to be this way. Perhaps part of the solution is to treat our approval processes as we would like to treat our code. If we regard such processes as part of the operating system of our organisation, then we are prompted to ask important questions. Are these processes valuable? Are they efficient? Are they unobtrusive? Do we know what outcomes they are intended to deliver? Are they successful in delivering those outcomes? What steps can be automated? What steps are best left to the professional judgement of experts?

If, just as we should with our systems, we can establish a fast feedback loop and a fast feedback cycle, then we may stand a chance of making our approvals processes fit for the development of software. Perhaps, rather than having project plans which are distorted by the demands of our approvals processes, we can have processes which reflect the practices of developing good software.