In brief
When software fails to take hold in a machine shop, the software gets the blame. Almost always wrongly. What blocks it is people: the ones on the floor who fear what the tool will reveal about them, and the owner who doesn't understand what the person pushing for it is actually doing.
That person already exists in most small manufacturers. They built the spreadsheet everyone uses, they rig up faster ways of working, they ask questions about things that aren't their business. And they get held back — because they move fast, because they're technical, because it isn't their job. So the company loses them. Here is how to recognize that person, what it costs to let them burn out, and the minimum framework that lets them work for you instead of against their own employer.
The problem is almost never the software
An owner who has already botched one rollout will describe it like this: "we tried, it didn't work, the system was too complicated for us." That's the convenient explanation. It's rarely the right one.
Look at what actually happened. The software was bought by management, presented on a Tuesday morning in the meeting room, and everyone was expected to be using it by the following Monday. Nobody on the floor was asked what needed to change. Training lasted two hours. The old system stayed in place "during the transition," which is to say forever. Six months later, three people use the tool, everyone else went back to paper, and the invoice still shows up every month.
None of that is a software problem. Those are problems of people, time and framing. And the large studies on digitization projects, across every sector, put the failure rate somewhere between two thirds and three quarters — with the same family of causes at the top of the list every time: adoption, not technology.
The software that fails is almost never the wrong software. It's the right software dropped into a shop that was never asked its opinion.
The good news is that what's missing isn't a budget. It's a person — and you very likely already have them on your payroll.
What your people are actually afraid of
Before talking about the one who pushes, we have to talk about the ones who hold back. Because they get described badly. "They resist change" means nothing: nobody resists change as such. People resist a specific loss, and that loss has a name they will never say out loud in front of a boss.
On a shop floor there are five of them. I've heard them expressed a thousand ways, never directly.
| The fear | What you hear instead | What to answer |
|---|---|---|
| Being replaced "if the machine does my job…" |
"We've always done it this way and it works." | Name what disappears: the re-typing, not the trade. And say where the freed time goes — back onto the floor, not out the door. |
| Being monitored everything gets time-stamped |
"We don't have time to key that into the system." | Decide in advance who sees what, and say it. Data used to understand a process must never be used to rate a person. |
| Being exposed the strongest one, never spoken |
"Computers aren't really my thing." | This is an inspector with thirty years of experience becoming a beginner again in front of a screen, in front of his coworkers. Train him privately, and first, before the group. |
| Losing informal power the one who "knows where things are" |
"The system won't handle the special cases like we do." | Give the status back another way: let him decide how the special cases get modelled. His knowledge becomes the system's rule. |
| Double workload the only fear that is entirely justified |
"So now we'll do both, and it'll take longer." | He's right. Set and announce the date the old system dies. Without that date you aren't deploying anything — you're adding work. |
Note that four of these five are settled with words, not money. They simply have to be said out loud, which means they have to be understood first. A rollout that opens with "here's the new system" instead of "here's what won't change for you" loses the room in the first thirty seconds.
The fear nobody talks about: the one at the top
Every article on resistance to change stops there, at the fears of the shop floor. One is missing, and it's the decisive one, because it belongs to the person who decides.
An owner of a small manufacturing business knows the trade better than anyone. He can read a drawing, size up a quote, sense a customer who's going to pay late. Put in front of him an employee talking about databases, fields to normalize and single-entry data, and something uncomfortable happens: for the first time in his own company, someone is working on a subject he cannot evaluate.
There's a very sharp line where this happens, and it's always in the same place.
As long as you stay in a spreadsheet, everyone follows you. The moment you step outside it, nobody understands a thing.
The spreadsheet is the technical glass ceiling of the small manufacturer. It's the last tool the owner, the foreman and the bookkeeper can all read. Below it, people argue about the content. Above it — a script, a database, an automation — nobody argues about anything: the person gets judged instead of the result.
And that judgment takes four forms. They come in this order, almost every time.
"That's not your job." The boundary reminder. What you built may well be excellent, but you weren't the one supposed to build it, and that question comes before the value of what was produced.
"How many hours did you spend on that?" Time counted as an expense, never as an investment. The question is never followed by its counterpart: how many hours a month does it save. Nobody does the subtraction.
"We don't understand what you're doing." The technical wall, said without hostility, often in complete good faith. Except that in a business, what isn't understood doesn't get funded.
Silence. The hardest of the four. No opposition, no refusal, no debate: nothing. The tool is shown, it works, it saves hours, and absolutely nothing happens. Nobody says no, so there isn't even a decision to argue with. It dies on its own.
None of these four reactions is malice. They're the normal reflexes of a busy owner facing a subject he has no way to judge, presented by someone who has no way to translate it for him. The problem isn't moral. It's linguistic.
The expensive reflex: looking outside for what's already inside
When that same company finally decides to digitize, it almost always does the same thing: it looks outside. A consultant, an integrator, the nephew who's good with computers. Competence, in the owner's mind, comes from elsewhere — that's practically how you recognize it.
That spend has three flaws, and they're serious.
The consultant leaves with the knowledge. He spent six weeks understanding your shop — your special cases, the customer who demands his own format, the way you number jobs. That understanding, dearly paid for, walks out the door with him on the last day. What stays behind is a document.
The integrator knows his product, not your trade. He'll configure a generic system very competently. He won't know that a dimension reworked three times on one lot isn't an isolated incident but the symptom of a fixture that moves — because that isn't taught in product training, it's learned gritting your teeth next to the machine.
Meanwhile, the person who has both halves is already inside. They know the trade and they're interested in the tools. They generally cost less than the consultant's day rate, and six months earlier someone explained to them that it wasn't their job.
It's the paradox that struck me hardest in fourteen years: small manufacturers pay dearly for outside expertise that will have to learn everything, while holding back inside expertise that already knows — because the first arrives with an invoice, which makes it credible, and the second arrives with an idea, which makes it suspect.
Recognizing the innovator you already have
They won't introduce themselves by saying they want to innovate. They probably never use the word. Here are the real signs, the ones you can check this week in any shop.
They built the spreadsheet everyone uses. The one with formulas nobody else can modify, the one they get asked to update every time something changes. It's the most reliable sign of all: they solved a collective problem on their own time, with no mandate, and nobody asked them to.
They automate the task before doing it. They spend two hours building a template for a job that would have taken three by hand. Seen from outside, that looks exactly like someone wasting time.
An employee who automates a task before doing it isn't avoiding work. He's investing. The trouble is that from the outside the two look identical — and the difference only shows up in the third month.
They ask why. Not "how do I fill in this form," but "why do we fill in this form, and who reads it afterwards." That question is irritating, and it's precisely the one that finds the waste.
They show their stuff to coworkers. Unprompted, because it interests them. That's your shop's natural trainer, and they're already training — on tools they picked themselves.
They try tools on their own initiative. An app on their phone to track calibrations, a free program found one evening. That isn't a lack of focus. That's technology scouting, done for free, by someone nobody assigned to it.
Three important clarifications, because people often pick the wrong person. It isn't necessarily the most senior. It isn't necessarily the quality manager — often that one is far too busy holding the existing system together to be allowed to question it. And it isn't necessarily someone easy: a person who sees what doesn't work says so, and that doesn't make them the most restful employee in the shop.
Trust, concretely
"Trust" sounds like an empty word. In this specific context it means three verifiable things, and nothing else.
Accepting that you won't understand the method. You don't have to understand how he structures his data, any more than you ask your machinist to explain his toolpaths before letting him cut. You judge the result: does the report come out faster, does it come out clean, can anyone other than him use it. Three questions, none of which requires technical knowledge.
Letting him move at his own speed, even when it looks unreasonable. This is the most counter-intuitive point, and the one nearly every owner gets wrong. An innovator moving fast isn't taking risks — he's eliminating them, because he's trying ten things instead of one and nine will be in the bin before you ever hear about them. Slowing him to your pace doesn't make the project safer. It just makes it longer, more expensive, and it kills the only thing that was driving it.
Saying it out loud. An authorization that isn't spoken doesn't exist. "Go ahead, take your Thursday afternoons on it until the holidays, show me where you're at at Christmas" — that sentence is worth more than any training budget. It turns an employee cheating with his schedule into someone with a mandate.
And it's worth being clear about what trust isn't. It isn't a blank cheque, or an absence of follow-up, or permission to rewrite everything. An innovator with no framework is as unproductive as one held back: he starts fifteen projects and finishes none. Trust applies to the method. The framework applies to the scope, the date and the expected result. Both together, or neither.
What it costs to lose him
Take a story. It's a composite: not one particular shop, but what I've watched repeat itself in several, with different faces and always the same mechanics. Call him Marc. Quality inspector, about forty people in the shop, a dozen years of seniority.
What Marc does is simple: he automates his own tasks before doing them, so he'll be faster afterwards. As long as it stays in spreadsheets, nobody says a word. The day it requires stepping outside them — structuring data, writing a small program — the conversation stops dead. The four answers from earlier, he gets them in order, the last one being silence.
The tipping point isn't a rejected project. It's the moment he realizes his position could be on the line: that working to improve things, in good faith, on his own time, could cost him his job. That day, two things break at once.
The first: he's stuck in an operations role with no path to improve anything at all. Not slowed — stuck. Those aren't the same thing: you can negotiate with a brake.
The second, and deeper: he stops believing what he was taught about companies. Meritocracy, the idea that doing your job well and trying to do it better eventually gets noticed. It doesn't get noticed on its own. It gets noticed if you know how to make it visible — and that's a completely different skill from the one that made him good.
A technician is rarely a political animal by nature. That's exactly why he's good at what he does — and exactly why nobody hears him.
And Marc owns his share, otherwise this story is just a complaint. He moved too fast for them: three steps ahead while management was still on the first, never slowing down to bring them along. He took the time out of his own, which let him move without permission and cost him his health. He never asked for a framework: no mandate, no date, no sponsor — nobody had told him yes, so nobody owed him anything. And he showed the tool and the method, never the hours saved per month. The return existed, it was measurable. He never measured it.
There's a Marc in a good share of the shops out there. Most of them never made any noise, which is precisely why they're counted nowhere.
So much for him. Now look at the company's trajectory, because that's the one that matters to an owner.
Figure 1 — What internal initiative becomes, with and without a framework
With no framework, initiative rises fast — that's unfunded enthusiasm — then collapses at the first refusal, and doesn't come back. With a bounded mandate it climbs in steps: each step is a finished project, shown, and followed by a new authorization. The second scenario is slower for the first six months. It's the only one of the two still alive at two years. Illustrative diagram.
The expensive scenario isn't the one you'd expect. It isn't the departure: when the person leaves, at least you know, you look for a replacement, the loss is visible and eventually gets counted.
The most common and most expensive scenario is the one where he stays. He does exactly his job, correctly, without a word too many. He proposes nothing anymore. He no longer flags the problems he sees going by — he still sees them, he's simply stopped mentioning them. Your indicators don't move: normal attendance, normal output, no complaints. And you've just lost, with no accounting trace whatsoever, the only person in the shop who was still looking at how the whole thing worked.
The one who already tried and gave up
Which leads to a question few owners ask themselves: what if it has already happened here?
Statistically, that's the most likely case. Three or five years ago, someone came forward with something. They were told it would be looked at later, or that there were other priorities — which was probably true at the time. They didn't insist. They never raised it again.
The signs are quiet but readable. That person has skills that are useless in their current role. They still tinker with things for themselves, which they no longer show anyone. When you announce a new project in a meeting, they say nothing — not for, not against. And if you ask them directly, the answer is "whatever you think."
Restarting them is possible, but not with the usual methods. Three things, in this order.
Name what happened. "You came to me with something three years ago and we never got back to you." That sentence alone defuses half the blockage, because it proves it didn't go unnoticed. Don't dress it up, don't apologize for it: state it.
Ask for a small yes, not a big one. Don't hand them the shop's digitization project. Ask them to fix one precise irritation, bounded, in a few weeks. They no longer trust you: they need short proof that this time, someone will see it through.
See it through, visibly. The first result has to be shown in a meeting, with their name on it. Not a private thank-you — recognition in front of the others. That's exactly what the first attempt never got.
And if it doesn't take, accept it. Some people have closed that door for good, and that's their right. The real lesson is elsewhere: it is far cheaper not to extinguish someone than to try to relight them.
The honest arithmetic: one in ten
Now for the objection any serious owner will raise, and it deserves an answer with no spin: does this pay?
Honest answer: most of the time, no. Out of ten internal initiatives, one will genuinely change something. Maybe two. The others will deliver a small gain, or nothing at all, or a tool only its author ever uses.
That would be a bad bet if the other nine were wasted. They aren't.
One project in ten pays. All ten tell you what works in your shop and what never will — and that map is something no consultant can sell you.
Every failed attempt tells you something precise about your operation: that your guys will never key data into a fixed workstation at the far end of the floor, that the night foreman will never read a dashboard, that your job numbering is too shaky to serve as a key for anything. That's hard information, specific to your company, and it makes the next attempt shorter. An organization that has failed at nine small projects in three years knows infinitely more about itself than one that has launched none.
What remains is to bound the stake, because nine failures are only acceptable if they're small.
Half a day a week is 10 % of one person's time. In a shop of thirty, that's three tenths of one percent of your payroll. You lose more than that every year in rework you never even discuss in a meeting. At that price the question is no longer "is it worth trying," but "can I afford not to know."
And the other side of the ledger belongs here too, the one that appears on no accounting line: the cost of having tried nothing. It isn't an expense, it's a gap. It shows up the day a customer asks for traceability you can't produce, or when the competitor in the next town delivers a quality package in two days where you need ten. That gap never shows in the month's financials. It shows in the tenders you stop receiving.
The framework, in five rules
Here's the operational part. Five rules, applicable Monday morning, in a shop of twenty to a hundred people.
1. Official time, not stolen time. Put it in the schedule, like a job. Half a day a week, a fixed day. The difference between granted time and time taken on the sly isn't administrative: it decides whether the person ends up with a project or with burnout. Someone improving your company on their evenings is giving you a gift they won't be able to give for long.
2. A written scope, no leash on the method. Three lines is enough: the problem to solve, how we'll know it's solved, the date we look. "Cut the time it takes to put together an inspection report. Measured in minutes per report. We look on November 15th." What happens in between is none of your business — that's where trust operates.
3. A translator, or yourself in listening position. Someone has to bridge the technical and the decision. If nobody in management plays that role, take it yourself: fifteen minutes a month, one single question — "show me what this changes about somebody's job." You don't need to understand the tool to judge that answer.
4. Demand numbers, and learn them together. Not as an exam: as a shared language. Minutes per report, rework per month, late deliveries. A technical innovator doesn't spontaneously think about measuring — he thinks about making it work. Asking him to quantify is doing him a favour: it's the only thing that will protect his project when a harder year arrives.
5. Make the first result public. In a meeting, with his name on it. That isn't decoration. You're sending two messages at once: to him, that it counts; to everyone else, that it's allowed. The second person who comes to you with an idea will have come because of that meeting.
The permanent help-desk trap
Once the tool is in place, a mechanism sets in, and it kills more innovators than every refusal combined.
Because he knows the system, everyone calls him. A forgotten password, a jammed printer, a report to find. Each interruption takes three minutes. There are twelve a day. Six months later he creates nothing: he has become the company's IT department, without the title, without the pay, and without ever having agreed to the role. Many leave at this stage — not for lack of recognition, but because they're now doing a job they didn't choose.
Three simple protections.
Train at least two people, never one. That's the rule that matters most, and it protects you too: a shop where a single person can keep a system running is a fragile shop. That person will eventually take vacation, or leave.
Write the procedure as you go. One page per common operation, written the moment the problem comes up for the first time. It costs ten minutes that day and removes the question forever.
Separate the two roles explicitly. Routine support belongs to someone's job description — name them. Improvement time belongs to a different slot, and it doesn't get eaten by the first. Without that boundary, urgency wins every week.
The rollout, in practice
That leaves the operation itself. Nothing below is original; it's simply the opposite of what usually gets done.
Figure 2 — Two ways to install the same tool
| What fails | What sticks |
|---|---|
| General announcement, everyone switches the same Monday. | One real job, one person, two weeks. Fix it before widening. |
| Vendor demo on an ideal case. | Trial on your most painful part, the one with the difficult customer. |
| Two-hour group training for the whole shop. | The champion trains one-on-one, starting with the least comfortable, no audience. |
| The old system stays "until people get used to it." | A shutdown date announced from day one, and held. |
| Success measured by management, at year end. | One simple number, taken weekly, posted where people walk by. |
| Irritations surface at the quarterly meeting. | They go to the champion, who is allowed to change the tool. |
The right-hand column costs no more than the left. It costs patience during the first six weeks — precisely when the urge to move fast is strongest.
A word on the shutdown date, because it's the line almost nobody holds. As long as the old system exists, people fall back on it at the first snag — and there will be snags. Running both isn't a gentle transition: it's the surest way to pay twice for work done once and a half. Announce the date at the start, and hold it even if the tool isn't perfect that day. It never will be beforehand.
If you're the one pushing
This piece is addressed to owners, but it will be read by people who recognize themselves in the other role. Four things, so they get said to you before rather than after.
Show the result, not the method. Nobody will ever ask you how it's built, and explaining it works against you: it moves the conversation onto the one ground where your listener can't follow. "The report takes seven minutes instead of forty-five" lands immediately. How you got there is your business.
Quantify before you ask. Three hours a week, twelve a month, a hundred and forty a year. An owner doesn't fund a good idea: he arbitrates between numbers. Until yours exists, you aren't in the arbitration.
Ask for a framework, not permission. "Can I try?" gets a vague yes that protects you from nothing. "I'd like to put Thursday afternoons on this until November, we measure the result in minutes per report, and if it gives nothing I stop" — that's a proposal someone can accept or refuse. Both answers are useful to you.
Don't fund your employer's innovation with your health. It's the most widespread mistake, and the only one that can't be undone. A project you carry on your evenings and weekends belongs to nobody in the company: no budget, no mandate, no protection the day someone decides it shouldn't have existed. If your employer won't put working hours into it, he doesn't want the project — whatever he says. That isn't pleasant to hear, and it's what nobody tells people in time.
In closing: three questions
The answers already exist inside your company. None of them requires a study.
Who built the spreadsheet everyone uses? That person solved a collective problem with no mandate, on their own time. It's the only clue you need.
How much paid working time does that person have to improve things? If the answer is none, everything they've produced so far, they paid for out of pocket.
When was the last time someone told them yes? If you can't remember, they can. And if nobody ever told them no either, that's probably worse: silence is the answer that discourages most reliably.
Digitizing a small manufacturer isn't decided when you choose software. It's decided months earlier, in how you treat the first person who came forward to say things could be done differently. That person costs half a day a week. They're already on your payroll. And they're still waiting for an answer.
The convictions defended in this article are the ones that guided the development of Asterion Solutions, a suite of trade-specific tools built for small manufacturers who want to structure their quality without multiplying paperwork.