Lessons From Industrial Engineering

Not the Origin Story This Time

I've written before about how my path moved from electrical maintenance toward product management. This isn't that piece. This is the more specific stuff — lessons that came from particular failures, particular shutdowns, particular moments across VDEAL, Logix, Quess, and JK Paper that I still catch myself applying, outside of engineering entirely.

Documentation Isn't Bureaucracy

Early on, writing service reports felt like the tax you paid after the real work — the fix — was already done. It took a plant audit, and having to reconstruct a maintenance history from someone else's incomplete notes, to understand that documentation is part of the fix. A repair nobody can trace later might as well not have happened, from the system's perspective.

I apply this now in ways that have nothing to do with electrical systems: decisions without a written reason attached tend to get relitigated, or repeated, or misunderstood by whoever inherits them next.

The Failure That Doesn't Happen Gets No Credit

Preventive maintenance is a strange kind of work to be evaluated on, because success looks like nothing happening. Nobody notices the failure that a scheduled inspection quietly prevented. What gets noticed is the breakdown that wasn't caught in time.

This made me suspicious of any system — technical or organizational — that only rewards visible fixes. The best work is often invisible by design, and if your incentives don't account for that, they'll quietly push people toward reactive firefighting instead of prevention.

Root-Cause Analysis Has a Discipline, Not Just a Method

Everyone can recite "ask why five times." Fewer people actually stop at a cause they can act on, rather than the first cause that's convenient to blame. At JK Paper, the easy answer for a repeat failure was almost always "equipment age" or "operator error." The useful answer usually required going further — a maintenance interval that was slightly wrong, a spec that had quietly drifted from what the equipment actually needed.

The discipline isn't the five-whys technique. It's the willingness to keep going past the answer that lets everyone stop asking questions.

Shutdown Planning Taught Me What Coordination Actually Costs

Supervising contractors and technicians during shutdown maintenance meant I was responsible for a schedule I didn't fully control — other teams' timelines, parts availability, weather, all feeding into a single window that had to close on time. Nothing in a textbook prepares you for how much of "engineering" work is actually managing dependencies between people who don't report to you.

That lesson transferred directly and immediately to every group project in the MBA, and I expect it'll keep transferring for as long as I'm doing any kind of cross-functional work.

The Lesson I'm Still Applying

If there's one habit from those four years I trust most, it's this: before proposing a fix, make sure you can explain exactly why the problem happened — not just what fails, but why it fails now, under these conditions. That habit has outlasted the job that taught it to me, and it's the one piece of industrial engineering I don't expect to leave behind.