- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
How many placebos do you have in your diary?
In 1955, the researcher Henry K. Beecher published a paper called The Powerful Placebo, which described the placebo effect.
This is the phenomenon that, if you have two groups in a medical trial, and you give one group the drug being tested, and the other group a harmless substitute – a placebo – both groups will show improvement. If you want to know the true effect of the drug, you have to subtract the effect of the placebo.
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.
Do you have werewolves in your technology architecture?
What was that eerie, babbling, howling sound? It sounded like a group of people yelling or fighting, but without any words that we could make out.
My wife and I were visiting a wildlife park in the Pyrenees. We were standing in front of the large enclosure that held a pack of wolves. At first, they were hidden amongst the rocks and trees of the mountainside. Then we saw one furry head and a pair of sharp ears, then another, then another. Then the whole pack emerged, about a dozen of them. And they all started howling at once.
But it wasn’t the ‘how-oo-oo-oo’ sound we associate with wolves in films and TV programmes. It was a discordant babble that sounded like overlapping voices. It was strange and disconcerting, even though we knew that we were safe, and could see where the noise was coming from. Later, I learnt that Iberian wolves make this sounds to disorient their prey.
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.
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.