Every Industry Eventually Becomes an IT Industry

Years ago I watched a telecoms engineer take a phone system apart on a customer’s floor, and it was genuinely lovely to watch. He knew that PBX the way a mechanic knows an engine. He could tell you what each card in the chassis did, what the extension numbering plan meant, which pair on the punch-down block went where, and roughly what year the cabinet had been installed based on the colour of the plastic. He had spent fifteen years getting that good. Somebody had paid for every one of those years, in training courses and in mistakes.

About eighteen months later the customer replaced the whole thing with a server, a licence file and a box of handsets that got their dial tone over the LAN. He was still in the room when it happened. He was still, technically, the telephony engineer. And he was, for the first time in his career, the person in the room who understood the least about the telephone system.

Nobody made him redundant. That is the part people get wrong about this. His job title survived the transition perfectly intact. What did not survive was the definition of doing it well.

Technology does not usually replace a profession. It re-bases the competence underneath it, and leaves the job title standing there looking unchanged.

The PBX engineer is the origin story

Telephony is the cleanest case I know of, which is why I keep coming back to it. If you were a serious voice engineer in the late nineties and early 2000s, your expertise was physical and it was hard-won. ISDN30. Copper. Line cards and extension cards. Programming a PBX through a terminal with a syntax that existed nowhere else on earth and was documented, if you were lucky, in a binder. That knowledge was not trivial and it was not fake. It took years, and the people who had it were properly, defensibly expert.

Then voice became an application. It ran on a server, and later it did not even do that: it became a tenant in somebody else’s SaaS platform, provisioned through a web portal by a person on a helpdesk.

Look at what happened to the skill list. The things that decided whether a voice deployment worked stopped being anything to do with the PBX. They became QoS, because voice packets are small and frequent and hate waiting behind a file copy. Codecs, because someone has to decide what a call is worth in bandwidth. Jitter and latency, because a network that is perfectly fine for email will make a phone call sound like it is being made from inside a washing machine. SIP, because now the call setup is a protocol you read with a packet capture. Firewalls, because a protocol that negotiates media ports on the fly and a firewall that blocks unexpected ports are natural enemies. Network design, because voice is the first application most businesses run that genuinely cares about the quality of the underlying transport rather than just its existence.

Not one of those is a telephony skill. They are all networking skills. Telephony had become a networking problem wearing a telephony hat.

The engineers who came through that transition well were not the ones with the deepest PBX knowledge. Often it was the opposite. Here is the cruel geometry of it: the more expert you were, the more you had to give up in order to admit that the expertise had moved. A junior with two years on the job could shrug and go and learn SIP. Two years is not much to walk away from. Fifteen years is an identity, and you do not casually concede that your identity is now a footnote.

Expertise generates its own resistance to change. It is not stupidity and it is not laziness. It is the entirely rational feeling that you paid a great deal for this knowledge and the market has just moved the exchange rate.

The same story, one industry over

I lived through my own version of this, and I would love to tell you I was gracious about it.

A serious infrastructure career, fifteen or twenty years ago, was built on physical things. SANs. LUNs and how to carve them. Fibre channel zoning, which is a discipline with real teeth and a wonderful capacity to punish the careless. RAID levels, and the argument about RAID 5 versus RAID 10 that every storage person has had at least forty times. VLANs configured on actual switches, in a room, with a console cable, at a time of day nobody enjoys.

Then it became an API call. Then it became a Terraform file, and the storage tier was a dropdown, and the network was a JSON object.

I want to be careful here, because the lazy version of this argument is that all of that old knowledge was wasted, and it plainly was not. Understanding IOPS still matters enormously. The people who genuinely understood storage, who could reason about queue depths and cache and the difference between throughput and latency, tend to be much better at reasoning about cloud storage than people who arrived after the abstraction and have only ever seen the dropdown. When the cloud database is slow, the person who once diagnosed a badly zoned fabric at two in the morning has a shape in their head for what “slow” can mean. That intuition transferred beautifully.

What did not transfer was the mechanics. Nobody is paying for your zoning skills. The day job stopped being configuration and became design and costing, which is a genuinely different activity requiring a different temperament. You are no longer the person who makes the storage work. You are the person who decides what storage to buy, what it costs per month for three years, and what happens when someone leaves a snapshot policy running.

The principles transferred. The specifics evaporated. That distinction is the whole argument of this piece, and I will come back to it.

And now it is happening to electricians

Here is the live one, and the reason I have been thinking about all of this recently.

Solar used to be an electrical trade, straightforwardly. Panels on a roof, an inverter on a wall, mount, wire, terminate, test, certify. The electrical work was the job, the electrical work was the risk, and an excellent installer could do an excellent install without ever reasoning about anything more abstract than “it exports when the sun shines.”

A modern installation is not that. It has networking in it. It has firmware, and firmware bugs, and firmware updates that change behaviour. It has APIs, smart meters, and a hybrid inverter making control decisions several times a second. It has DNO compliance, which means grid codes with names like G98 and G99 and a paperwork trail that has legal weight. It has EV chargers coordinating with batteries. It has home automation, because the customer wants a dashboard. It has export limitation, which is a compliance function that people configure like a preference.

The trade certification kept pace with the electrical work, which is the safety-critical part, and I would never diminish that. It did not keep pace with the system design.

I have written about the solar knowledge gap at length, but the moment that crystallised it for me is worth repeating because it is exactly, precisely, the PBX engineer twenty years later in a different uniform. An electrician was installing my EV charger. Competent, experienced, clean work, genuinely good at the physical job. The commissioning app put a G98 prompt on the screen. He paused, read it twice, and then rang another installer to ask what it was.

The advice came back: “Just press OK, it’ll go away.”

He pressed OK. It went away.

That is not a story about a bad electrician. He was not bad. He was excellent at the job as it was defined when he learned it, and a screen had appeared asking him a question from a discipline that was never part of that definition. Grid connection compliance is not electrical work. It is closer to the paperwork of network design than it is to terminating a cable, and nobody told him that his trade had acquired a compliance-and-networking layer while he was busy being good at the old one.

The telephony engineer stared at a SIP trace and saw noise. The electrician stared at a G98 prompt and saw an obstacle. Same expression on the face. Twenty years apart. Completely different industries.

The part that is happening to you and me right now

Which brings us to the one we are all currently inside, and cannot see clearly for the same reason a fish has opinions about everything except water.

In engineering, the skill of producing a first draft has been commoditised. First draft of a script, a Terraform module, a runbook, a config file. That work used to be a real portion of the job and a real portion of what you were paid for. It is now something I get in twenty seconds, and I use it that way, daily, without any romance about it.

What is left is judgement, and judgement has gone up in value rather than down. Knowing what to ask for, which is a design skill dressed as a prompt. Knowing when the output is wrong, which requires that you could have written it yourself, or at least that you know what wrong looks like. Knowing what to do with it once you have it. The model will produce a plausible backup script with great confidence and no opinion whatsoever about whether your restore has ever been tested. That opinion is the job now.

The same thing is happening in presales, and it is more brutal there because the artefact was more obviously the deliverable. Generating a proposal document is trivial now. It was never the hard part, but it looked like the hard part, and a lot of people had quietly built a career on it looking like the hard part. When document generation collapses to nothing, all the remaining value moves to understanding the customer’s actual problem, which is the one thing the model cannot do for you, because it does not sit in the room. It does not hear the pause before someone answers. It cannot notice that the stated requirement and the real requirement are different, which they usually are. Everything I care about in the discovery call survives this intact, and everything downstream of it got cheaper. I have made the same argument about where technical presales is going. It is the shape of every other example in this piece: the artefact got automated, the understanding got more valuable.

First a bolt-on, then the integration, then the product

If you stack these up, a pattern falls out that I think is close to a law.

Every industry, given enough time, acquires an IT layer. It arrives as a bolt-on: something small and slightly annoying, off to one side of the real work. A computer that prints the certificate, an app that logs the job, a portal you have to update. Nobody good at the core trade feels threatened by it, and at this stage they are right not to.

Then the layer becomes the integration. It stops being a thing beside the work and becomes the thing that connects the work to everything else, and now the interesting failures happen there. The phone system works but the calls sound terrible. The panels generate but the export limit is wrong. A meaningful fraction of the problems on the job are suddenly IT problems, handled by people who are, entirely reasonably, not IT people.

Then the layer becomes the product. The hardware commoditises, the software is where the differentiation lives, and what you are selling is the system rather than the components. At that point the industry has become an IT industry and typically has not noticed, or has noticed and is deeply unhappy about it, which is roughly where the energy trade sits right now.

The bit that stings

Here is the uncomfortable corollary, and I am not going to dress it up.

Years of experience is a depreciating asset if it is experience in the specifics rather than the principles.

“Twenty years of experience” is sometimes one year of experience repeated twenty times, and the market has started to notice. It notices quietly and awfully: the CV that gets no callbacks, the interview where the answers are about products that were current a decade ago, the increasingly defensive certainty that the new thing is a fad. I have watched genuinely brilliant people do this, and it was not their intelligence that failed. Nobody ever told them the exchange rate had moved, and by the time it was obvious, admitting it felt like admitting the whole career had been misfiled.

But I want to be fair here, and fair matters more than clever.

The people who adapt best are not the ones with the least to lose. That is the smug version and it is wrong. Shallow novelty-chasers are not thriving either. They move quickly through things they never understand, and they age badly too, because they never accumulate the intuition that lets you tell a real advance from a rebranded one. The people who genuinely thrive are the ones with deep experience who are also, somehow, still willing to be a beginner. Depth plus humility. It beats stubbornness and it comfortably beats novelty-chasing, and it is rarer than either.

And I am implicating myself, because I have to. Twenty-odd years in IT and a reasonable claim to knowing what I am doing, and earlier this year I sat down to talk to my own solar hardware and had to learn what Modbus is from absolute scratch, like a person who has never seen a protocol before. It was humbling in a way I did not entirely enjoy. It was also the most useful week I had had in months.

What actually carries you across these transitions is not a tool. It is a way of thinking. How to diagnose something you do not understand. How to reason about failure, and about what could fail that has not yet. How to keep asking what the actual problem is instead of accepting the first stated one. How to be sceptical of a vendor claim without being reflexively cynical about it. None of those have a version number. They are the only things I have carried unchanged from a decade of Citrix into cloud into AI into arguing with an inverter about grid codes.

What to actually do about it

I do not want to end on “embrace change”, which is the sort of advice that costs nothing to give and delivers nothing to receive. So, three concrete things, and I mean them as practice rather than encouragement.

Audit your own skills and label each one. Take the things you would put on a CV and mark each as principle-level or vendor-specific. “I understand how storage latency compounds under queue depth” is principle-level and will still be true in fifteen years. “I know the console layout of a product version” is already decaying. You need some of both. The question is your ratio, and whether you have honestly looked at it recently, because most people have not and are quietly surprised by the answer.

Deliberately arrange to be the least knowledgeable person in the room. Not accidentally, which is unpleasant, but on purpose, which is a completely different experience. Go and sit with a discipline you do not have. Take on the project you are underqualified for. This is most of what a home lab is actually for: not the hardware, but the structured opportunity to be incompetent somewhere the failure is cheap. Do it every year or two, especially when you do not feel like it.

Practise saying “I don’t know what that is, explain it to me.” This is the whole thing, really. It is a professional superpower and almost everybody loses it somewhere around the point they get senior enough to feel that not knowing is embarrassing. It is not embarrassing. It is the single cheapest way to acquire information ever devised, and the reason people stop using it has nothing to do with efficiency and everything to do with ego. The electrician who phoned a friend was one honest sentence away from learning what G98 was. He asked the wrong question. He asked how to make the box go away, when the question available to him was what the box was for.

That is the difference. Not talent, not youth, not even effort particularly. Just which question you ask when something appears on the screen that you do not recognise.

Most of us get one of those a week and click past it.