In defence of unsackable, obstructive civil servants

The letters page of The Telegraph is full of reactions to Ameer Kotecha's expose on the civil service. One comment that leapt from the page... "occasional interactions with civil servants made me realise that their primary ambition was what they saw as maintaining stability, and what I saw as the preservation of the status quo."

My first thought is... Good. That is indeed part of their remit. If and when change is to be made, a good case should be made for it, it should be properly planned and diligently executed. Many of our woes arise from half-arsed "reforms" which do more harm than good. The civil service is the thin beige line. If civil servants did everything as ministers instructed then nothing would work at all.

As a lapsed software developer, I have a lot of sympathy for civil servants. If some manager comes along and asks me to add a feature I won't simply obey. I have to think about whether the request is technically feasible, whether it's actually needed, what other systems it might interfere with, and whether it will even solve the problem. I need to convince myself that something is a good idea before I start meddling, otherwise I can end up breaking something that works (for which I am held accountable).

From experience, most of the requests I get are from idiot managers who don't understand the system, who think their changes are small, cost-free and inconsequential, when sometimes they might require a major change to the software architecture to do something only they actually want, isn't all that helpful, and by the time I deliver it they've probably forgotten they even asked for it.

As such, I've developed a "fuck off loop" to ensure only serious changes are made, and only when those asking for them fully understand what it is they're proposing. Any *good* civil servant will do exactly the same, especially if you have retards for ministers - which is the system default these days.

One lesson I learned in my unremarkable career as a software developer is that small details, if overlooked, can have fatal consequences. One time I worked for a mid-ranking gas retailer who underwent a rebranding exercise. One of my first tasks as a junior was to update the company logo on the gas bill invoicing system. Relatively straightforward, or so you would think.

With most commercial systems, you make your changes in the test environment, then move them across to the live version. This insulates you from most fuck-ups but it’s no guarantee, as I was about to learn. I changed to logo on the test/development version form template, which all looked fine.

What I was unaware of is that the test version invoice form had an old account number on it, so when the monthly invoice run went out, bills were paid to a dormant account and no money went into the company current account, which is something of a problem when you’re buying gas off the daily spot market.

That morning, there was a major panic in the office. The CEO was called back from his holiday on his yacht in order to mortgage the headquarters so we could buy gas, until the bank rang up to say they’d suddenly had a large influx of money into the previous account. Mystery solved. Bankruptcy averted.

This wasn’t (entirely) my fault. I was new to the company (and only a junior developer) and I’d assumed the development test version was recent (which is the usual practice). In any case, account numbers should not be hard coded on forms. I didn’t even know what I was looking at, and there was no reason I should have. I’d been tasked with what was viewed as a low risk operation and I did exactly as I was told - no more, no less.

The lesson I took from that, or one of them, was never to simply do as instructed, and never assume that something seemingly straightforward is consequence-free. What I also learned from an organisational perspective is that when you have a high rate of staff churn, where all these small lessons are forgotten, the frequency of avoidable fuck-ups is far higher. You need to retain a certain amount of institutional memory that knows what goes where and why. As such, there’s a lot to be said for unsackable developers who know how the system works and will resist changes made on a management whim. The same goes for civil servants.

While this doesn’t meet anybody’s definition of efficiency, the cost of not having that experience is far higher than paying a mid-ranking developer to sit on their arse scrolling through Twitter. I am reassured to know that there are seasoned operators in the civil service who know how to contain the enthusiasm of would-be reformers.