David Knott 27/08/2025 David Knott 27/08/2025

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

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.

David Knott 05/09/2024 David Knott 05/09/2024

Are you under attack from your corporate immune system?

It was supposed to protect us.

One of the most disconcerting aspects of the recent Crowdstrike incident was that the process which caused the disruption - a rapidly deployed update to a piece of endpoint protection software - was meant to prevent disruption. Rapid deployment was intended to help us respond quickly to new threats against which we would otherwise be defenceless. Low level access to the operating system was intended to enable us to detect and deal with anomalous behaviours and subtle modes of attack. Tools such as Crowdstrike are supposed to be vital parts of our immunity against deliberate attacks and accidental failure: they are not supposed to turn on us.

It might seem that incidents such as the Crowdstrike update failure are, mercifully, rare. Most of the time, we rely on our corporate immune system to help us, not to harm us.

David Knott 17/02/2022 David Knott 17/02/2022

Three steps through the thicket

Last week, I wrote about those horrible processes which still exist in most technology functions in most large enterprises - the release process, the production acceptance process, the onboarding process and so on. The process that everybody dreads, no-one seems to be accountable for, which we don’t seem to be able to change, and which stands between us and our code running in production. I suggested that the way to tackle such processes is not simply to optimise and streamline them: such ‘process gardening’ is a never ending battle against a thicket of thorns that grows back every day. Rather, it is to shift from a focus on process to a focus on trust and accountability.

I realise that’s a difficult thing to do. If everyone is telling you that the process stands between the company and catastrophe, then it takes a lot of courage to step away from it. It’s also rarely wise to abandon all of your process: you just want to get rid of those parts that add friction but not value. However, based on my own mistakes and the successes of others, I can offer three suggestions to get started.

David Knott 10/02/2022 David Knott 10/02/2022

Trust and accountability can guide us out of the process maze

If you want to know the history of a company’s IT failures, take a look at their release management process. If they’ve got more than one process, look at the gnarliest, longest, most frustrating process you can find. Typically, you’ll find a set of checks, inspections and approvals that comprise an archaeology of previous mistakes and failures. Twenty years ago several systems ran out of capacity shortly after launch, so a capacity plan is now an essential part of the process. Ten years ago, there was an audit finding questioning the validity of DR planning, so a complete DR plan is required for every release. Five years ago, there was a licensing compliance breach, so evidencing license coverage is now mandatory.

Taken individually, these steps all seem rational. Of course we want to be sure that there is enough capacity to run the system. Of course we want to know that our DR plans work. Of course we want to be compliant with our licensing agreements. But collectively, these steps turn into a complex maze, where it seems that every release must atone for the errors of the past.