I have recently been observing a phenomenon I can only describe as the industrialisation of doing absolutely fuck all.
Not ordinary laziness. We’ve all had a Friday afternoon when the prospect of opening another spreadsheet makes us want to climb into the stationery cupboard and die.
No, this is something far more sophisticated. This is twenty people, all working very hard, all attending meetings, all producing documents, and somehow collectively achieving less than one bloke with a screwdriver.
The easiest way to explain it is with a light bulb. Not a clever one. No Bluetooth. No subscription required to access the illumination functionality. The sort of thing you buy in Tesco.
1. Dave
A large organisation discovers that a light bulb has gone out and engages an electrician. Let’s call him Dave.
Dave arrives on Monday morning. He replaces the bulb, checks the wiring and tests the switch. The light comes on. He turns it off. He turns it on again. Beautiful.
You might imagine that would be the end of the story. You would be spectacularly wrong.
Dave has confused the successful installation of a working light bulb with the successful delivery of the Light Bulb Programme. These are entirely different things.
The Light Bulb Programme has a Programme Board, a Lighting Design Authority, a Risk and Assurance Function, and a gentleman called Martin, the Programme Assurance and Stakeholder Alignment Lead.
Martin’s first job was replacing batteries in emergency torches. He once spent three days investigating a faulty torch before somebody noticed he had put the batteries in backwards. He was promoted to Torch Maintenance Coordinator, where he could supervise battery replacement without going anywhere near a battery.
Twenty years later, Martin is an authority on the governance of illumination.
Martin has concerns.
Martin has not personally produced any light since 2004.
2. The Lighting Design Authority
The Design Authority asks for an architectural diagram. Dave produces one. There are arrows. Everybody likes arrows.
It is circulated to seventeen people, including three on annual leave and one who left the organisation in 2022.
“Dave, could you just talk us through the architecture?”
“Electricity comes in here, passes through the switch and powers the bulb.”
“And the bulb itself?”
“Produces light.”
“Fantastic. Could we capture that in a separate document?”
At the next meeting, Martin asks whether anybody has confirmed that the bulb is compatible with the switch.
“I’ve turned it on and off several times, Martin.”
“Yes, but I think we need to be careful about confusing successful testing with formal confirmation of compatibility.”
The programme manager nods. “That’s a really important distinction.”
Dave briefly considers eating the test report. Instead, he agrees to add a sentence.
Without Martin, the electrician might have walked away under the entirely mistaken impression that turning a light bulb on and off constituted evidence that it could be turned on and off.
3. The forty-document handover
Over the following weeks, Dave produces an Architecture Definition Document, an Interface Definition Document, a Functional Specification, an Operational Support Manual, a Troubleshooting Guide, a document explaining the relationship between the switch and the bulb, another explaining the relationship between the bulb and the room, and a rollback procedure, which consists of turning the switch off.
Forty documents in total.
Martin suggests a simple orientation document explaining what each component does.
“For example, this component called Light Bulb. What does that actually do?”
“It produces light, Martin.”
Dave briefly considers whether prison would really be that bad. Instead, he writes document forty-one:
Light Bulb: The component responsible for producing light.
Light Switch: The component responsible for switching the light on and off.
It reads like GhostDoc, that old Visual Studio extension that generated comments with all the intellectual sophistication of a damp flannel. A property called UserName? The user name. Marvellous.
The document is accepted. The organisation now has a comprehensive understanding of the light bulb.
Unfortunately, the office is still dark.
The Design Authority then asks why the documentation says “light bulb” when the approved terminology is “Illumination Delivery Component”.
Dave changes the heading. Document forty-two.
This is, and I really cannot emphasise this enough, a fucking light bulb.
4. This is enterprise lighting, Dave
Eventually, Dave says it out loud.
“Look, it’s a fucking light bulb. Can we please just turn the bloody thing on?”
The room goes quiet.
“Dave, I appreciate you may be used to smaller domestic installations, but this is a large professional enterprise. We have processes, stakeholders and security requirements. It’s a rather different level of complexity.”
Martin nods. “Enterprise lighting operates at a completely different level.”
Now, before this engagement, Dave had been lead electrical engineer on some of the largest commercial buildings in Britain. Skyscrapers. Hospitals. Substations, backup generators, thousands of circuits. On those projects, fitting a single bulb was a task for the most junior apprentice, possibly as a reward for identifying which end of the screwdriver to hold.
He had not expected to be lectured on enterprise electrical engineering by a man whose principal technical achievement was connecting his laptop to the projector, with assurance provided by a man once defeated by a torch.
Dave considers explaining this. Then he looks at Martin, who is making a note about stakeholder alignment, and decides life is too short.
“Fair enough. You tell me how you’d like it installed.”
“Excellent. That’s exactly the collaborative approach we need.”
5. The Great Switch Access Crisis
The programme enters its operational handover phase. Dave’s key to the electrical cupboard is confiscated. He is no longer permitted to touch the switch.
A week later he is invited to Light Bulb Production Readiness: Critical Path and Outstanding Delivery Actions.
“Dave, we’re a bit worried. The light hasn’t been turned on in production.”
“Correct.”
“What’s preventing that?”
“You took my key away.”
“Yes, but that was part of the agreed handover process.”
“Then ask your electrician to turn it on.”
“But can you confirm it will work?”
“I tested it in development and test. I haven’t been allowed into production.”
“Could you do that today?”
“No.”
“Why not?”
“Because. You. Took. My. Fucking. Key.”
The programme manager writes something in his notebook. “Right. So we’ll capture that as an outstanding action for Dave.”
Dave points out that the organisation now owns the installation, the cupboard, the switch, the keys and the electrician.
“Absolutely. But you’re still our subject matter expert. We’d really appreciate it if you could take ownership of getting this over the line.”
Dave asks whether that means he can have his key back. It does not.
Martin intervenes. “Perhaps it would help to separate the question of who has access to the switch from the question of who is responsible for ensuring the switch gets switched.”
Martin is delighted. He has identified two distinct workstreams.
6. Scope, security and the observation framework
To reduce risk, the organisation decides to deploy a single bulb. The rest of the building will stay dark while it considers the security implications of illuminating multiple rooms.
Somebody asks who is responsible for observing the room once the switch is flicked, and whether that person is authorised to confirm that illumination has occurred.
Martin raises a further concern. The room is currently lit by daylight. How will they distinguish successful illumination from a false positive?
The meeting agrees the bulb must be tested after sunset. Unfortunately, Electrical Operations does not provide out-of-hours support.
Then somebody asks whether the bulb has been penetration tested. Could light visible through the window constitute an information disclosure vulnerability?
The security team requires a representative production environment. The light cannot be turned on until the penetration test is complete. The penetration test cannot begin until the light is on.
The meeting concludes that there is a dependency. Everybody nods solemnly. It is added to the risk register.
Dave’s contract is extended for another month.
7. The electrician builds something else
Dave is no longer upset by any of this.
He is paid his full rate to attend meetings about a bulb he finished installing months ago. He has no access and no authority, and most questions can be answered by pointing at one of forty-two documents.
This leaves him with rather a lot of spare time.
So he builds an automated electrical installation system. Robotics, machine vision, software that designs a circuit, installs it, tests it, finds its own defects and fixes them. Before long it can wire an entire house without him.
Martin, meanwhile, is having an excellent year. He has identified seventeen documentation gaps, chaired eleven stakeholder meetings and escalated three critical dependencies. His performance review describes him as instrumental in driving the programme towards production readiness.
Not a single photon has emerged from the production bulb.
Martin is promoted to Head of Illumination Strategy.
Nobody asks whether he knows how to change a light bulb. That would be rather beneath him.
8. Governance is not delivery
I am not suggesting governance is pointless. The more serious the consequences of failure, the more important it is to establish that a system is safe.
But there is a difference between governance that reduces risk and governance that makes people feel less anxious. One produces evidence. The other produces meetings.
Some organisations have become extremely good at observing delivery without participating in it. They can produce a beautifully colour-coded spreadsheet showing the Light Bulb Programme is 94% complete. Ask what is physically stopping the light coming on, and they have no idea.
The incentives are the interesting part. The electrician’s measure of success is simple: does the fucking thing work? His job ends when it does.
Martin’s job can continue indefinitely, provided there is always something else to discuss before somebody turns it on. Every delay produces a dependency. Every dependency produces a meeting. Every meeting produces an action. Every action proves Martin is indispensable.
It is a magnificent little perpetual-motion machine. Unfortunately, it runs entirely on other people’s productivity.
It would be a terrible shame to discover that the only person in the organisation who understands the light bulb is the one person they have forbidden from touching it.
Although it would explain the spreadsheet.
9. How many electricians does it take?
Dave attends what he has been assured is the final production readiness meeting.
“We’ve made tremendous progress. Documentation, handover, ownership model. I think we’re almost ready.”
Dave looks at the light bulb. It is off.
He checks his phone. His system has just finished another project. Three houses wired. Two defects found and corrected. No human intervention.
“Dave, are you comfortable the light bulb is ready?”
“Yes.”
“So when will it be turned on?”
“When your electrician turns on the switch.”
“Is there anything you need from us?”
“Not a thing.”
“Fantastic. We’ll capture that as an action for Dave.”
Martin raises his hand.
“Sorry, just one final point. Could we get a simple diagram showing which direction the switch needs to move?”
Dave looks at Martin. Martin looks at Dave. The programme manager looks delighted.
“Really good point, Martin. Let’s get that documented.”
The meeting closes. Everybody thanks everybody else for their time.
Dave’s contract is extended for another month. He opens his calendar.
Light Bulb Production Readiness: Weekly Progress Meeting. Recurring. No end date.
He accepts. After all, the light bulb isn’t going to turn itself on.
Although, funnily enough, the one Dave has just designed probably will.