The craft in the unglamorous work
Healthcare equipment service is not considered a skilled trade in the way surgery is, or engineering. This essay argues it should be — and that the way we build software for it either honours that craft or quietly erodes it.
Nº 10
9 min read
Before the morning's first scan.
Nobody writes long profiles about the technician who kept the MRI running.
The surgeon who used it, perhaps. The researcher whose findings depended on it, occasionally. The administrator who secured the funding for it, in the right kind of publication. But the person who drove forty minutes in the dark to get there before the morning's first scan, who diagnosed the fault from a sound they recognised from a machine they'd worked on six years ago at a different hospital, who had the replacement part in the back of the van because they'd been watching this model long enough to know what it tends to fail at and when — that person does not get the profile.
This is not a complaint. It is an observation about which kinds of work our culture has decided to call skilled, and which it has decided to call something else, and what that distinction costs.
The invisibility of maintenance
There is a theory in infrastructure studies — articulated most clearly by the scholar Andrew Russell and the historian Lee Vinsel — that modern societies are systematically better at celebrating the creation of things than the maintenance of them. We name buildings after the architects, not the people who keep them standing. We write histories of invention, not histories of repair. We fund innovation and tolerate maintenance, usually until the moment something breaks and we are reminded, abruptly, of the difference between a world where things work and a world where they don't.
Healthcare equipment service sits squarely in this blind spot. It is maintenance work, and it is invisible in the way maintenance work almost always is — which is to say, it is invisible precisely when it is being done well. A hospital whose imaging fleet runs without incident generates no story. The scan happens. The image renders. The diagnosis is made. The technician who made all of that possible is, by the standards of how we usually measure contribution, nowhere in the picture.
The measurement system is not wrong, exactly. It is just oriented toward a different kind of value than the kind being created.
What skill looks like when nobody is watching
The craft in this work is real, and it is specific, and it is earned over years in a way that resists shortcutting.
It is the ability to read a machine's behaviour the way a good doctor reads a patient — not just the presenting symptom but the pattern underneath it, the history that contextualises it, the differential between what it looks like and what it is. A technician who has serviced two hundred CT scanners carries a diagnostic model that cannot be downloaded or trained in a classroom. It is built from the accumulation of specific encounters, specific failures, specific moments when the expected thing didn't happen and something had to be figured out from first principles under time pressure.
It is the knowledge of which hospitals prefer morning service windows and which are actually fine with afternoons regardless of what the contract says. Which site coordinators will tell you immediately if something's wrong and which will wait until it becomes a crisis. Which models fail predictably at a particular component after a particular number of hours and can be managed proactively, and which fail randomly and just have to be watched.
None of this is written down anywhere. It is carried by people, transferred imperfectly through proximity and time, and lost — partially, irrecoverably — every time someone leaves.
The economic argument nobody makes
There is an economic argument for taking this work seriously that the healthcare industry has been slow to make.
Unplanned equipment downtime in a hospital imaging department is not an inconvenience. It is a measurable clinical and financial event. Delayed scans mean delayed diagnoses. Rescheduled patients mean absorbed costs and diminished throughput. An MRI that is down for an unplanned day in a busy urban hospital represents a loss that runs, depending on the institution, into tens of thousands. The technician whose pattern recognition caught a developing fault three weeks before it would have caused that failure prevented something with a real value — a value that shows up nowhere in how we talk about or compensate the work.
The field as a whole has not developed the vocabulary or the measurement infrastructure to make this argument clearly. The value of prevention is structurally harder to see than the cost of failure — not because it is smaller, but because it leaves no trace. The scan that happened because the machine was ready is indistinguishable, to anyone not looking specifically, from the scan that happened because nothing went wrong.
This is, again, the maintenance problem. The better you are at it, the less evidence you leave of having been necessary.
What software has done to the work, for better and worse
The digitisation of healthcare equipment service has changed the nature of the craft in ways that deserve more attention than they have received.
The better version of this change: information that used to live only in experienced heads now has somewhere else to live. Service history, fault patterns, parts life cycles, contract terms — when these are captured in a system and made accessible, they extend the effective expertise of the team beyond the individuals who happen to hold it. A junior technician with a good system and access to the right records can, in some situations, arrive at a diagnosis that would previously have required a decade of experience. The floor rises.
The worse version: the act of capturing information in a system can create the impression that the information is now managed, when what has actually happened is that it has been logged. A fault recorded is not a fault understood. A pattern visible in a report is not the same as a pattern recognised in the field, in real time, against the background noise of a machine doing seventeen other things simultaneously. Digitisation, done badly, can produce operations teams that know more and understand less — that have access to better data and are less capable of interpreting it, because the scaffolding of explicit information has quietly replaced the scaffolding of tacit knowledge without anyone noticing the substitution.
The software that serves this work well is the software that understands this distinction. That treats the system not as a replacement for expertise but as a surface for it — something that makes the expertise more legible, more transferable, more durable, without pretending that the expertise itself can be automated away.
Why the profile matters
The invisibility of this work is not merely a cultural oversight. It has consequences.
It shapes who enters the field and who leaves it. Work that is not recognised as skilled tends, over time, to be compensated and treated as unskilled — which means it attracts fewer people who might otherwise choose it, and loses more of the ones who do, to fields where the same capability is more legibly valued.
It shapes how institutions think about the people who do it. A hospital that treats its service technicians as a maintenance cost rather than a clinical asset makes different decisions about staffing, training, tooling, and retention than one that understands what it would cost to lose them.
And it shapes how software gets built for the field. Products designed for work that is considered low-skill tend to reflect that assumption — simple interfaces for simple tasks, minimal depth, no real investment in the features that would support expertise rather than replace it. The assumption becomes self-fulfilling.
The technician who drove forty minutes in the dark and diagnosed the fault by sound is not waiting for recognition. They have a job to do, and they are good at it, and the work itself is its own form of satisfaction — there is a particular quality of competence, when it becomes fluency, that does not require an audience.
But the people who build the systems they work with, and the institutions that employ them, and the industry that depends on them — they should probably think more carefully about what they have, and what it would take to lose it.
Share

about the author
Jakub Horak
Head of Design
Writes about product thinking, calm software, and what editorial design has to teach a SaaS team.
Continue reading
More from the same beat — operations, equipment, and the slow business of building reliable software.


