Your Mazatrol Programmer Just Quit. Here's How to Keep the Lathes Running.

This is one of the most common phone calls I get, and it never comes at a good time. Your Mazatrol programmer — maybe your only Mazatrol programmer — gave notice, or didn't, and now the knowledge of how your lathes actually run is walking out the door with him. Jobs are on the schedule. Customers don't care about your staffing problem.

I'm Tom Herzog. I spent 19 years at Mazak Corporation as an Applications Engineer and I've done the same work independently through Added Performance Machining in Linden, Michigan ever since. A good part of that work is walking into exactly this situation. Here is what I do in the first week, and what you should do whether you call me or not.

What's actually at risk

The programs on the control are the least of it — those, at least, are still there. What leaves with a departed programmer is everything around the programs:

• Setup knowledge. Which workholding for which job, what the chuck pressure was, why that one part runs in the sub-spindle first. None of it written down.
• Tool data discipline. Which tools are in which pockets, what the tool descriptions actually correspond to, which offsets are load-bearing.
• The workarounds. Every long-running job accumulates small fixes — a tweak here, a parameter there — that live in one person's memory.
• Supplier and process context. Why a part is run the way it's run, and which corners were already tried and failed.

The danger isn't that production stops today. It's that it degrades slowly — a crash here, a scrapped run there, cycle times creeping — because the knowledge layer is gone.

The first-week stabilization plan

When I come in after a departure, the order of work is always the same:

1. Audit what's on the controls. Every program, backed up, inventoried against the jobs actually on your schedule. If there's no current backup of parameters and programs, that gets made before anything else — see why in the parameter backup guide. A departure is exactly when a dead battery turns into a catastrophe.
2. Document the live setups. The jobs running now get written down while they're still running: tooling, offsets, workholding, the notes that were never notes.
3. Keep production shipping. Triage the schedule. The jobs that pay the bills get proven and protected first; the rest get sequenced honestly.
4. Identify the single points of failure. Which jobs can literally nobody else in the building run? That list becomes the training syllabus.

By the end of that week you should know what you have, what you can run, and what you can't. Most shops find the situation is bad but not as bad as the first morning felt.

Then the fork

Once production is stable, there are two ways out, and most shops need some of both:

Train a successor. Pick the machinist who will own Mazatrol in your building and train them properly — on your machines, on your parts. This is the durable fix. It takes weeks, not days, but it ends the dependency. My training roundup lays out the options honestly, including when a factory class is the right call instead of me.

Bridge with contract days. While the successor gets up to speed — or while you hire — I come in on scheduled days to handle the programming load and the hard parts. That's the programmer-for-hire model, and it's designed to shrink as your person grows.

Never again

The last piece of the work is making sure one resignation can never do this to you again: setups documented as a matter of routine, programs and parameters backed up and stored off the machine, tool data kept honestly, and at least two people in the building who can run every production job. None of that is expensive. All of it is cheaper than the week you're having right now.

If this is your week

Send me the part, the machine, and the control version. I'll tell you what's possible.

Thank you, Tom Herzog