Fourteen months after the restructuring, the company was paying two of the engineers it had laid off about $180 an hour to come back as contractors. Not to build anything. To answer questions about a test fixture one of them had designed three years earlier and never fully documented.
I have spent a good part of the last two years in rooms where AI layoffs and workforce planning get decided — the meeting where a headcount model, a tool demo, and a board deadline all sit on the same table. This is one company, a hardware startup of about 260 people. I have changed identifying details and rounded some figures, because people I like still work there. The pattern is not theirs alone, which is the only reason it is worth writing down.
The restructuring did not fail because the AI underdelivered. The tooling did roughly what the vendor said it would do. It failed because the company confused the output of a role with the role.
The myth, in its most convincing form
You have heard the crude version and dismissed it: AI is coming for jobs, cut early, move fast. Nobody serious says that in a boardroom.
The version that actually gets decisions made is more careful, and it goes like this: AI does not replace people, it replaces tasks. So inventory the tasks. Find the ones a model now performs at acceptable quality. Total up the hours. Resize the organization around what is left, and redeploy the humans to higher-judgment work.
That framing sounds like rigor because it is rigor, applied to the wrong input. A task inventory captures the work people can describe when asked. It reliably misses the work they do not think of as work — the glance at a supplier change notice that says this resin is not the same resin, the decision to hold a build for two days, the half-remembered reason a tolerance is 0.05 and not 0.1. That work has no ticket. It shows up in the inventory as slack.
What the numbers did
The company cut 41 of 260 people, about 16 percent. Nine test engineers. Six people from technical documentation. Eleven NPI and manufacturing engineers. The rest across quality and supply chain. The stated rationale was defensible on paper: generative tooling could draft test scripts, produce first-pass work instructions, and flag manufacturability problems in CAD review. Annualized savings booked at roughly $6.1 million.
Then the calendar did its work.
In month five, first-pass yield on a new SKU at the contract manufacturer fell from about 94 percent to 81 percent. In month seven, a supplier substituted a resin without meaningful notice; the change notice arrived, was read by nobody who knew what it meant, and shipped into three builds. Field return rate on that product line went from roughly 1.1 percent to 2.9 percent over the following two quarters.
Here is the part that matters for your own modeling — where the money went and, more importantly, whose ledger it landed on.
| What was booked | Where it landed | What was paid back | Where that landed |
|---|---|---|---|
| $6.1M annualized salary reduction | Corporate G&A, Q1 | 3 contractors at ~1.6x loaded cost | Engineering opex, Q3–Q4 |
| Headcount ratio improvement | Board deck, Q1 | 5 rehires, 2 of them boomerangs | Recruiting + comp, Q4 |
| "AI efficiency" narrative | Investor update | Scrap, rework, CM overtime | COGS, Q3 |
| — | — | One launch slipped a quarter | Revenue, next fiscal year |
I cannot give you a clean industry-wide multiple for this. I do not have one, and I am suspicious of the ones I have seen quoted, because the two ledgers above are almost never joined by the same analyst.
The mechanism: two things, both boring
First: the tool produced the artifact, not the judgment about the artifact. A model will write you a test script. It will not tell you that the script passes a unit which will fail in the field, because that knowledge lived in someone who had watched four hundred units come back. AI raised the floor on producing engineering output and did close to nothing to the ceiling on knowing whether the output is correct. When you remove the people who supplied the second thing and keep the tool that supplies the first, you have not automated a function. You have removed the check and kept the thing being checked.
Second, and this is the one I would put on the wall: hardware reports late. A software organization that cuts wrong finds out in a deploy cycle — two weeks, maybe six. A hardware organization finds out at the next build, the next tooling change, the next supplier substitution, the next season of returns. Four to nine months, routinely.
That latency is not a detail. It is the whole reason the decision keeps looking smart. The savings land in the quarter you announce them, in a cost center you own, attributed to a strategy you authored. The costs land two to four quarters later, in COGS and warranty and recruiting, attributed to "supplier issues" and "a tough launch." Both are true. Neither is connected to the other by anyone whose job it is to connect them. A decision whose feedback arrives that slowly, and that scattered, does not self-correct — it repeats.
There is a selection shortcut underneath both of these, and it is worth naming plainly. Cut lists get built where salary is high and output is legible. A test engineer's output is a unit that passes. Their value appears in the organization as the absence of a problem, and absence of a problem is the easiest thing in any company to mistake for spare capacity. That is not stupidity. That is what happens when the instrument you are handed measures cost precisely and measures risk not at all.
What I would do before signing the list
Run the cut list against the field-failure record rather than the org chart. For each role, one question: what did this person catch in the last 24 months, and where is that written down? If the answer to the second half is "in their head," you are not removing a cost, you are converting an asset into a liability with a delay fuse.
Buy the knowledge before you release the person. A paid 60-to-90 day documented transition with a named receiver — not a wiki, a person — costs a fraction of a contractor at 1.6x loaded rate fourteen months later, and it is the version everyone still in the building respects.
Pre-register the review. Pick the metrics now: first-pass yield at each CM, supplier change notices caught, field return rate, launch dates. Write down, before the announcement, what result would count as evidence the cut was wrong. After the fact, every one of those numbers finds a market explanation.
Separate the two decisions and defend each alone. "We need $6 million out of the run rate" can be entirely correct while "these 41 roles are the right $6 million" is entirely wrong. Bundled together, the AI story does the work of justifying both, and it is very good at that job.
And if a tool is the reason a role is going: run it in parallel with the humans for one full cycle first. In hardware, a cycle is not a quarter. It is a build.
What this does not answer
It does not tell you what to do when the cash genuinely is not there. Sometimes the restructuring is survival, and then the argument is about sequencing and what you protect, not about whether. Everything above assumes you had a choice, and plenty of people reading this did not.
It does not tell you which roles hold the undocumented knowledge in your building. Mine came from a company with a contract manufacturer in Malaysia and a resin problem. Yours will have a different load-bearing wall, and you will not find it by asking who is expensive.
Where I would look next is inside your own systems, not in another survey. Pull warranty, scrap, rework, and contractor spend by quarter, and lay it over headcount changes with a two-to-four quarter lag. Then ask HRIS for the rehire and contractor-return rate on the exact roles you eliminated. That number exists in almost every company that has done this. Almost nobody asks for it, because of what it tends to say.
The question was never whether the AI could do the work. It is whether anyone left in the building can tell when it has done it wrong.
