The Standard That Ate the Story

Thinking Out Loud · Nick Appleby

Somewhere in the last forty years, a good chunk of British industry quietly decided that the people who actually knew how things worked were a liability.

Nobody signed that off in a meeting. It arrived wrapped in something entirely reasonable: BS5750 in 1979, which became ISO 9001 a decade later, and with it a pitch no boardroom was ever going to argue against. Write down how you do things, so quality doesn’t depend on which bloke happens to be on shift. Consistency. Repeatability. A certificate at the end.

Forty-odd years on, I think we can see the bill. We didn’t just standardise process. We slowly stopped training people – and we started treating the ones who still knew things as a compliance risk.

How the knowledge actually used to move

Twenty-five years ago, if you wanted to understand why a particular install kept failing, you followed an engineer around for six months who’d seen it before. Nobody wrote “if the earth bond reads high on a rooftop installation, check for galvanic corrosion at the bracket before you touch the electronics” in a manual, because it didn’t need to be written down. It lived in the person, and it got passed on by watching, asking, and getting told off for skipping a step that mattered.

That’s expensive. It ties up two people’s time for months, it doesn’t scale, and it definitely doesn’t produce a certificate you can wave at an auditor. So it got replaced, gradually and with the best of intentions, by a module. An e-learning course. A competency framework with a tick at the bottom. Someone can now be “signed off” as competent on a piece of kit having never once stood next to someone who’s actually broken one and fixed it.

I’ve watched this happen specifically in cellular router support. New starters come in, do the online induction, pass the internal certification quiz on APN configuration and firmware upgrade procedure, and are on live tickets within weeks. They can follow the flowchart perfectly. What they can’t do – because nobody had the time or the mandate to teach them – is recognise the fifteen-minute pattern that tells an old hand the fault isn’t the router at all, it’s the SIM profile the MVNO pushed out at 2am. That recognition used to come from years on the bench. Now it doesn’t come at all, because the job got redesigned around not needing it.

When experience gets overruled by the process

The part that actually irritates me isn’t that we stopped training people properly. It’s that when someone who does still have the knowledge tries to use it, they increasingly get shut down for it.

I’ve sat in enough support escalations to have seen the pattern first-hand: an engineer with real depth flags that the documented troubleshooting sequence is wrong for a specific fault class – it wastes forty minutes on steps that will never fix this particular problem – and gets told the sequence has been through change control and can’t be deviated from without a variance request. By the time the paperwork to justify skipping step four of nine is approved, the customer’s been on hold twice and the “efficient, auditable” process has taken three times longer than the engineer’s instinct would have.

Now, anyone who’s actually run a quality system will tell me – correctly – that ISO 9001 has the machinery for exactly this. Nonconformance reports. Corrective action. Continual improvement. On paper, the standard wants the engineer to raise their hand and say step four is wrong, and it wants that feedback to flow back and change the documented process. On paper, I’m describing a badly run system, not the standard itself.

I’d genuinely like to believe that. But I’ve watched how the machinery gets implemented, everywhere it lands, and it is almost never the fast loop that rewards the engineer for being right. It’s a variance-request form. It’s a change-control queue measured in weeks. It’s a process that is entirely auditable and reliably slower than the fault it was meant to fix. The intent and the outcome have come apart so consistently, across so many desks and contracts, that at some point you stop calling it bad luck and start calling it the actual behaviour of the thing.

And to be fair, the standard didn’t manage all this on its own. Offshoring, headcount cuts and the general squeeze on support margins were pulling in the same direction the whole time. But ISO gave the trend a language and a justification. It let an organisation call the de-skilling “process maturity” and put a certificate on it.

The trap closes on itself

Here’s the bit that should worry anyone running a technical business. Once you’ve optimised for tick-box compliance long enough, you lose the ability to tell the difference between someone who’s good and someone who’s merely good at following the process. Both score identically on the metrics that matter to the business. So when you’re hiring, promoting, or deciding who trains the next generation, you’ve got no reliable signal left for actual competence – and the people who might have been that signal have either left in frustration or learned to keep their mouths shut and tick the box like everyone else.

That’s the real cost. Not the paperwork itself – paperwork’s fine, records matter, and losing knowledge when someone retires is a genuine problem worth solving. The cost is a generation of engineers who are certified, auditable and compliant, and who have never been allowed to develop the judgement that made the original process worth writing down in the first place.

Where I land

Write things down. Absolutely. But if the only way anyone learns the job now is a module and a multiple-choice test, and the people who learned it the old way get overruled every time their instinct conflicts with the flowchart, you’re not preserving expertise. You’re replacing it with the appearance of expertise, and hoping nobody needs the real thing before it’s gone entirely.

If you’ve had your own “the process says X, I know it’s Y” moment – on a support desk, an install, anywhere – I’d genuinely like to hear it. Drop me a line.