A machine-tool maker should put its software engineers on the assembly floor, not in a separate company

I think the answer most Japanese machine-tool makers have given to the software question is the wrong one. The answer is to create a separate digital company, with its own office in a large city, its own pay scales and a mandate to move faster than its parent. My position is that for a maker of precision machines, software that changes how the machine behaves belongs inside the same design authority as the castings and the spindles, and the people who write it should learn the machine before they write a line for it. Monozukuri does not need protecting from software. It needs software written by people who have watched a machine being built.

I should explain where this view comes from, because it has cost us something. When I took over product development at Isaragi in 2019, I recommended ending our own CNC controller programme, and the engineers who moved from it became the core of our operator-software team. Several had never spent a day on an assembly floor. Their first release included an elegant screen for setting work offsets that assumed an operator would stand in front of the controller with both hands free. Our assembly technicians pointed out, politely, that nobody setting a heavy fixture on a horizontal machine has both hands free.

The case for a separate company, taken seriously

The arguments for separation are real, and I do not dismiss them. Software engineers in Japan's large cities earn more than a Nagaoka pay scale allows, and many will not move to a regional manufacturing town. A machine-tool company's release rhythm, built around trade fairs and model generations, is slow for software that could improve every month. And a separate company can hire, promote and fail in ways that a parent with a long tradition of seniority finds hard to accept.

I have watched several companies in our industry and in neighbouring ones take this route. The pattern I have seen, and I accept that it is a pattern rather than a law, is that the subsidiary builds products that sit beside the machine rather than inside it: dashboards, scheduling tools, customer portals. Those products can be useful. They rarely change the accuracy, the reliability or the ease of setting up the machine, because the people who could change those things work for another company with other priorities. The parent's engineers come to see software as somebody else's job, and the subsidiary's engineers come to see the machine as a source of data.

For a machine tool, the software that matters most sits close to the iron. Thermal compensation, the logic that protects a spindle in a collision, the cycles that let an operator probe a part and correct an offset, and the screens a technician uses at three in the morning to recover from an alarm all change what the machine does to metal. Getting them wrong scraps parts or damages machines. That work needs people who know why a ball screw warms faster than the column, and who have felt a tool vibrate just before it breaks.

Six weeks in assembly before the first line of code

Since 2021 every software engineer who joins our Technology Headquarters spends six weeks away from a keyboard before being assigned to a product. Two weeks are on the assembly line at Nagaoka, including a few days beside the scraping technicians. Two are in our test cell, running cutting trials on the materials our customers machine. Two are with a service engineer, travelling to customers' plants. Not every part of it is popular. Several engineers have told me the scraping days felt like an initiation ritual, and I understand why.

The results have been specific. Our second operator-software release rebuilt work-offset setting around a handheld pendant after two new engineers had tried to set offsets with a fixture in their arms. Field defect reports attributed to software in the first ninety days after a release fell from 41 on the first release to 9 on the fourth. That does not prove the rotation caused the improvement, because the team also matured over the same period, but the engineers themselves cite what they saw on the floor when they explain design choices.

The rotation has costs. Six weeks is a large share of a new engineer's first year. Some candidates from the big cities turned us down when they heard about it, and two of the software engineers we hired from outside manufacturing left within a year. We have accepted a smaller pool, partly offset by our technical centre in Pune and by letting experienced engineers live elsewhere and come to Nagaoka for set periods.

Two signatures on every release

The second part of my argument concerns authority. In many Japanese machine-tool companies, including ours until recently, a product release was approved by the chief engineer of the machine family, who was almost always a mechanical engineer. Software was treated as a component, tested and accepted like a motor. That arrangement tells software engineers that their judgement is subordinate, and it tells mechanical engineers they need not understand the code.

Since 2022 every product release at Isaragi has carried two signatures: the chief mechanical engineer of the family and our chief software engineer. Either can stop a release. In the first year the rule stopped two, one for a mechanical reason and one because a change to the spindle-protection logic had not been tested on the oldest machines that would receive it through an update. The second stop delayed a product announcement by six weeks and annoyed our sales division. It also prevented a fault on several hundred machines already in the field.

Equal authority has to come with an equal career. With our human resources division I have introduced a technical ladder on which a principal software engineer can reach the same grade and pay as a chief mechanical engineer. Before that change, a software engineer's only route to seniority was management, and the best of them often chose to leave instead.

I do not claim our model suits every manufacturer. A company whose products are largely mechanical, with software confined to a standard controller, may need much less of this. A company building a genuinely separate software product, sold to customers who own many brands of machine, may need a separate organisation for good reasons. And our approach is slower to recruit for than a city subsidiary would be.

But I would ask any board in our industry to test a proposal for a separate digital company with three questions. Which software in our machines changes what they do to metal? Who will write it, and have they seen a machine built? And who has the authority to stop a release that the mechanical engineers favour? If the answers point to people outside the design authority, the separation may produce good software and worse machines. Monozukuri, as I understand it, means care for the whole product. Software is now part of the product, and the care has to include it.