I’m 18 years in, currently second‑shift lead running a Haas UMC‑750 and a Mazak QT, and I’m eyeing a move into full‑time programming. For those who’ve done it mid‑career, did a short‑term pay dip or schedule change pay off in the long run — more say in process, mentoring apprentices, and future‑proofing the skillset?
I moved into full‑time programming after years on a Mazak cell; what made it stick was a 5‑week hybrid where I programmed the first half of my shift and proved the second half on our UMC‑750, then handed the boss hard numbers on cycle‑time/setup gains. Small caveat: the dip hurts if OT dries up, so I negotiated one guaranteed OT block during the trial. Would your shop let you try a short ‘second‑shift’ split on the UMC‑750/QT to build the case?
But @norwalk’s hybrid idea is solid, but I’d pitch a 4–6 week pilot where you program off the floor two days a week for a repeat family and deliver standardized ops sheets, tool libs, and probing checks to prove ROI. Ask to keep your second‑shift differential during the trial — pay dip games drive me nuts — and use changeover time and scrap as the success metrics. Got a high‑runner on the QT you could use as the test bed?
Pilot one Mazak QT family offline, measure setup minutes saved; negotiate a 90‑day review on any ‘pay dip’. Fair?
If “more say in process” is the goal, bake it in: propose a simple change‑control rule — no at‑machine edits without a logged rev and tool library ID — plus DNC lockouts, then track first‑article pass rate and rework hours for 30 days. Building on @johcart, make ownership explicit or you’ll end up the on‑call fire extinguisher instead of the programmer. Do you already have DNC/revision control (even a shared folder with read‑only controls)?