A maintenance manager at a mid-size chemical plant had a reputation. When something broke, he was the first one there. Didn’t matter if it was a weekend. Didn’t matter if it was third shift. His phone rang, he answered, and he walked the crew through the fix or drove in and did it himself.

Everyone respected him. Plant leadership loved him. His uptime numbers were solid. He was the guy.

Then he took two weeks of PTO. First real vacation in three years.

Day four, a heat exchanger developed a tube leak. Routine failure. The crew had seen it before. But they’d never actually diagnosed one without him. Every previous time, he was the one who identified the leaking tube, made the call on whether to plug or replace, and coordinated the turnaround. The crew’s role had always been “wait for instructions.”

They called him on vacation. He didn’t answer. So they called engineering. Engineering said pull the whole bundle for inspection. That turned a 6-hour tube plug into a 3-day bundle pull. Production lost 72 hours they didn’t need to lose.

When the manager came back, he was frustrated with the crew. “They should have known how to handle that.” But they didn’t know. Not because they were incapable. Because every time that situation came up, he handled it. He never let them fail at it. He never let them learn it.

His problem-solving wasn’t building reliability. It was replacing it.

The Tactic: Stop Being the Answer

The instinct to jump in and fix things is not a character flaw. It comes from a good place. You know the equipment. You know the fastest path. And the cost of a wrong decision feels higher than the cost of just doing it yourself.

But every time you solve a problem your team should own, you confirm two things: that they don’t need to develop the skill, and that the system works fine as long as you’re available. Both of those are lies. And they compound.

Here’s the move. Pick one recurring problem that you currently own. Not the most critical one. Start with something where a wrong decision costs hours, not days. Then do three things:

1. Name the decision. Write down exactly what judgment call you make when this problem shows up. “I check the vibration trend, compare it to the last three readings, and decide whether to run to failure or pull forward the PM.” That’s the decision. Your team can’t learn it if they can’t see it.

2. Teach the framework, not the answer. Walk your lead or senior tech through your decision process on the next occurrence. Don’t tell them what to do. Show them how you decide what to do. Then let them make the call with you standing there.

3. Let the next one go. The occurrence after that, don’t show up. Let them run it. They might get it wrong. The cost of that wrong call is almost always less than the cost of a team that can’t function without you.

This isn’t delegation in the HR-training sense. This is building redundancy into your reliability program at the human level. You’d never design a system with a single point of failure on the equipment side. But most maintenance organizations have exactly that on the leadership side.

The Benchmark: Resolution Independence Rate

Resolution Independence Rate = Problems resolved without manager/supervisor direct involvement / Total problems resolved

This metric measures something most plants never think to track: how often your team solves problems on their own.

Where most plants sit: Nobody knows. Because nobody tracks it. The manager shows up, the problem gets fixed, and the work order says “completed.” It doesn’t say who actually made the diagnostic call or whether the crew could have handled it alone.

Where good looks like: Above 70%. The majority of routine and semi-routine issues get resolved by the crew using documented decision frameworks, standard procedures, and their own judgment. The manager gets involved on escalations, not on every call.

Start tracking it this week. For the next 30 days, tag every work order with a simple field: “Resolved by crew” or “Required supervisor/manager involvement.” Don’t change anything else. Just track it. At the end of 30 days, you’ll know what percentage of your problems actually require you and what percentage you’re inserting yourself into out of habit.

If the number is below 30%, your team isn’t underperforming. Your system is designed to keep them dependent.

The CMMS/AI Play: Build a Decision Tree Into the Work Order

Here’s where most “let the crew handle it” efforts fail: the manager leaves, the crew faces a decision point, and there’s no documented framework for how to make the call. The knowledge lives in the manager’s head. Telling the crew to “use their judgment” when they’ve never been taught the judgment is not empowerment. It’s abandonment.

Your CMMS can close this gap. For your top 10 recurring failure modes, build decision logic directly into the work order template. Not a 40-page procedure. A simple branching structure:

• Symptom observed → Check A

• If Check A shows X → Do Y

• If Check A shows Z → Escalate to [specific person] with [specific information]

An AI agent can accelerate this. Feed it the last 24 months of work orders for a given asset. It identifies the most common failure modes, maps the typical resolution paths, and drafts decision trees based on what your team has actually done in the past. The maintenance manager reviews and adjusts. The agent didn’t invent the knowledge. It extracted it from your own history and made it transferable.

The result: when the heat exchanger leaks at 2 AM and the manager doesn’t answer, the crew opens the work order and the decision framework is right there. Not because someone wrote a manual. Because the system captured what the expert does and made it available to everyone.

That’s the difference between tribal knowledge and organizational knowledge. One leaves when the person leaves. The other stays.

The Template: Manager Delegation Audit

This week’s template is a one-page self-assessment for maintenance managers and supervisors. It’s uncomfortable by design.

Answer honestly for the last 30 days:

Section 1: Involvement Pattern

• How many after-hours calls did you take?

• How many of those required your specific expertise vs. your authority to make a decision?

• How many problems did you solve that a senior technician could have solved with the right information?

Section 2: Knowledge Transfer

• For your top 5 recurring issues, can your lead tech describe your decision process?

• Are those decision processes documented anywhere accessible?

• When was the last time you let a crew member make a wrong call and coached them through it afterward?

Section 3: Dependency Test

• If you were unreachable for 48 hours, which problems would your team handle fine?

• Which would stall?

• For the ones that would stall, is that because the crew lacks skill, or because the crew lacks permission?

[Download the Manager Delegation Audit (PDF)]

(Covers: involvement frequency, knowledge transfer status, single-point-of-failure identification, and a 30-day action plan.)

From the Floor

“I’ve tried delegating, but when my team makes the wrong call it costs us. How do I let go without the plant paying for it?”

This is the trap. And it’s real. Bad calls cost money. But so does building a team that can’t function without you. You’re just not seeing that cost because it doesn’t show up on a single work order. It shows up over years, in slower response times, in talent that never develops, in your own burnout.

The answer isn’t to hand over everything at once. It’s to build a ladder.

Start with decisions where the downside is small. A wrong call on a routine PM reschedule costs you a few hours. A wrong call on whether to pull a critical asset offline costs you a shift. Start with the PM reschedule. Let them make the call. Coach afterward, not during. Then move up to the next level.

Most managers skip the ladder and try to delegate the high-stakes decisions first. When that inevitably goes wrong, they conclude that delegation doesn’t work and go back to doing everything themselves. That’s not evidence that your team can’t learn. That’s evidence that you started at the wrong rung.

The other piece nobody talks about: sometimes the reason you can’t let go isn’t about the team. It’s about identity. If you’re not the person who fixes everything, who are you? That’s a harder question than any equipment diagnosis. But it’s the one that actually matters.

Got a question from the floor? Something you’re dealing with at your plant that you want a straight answer on? Reply to this email. Best questions get featured in a future issue.

That’s The Floor Report #3. If this was useful, forward it to someone on your team.

See you next week.

— Ivan

A plant ran RCA on a gearbox failure. Standard process. 5-why, fishbone, the full investigation. Solid work. They found it. Lubrication schedule was wrong for the application. The oil grade was spec’d for a previous operating condition that changed two years ago when production increased throughput by 15%.

The corrective action was clear: update the lubrication schedule for the new operating parameters, retrain the lubrication technician, and add an engineering review trigger whenever production changes operating conditions on critical assets.

Three months later, the same gearbox failed again. Same failure mode. Same root cause.

The corrective action was still sitting in a planning backlog. No owner. No due date. No follow-up meeting scheduled. The RCA report was filed in a shared drive folder that hadn’t been opened since the day it was saved.

The investigation was excellent. The follow-through was nonexistent. And that’s the pattern I see over and over. Plants that are great at finding causes and terrible at fixing them.

The Tactic: Close the Loop or Stop Opening It

The RCA itself is rarely the problem. Most maintenance teams can find the cause. The failure point is what happens between “corrective action identified” and “corrective action completed.”

Here’s where it breaks down. The RCA meeting ends. Someone writes the corrective action in the report. That action requires a work order, budget approval, a scheduling slot, or an engineering change. Nobody in the meeting has the authority to execute all of those. So the action gets noted, filed, and forgotten.

The fix is structural, not motivational.

Every corrective action coming out of an RCA needs three things before the meeting ends:

1. A named owner. Not a department. A person. “Maintenance will handle it” means nobody will handle it.

2. A due date. Not “when we get to it.” A specific date that someone is accountable for.

3. A review checkpoint. A 30-day follow-up where someone with authority confirms the action was completed. Not started. Completed.

If your RCA process produces findings but doesn’t produce these three things, you’re running a documentation exercise. Useful for compliance. Useless for reliability.

One more thing. Track your corrective action completion rate separately from your RCA completion rate. Most plants proudly report that they completed 95% of their RCAs last year. Very few track how many of those corrective actions were actually implemented. That’s the number that matters.

The Benchmark: Corrective Action Close Rate

CA Close Rate = Corrective actions completed on time / Total corrective actions assigned from RCAs

This is the number that separates plants running real reliability programs from plants running RCA theater.

Where most plants sit: Below 40%. They complete the investigations. They identify the actions. Fewer than half ever get implemented within the original timeframe. Many never get implemented at all.

Where good looks like: Above 80%. Every corrective action has an owner, a deadline, and a review checkpoint. Overdue items get escalated, not ignored. Leadership reviews open corrective actions monthly as part of the reliability meeting, not as a separate audit someone remembers to do twice a year.

Start tracking it this week. Pull every RCA from the last 12 months. List the corrective actions. Check how many were actually completed. If the number makes you uncomfortable, that’s the point. You now know where your reliability program actually stands, not where your RCA reports say it stands.

A 95% RCA completion rate with a 30% corrective action close rate means you’re spending money to describe failures you’ve chosen not to fix.

The CMMS/AI Play: Auto-Track Corrective Actions to Completion

Here’s where most corrective actions die: they get written in a report, maybe mentioned in a meeting, and never entered into a system that tracks them to completion. They live in PDFs and slide decks. They don’t live in your work management system.

The play: every corrective action from an RCA should generate a tracked work order in your CMMS. Not a note. Not a comment on the original failure work order. A standalone corrective action work order with an owner, a priority, a due date, and a completion status.

An AI agent can automate this handoff. The moment an RCA report is finalized, the agent parses the corrective actions, creates work orders in your CMMS for each one, assigns them based on the action type (engineering change goes to engineering, procedure update goes to the planner, training goes to the supervisor), sets follow-up reminders at 30 and 60 days, and flags overdue items in a weekly reliability digest.

No more corrective actions lost between the RCA folder and the planning backlog. The system tracks them the same way it tracks any other work order. Because that’s what they are. Work that needs to get done.

The gap between “finding the cause” and “fixing the cause” is almost always a workflow gap. Not a knowledge gap. Automate the workflow and the gap closes.

The Template: RCA Corrective Action Tracker

This week’s template is a standalone tracker for corrective actions coming out of your RCA program. One row per action, with columns for everything that matters.

Use it as a supplement to your RCA reports or as the standing agenda for your monthly reliability review.

Columns:

• RCA Reference (which investigation)

• Equipment / Asset

• Corrective Action Description

• Owner (named person)

• Due Date

• Status (Open / In Progress / Completed / Overdue / Canceled)

• Completion Date

• Days Overdue (auto-calculated)

• Escalation Notes

[Download the RCA Corrective Action Tracker (spreadsheet)]

(Covers: action assignment, deadline tracking, escalation triggers, and monthly review format.)

From the Floor

“We do RCAs but nothing ever changes. How do I fix that without more meetings?”

You don’t need more meetings. You need the meeting you already have to produce outputs that go into a system instead of a folder.

The problem isn’t that people don’t care about the findings. The problem is that the findings leave the room as intentions, not as tracked work. Intentions decay. Work orders don’t.

Here’s the minimum viable change: end every RCA meeting by entering the corrective actions as work orders before anyone leaves the room. Owner, due date, priority. Takes five minutes. If the action needs budget approval, the work order is “submit budget request by X date.” If it needs engineering review, the work order is “complete engineering assessment by X date.” Break it into steps that can be tracked.

Then add one standing item to your existing monthly reliability meeting: review open corrective actions. That’s it. Not a new meeting. One slide. Five minutes. “These are open. These are overdue. These are done.”

The meeting isn’t the problem. The absence of a tracking system between meetings is.

Got a question from the floor? Something you’re dealing with at your plant that you want a straight answer on? Reply to this email. Best questions get featured in a future issue.

That’s The Floor Report #2. If this was useful, forward it to someone on your team.

See you next week.

— Ivan

A colleague shared a pump failure that everyone blamed on a bad bearing. Classic diagnosis. Replace the bearing, close the work order, move on.

Except when they dug deeper, the bearing didn’t fail on its own. The pump had been running with low oil for weeks. And the oil was low because operations was performing rounds, checking the box, and walking right past it.

Nobody trained them on how to actually assess oil level. Nobody showed them what low looks like versus acceptable. They were doing the round. They just didn’t know what they were looking at.

The root cause wasn’t a bearing failure. It was a training failure that showed up as a bearing failure. And that’s a more expensive problem, because it means every other check on that round sheet is suspect too

The Tactic: Audit the Understanding, Not the Checkmark

Most plants audit round completion rates. Very few audit whether the person checking the box actually understands what they’re inspecting.

Here’s the move: pick one critical check from your operator rounds this week. Walk the round with the operator. When they get to that check, ask three questions:

1. What are you looking for? (Do they know the acceptance criteria, or are they just confirming “looks fine”?)

2. What would bad look like? (Can they describe what a failing condition actually is?)

3. What do you do if you find something? (Do they know the escalation path, or do they just keep walking?)

If the answer to any of those is a blank stare, you don’t have a rounds problem. You have a training problem. And no checklist in the world will fix it.

This isn’t about catching people doing things wrong. It’s about finding the gap between what you assume your operators know and what they actually know. That gap is where your next failure lives.

The Benchmark: Round Yield

Here’s a metric most plants don’t track but should.

Round Yield = Work orders generated from operator rounds / Total rounds completed

If your operators are completing 200 rounds per month and generating zero work requests, one of two things is true: your plant is in perfect condition (it’s not), or your rounds aren’t catching anything.

Where most plants sit: Near zero. Operators complete rounds. Nothing gets flagged. The rounds exist for compliance, not for reliability.

Where good looks like: A healthy Round Yield means operators are regularly identifying early-stage defects. Loose bolts. Unusual vibration. Leaks forming. Oil levels dropping. Not every round produces a finding, but over a month, trained operators who know what they’re looking at should be generating a steady stream of early-warning work requests.

Start tracking it this week. Pull your last 90 days of work orders and see how many originated from operator rounds. If the number is close to zero, that tells you everything you need to know about the quality of your rounds program.

Round Yield won’t tell you everything. But a flat zero tells you exactly one thing: your first line of defense isn’t defending anything.

The CMMS/AI Play: Let the Agent Build the Job Plan

When an operator does flag something, what happens next? In most plants, the planner walks the job, takes notes, goes back to a desk, and manually builds the work order package from scratch. Parts lists. Procedures. Resources. Safety requirements. All of it, every time.

Your CMMS already has that history. Every time that pump was worked on, the parts used, the procedures followed, the resources required. It’s all sitting in the system.

An AI agent can pull that history the moment a work request comes in. It drafts a job plan based on previous work. Cross-references parts with current inventory. Flags what’s missing. Adds standard safety requirements. The planner reviews, adjusts, and approves instead of building from zero.

That’s not replacing your planner. That’s giving them back the 60% of their day they currently spend on data entry so they can focus on what actually requires their expertise.

The technology to do this exists today and it’s not the enterprise-grade, eighteen-month-deployment kind. If you can describe how your planner works in a document, you can build an agent that follows the same process.

(I wrote a full breakdown of how this works. Reply to this email if you want the link.)

The Template: Operator Round Audit Checklist

This week’s template is a one-page checklist for auditing the quality of your operator rounds. Not the round itself. The audit of whether your operators actually understand what they’re checking.

Use it during a ride-along. Walk a round with an operator and score each item. The results will tell you whether your rounds program is a reliability tool or a paper exercise.

[Download the Operator Round Audit Checklist (PDF)]

(Covers: execution integrity, equipment knowledge, sensory inspection skills, documentation quality, and escalation paths.)

From the Floor

“How do I get operations to care about equipment?”

This is probably the most common question in reliability. And the honest answer is: you can’t make people care about something they were never taught to understand.

Operations doesn’t ignore equipment because they don’t care. They ignore it because nobody showed them what matters. They were handed a checklist and told to walk the floor. Nobody explained why that oil level matters. Nobody showed them what a failing bearing sounds like. Nobody told them their round is the first line of defense against a $50,000 failure.

You want operations to care about equipment? Start by treating them like part of the reliability team instead of checkbox operators. Train them on what good looks like. Show them what happens when things get missed. Give them a way to flag problems that actually leads to action, not a work request that disappears into a backlog.

Caring follows competence. Not the other way around.

Got a question from the floor? Something you’re dealing with at your plant that you want a straight answer on? Reply to this email. Best questions get featured in a future issue.

That’s The Floor Report #1. If this was useful, forward it to someone on your team.

See you next week.

Not for maintenance, for content (but bear with me, I promise I have a point). I run a small writing operation and I needed something to handle the repetitive parts: checking what’s scheduled, scanning my notes, pulling together a summary so I know what to focus on. I found a guide, copied it into Claude Code, gave it some direction, and two hours later I had a working agent doing real work.

That night I was thinking about it and realized something that should have been obvious.

This is exactly what a maintenance planner does.

What a planner’s day actually looks like

If you’ve never worked alongside a maintenance planner, here’s the reality. They walk the field. They look at jobs. They take notes on paper, on a phone, sometimes in their head. Then they go back to a desk and start transposing all of that into the CMMS.

Parts lists. Procedures. Supporting resources like cranes, scaffolding, rigging, confined space equipment. Labor estimates. Safety requirements. All of it gets built into a work order package that a mechanic can actually execute.

This process takes time. Real time. And things get lost in the translation. A part number gets transposed. A resource gets forgotten. A procedure that worked last time doesn’t get referenced because nobody remembered to look it up. The planner isn’t bad at their job. The job just has too many places where information falls through the cracks between walking the field and typing it into a system.

Now imagine an agent sitting between those two steps.

What the agent actually does

The planner walks the job and dictates notes or types them rough, the way you’d text a coworker. The agent takes those notes and does the legwork:

• Pulls the work order history for that equipment. The agent can also pull relevant manuals and guides. What was done last time? What parts were used? What went wrong?

• Drafts a job plan template based on previous work. Not from scratch every time, from what already exists in the system.

• Lists the parts, cross-references with what’s in stock, flags what needs to be ordered.

• Adds standard procedures and safety requirements based on the job type.

• Flags anything that looks missing: “Last time this job required scaffolding. No scaffolding listed. Want to add it?”

The planner reviews. Adjusts. Approves. Types corrections instead of building from zero.

That’s not replacing a planner. That’s giving your planner a second brain that handles the 60% nobody should be doing manually anymore.

“But we’re too small for AI”

I hear this constantly from small plants. And I get it, when you hear “AI” you think of the million-dollar projects big corporations run with armies of data scientists and eighteen-month timelines.

This isn’t that.

I built my agent in two hours. I copied a guide, pointed it at my files, and it worked. No IT department. No vendor contract. No data warehouse. If you can describe how your planner does their job in a document, you can build an agent that follows the same process.

And here’s the part small plants don’t realize: you actually have the advantage here.

Big companies guard their data like it’s nuclear codes. Every AI project goes through twelve layers of approval, legal review, cybersecurity assessments, and a steering committee that meets quarterly. By the time they deploy anything, the technology has moved on.

Small plants? You can move next week. Your maintenance data isn’t classified. Your work order history isn’t a trade secret. And you don’t have a bureaucracy standing between a good idea and a working tool.

That’s not a disadvantage. That’s a head start.

I caught up in weeks

I’ll be honest. I am ashamed for waiting this long to jump on the AI hype train, but I started getting into this a few weeks ago. Not months. Not years. Weeks. And I caught up fast enough to build working tools that I use every day.

The technology isn’t waiting for you to be ready. But it’s also not too late. The gap between “I’ve never touched this” and “I have a working agent” is measured in hours, not quarters.

The plants that figure this out first won’t just have better planning. They’ll have planners who can actually plan, instead of spending half their day on data entry that a machine should have been doing years ago.

Your planner is probably doing the work of three people right now. You don’t need to hire two more. You need to give them a tool that handles the grunt work so they can focus on the part that actually requires knowing the equipment, knowing the craft, and knowing what good looks like.

That’s what this is. Not a replacement. A multiplier.

*Next week I’ll walk through the scheduler version, same concept, different application. If you’re running a small maintenance organization and want to try this, reply to this email or contact me. I’ll share exactly how I set mine up.*

Be disciplined. Be fair. Be consistent. Care about people. Hold standards.

And to be clear — those things matter.

But after numerous years inside manufacturing plants, leading maintenance teams, managing capital work, watching systems drift and stabilize and drift again, I started noticing something I couldn’t explain away: Good leaders were failing.

Not because they lacked integrity. Not because they didn’t care. Not because they weren’t competent.

They were failing because the system they were operating inside was quietly shaping outcomes more than they were.

And almost nobody was talking about that.

I’ve watched high-performing supervisors burn out while trying to hold it together. Strong technicians carrying broken processes through personal effort. Managers praised for personality while results quietly eroded. Standards “adjusted” under pressure, not removed, just softened. Drift that didn’t look like failure until it did.

And every time results slipped, the conversation went the same direction.

Who dropped the ball?

Rarely: What signal did the system send?

That’s when it clicked.

Leadership wasn’t failing because people were weak. It was failing because we kept personalizing structural problems.

We like believing leadership is about inspiration. It’s more flattering that way.

A strong leader walks in. Culture improves. Performance rises.

If that were true, performance wouldn’t collapse the moment the leader steps away.

And yet it does. I’ve seen departments that run beautifully under one personality — and unravel when that person leaves.

That’s not leadership strength. That’s dependency. And dependency is not stability.

Leadership Isn’t Personal argues something more uncomfortable than most leadership books are willing to say:

Most performance outcomes are system-driven, not personality-driven.

Intent doesn’t control results. Signals do.

Tolerance creates drift. Silence accelerates it. Late correction magnifies it.

Clear standards reduce personalization. Early correction preserves autonomy. Built-in feedback reduces dependency.

Once you see that pattern, you can’t unsee it. And once you understand it, leadership stops feeling mystical and starts feeling structural.

This isn’t a book about being softer. If anything, it demands more discipline.

Because when you stop blaming people, you lose the emotional release of frustration. You have to fix the design instead.

You have to define standards clearly. Intervene early. Build feedback loops. Remove hero-dependency. Stabilize signals.

That’s harder than motivational speeches. It requires restraint. And maturity.

In a plant, systems don’t care about intent.

If lubrication intervals drift, equipment fails. If tolerances loosen, output degrades. If inspection routines soften, defects compound.

No machine cares how motivated you feel. The system responds to inputs.

People are no different.

Teams drift the same way bearings do — gradually, predictably, under pressure. You don’t fix that with inspiration. You fix it with structure.

The chapter that challenged me most wasn’t about systems.

It was about identity.

Because if leadership isn’t personal, then your worth isn’t tied to short-term performance swings. Your value isn’t your heroics. Your job isn’t to be indispensable.

Your job is to make yourself structurally unnecessary.

That’s uncomfortable. Especially for high achievers. Especially for leaders who built their reputation on stepping in when things break.

But sustainable performance demands it.

These ideas weren’t built in theory. They were built from plants that struggled, standards that drifted, systems that got redesigned, teams that stabilized, and mistakes that cost real money. Lessons learned the expensive way.

Different companies. Same dynamics. Every time.

I don’t want you to feel inspired after reading it.

I want you to feel unsettled — in a productive way.

I want you to walk into your next meeting and ask: What signal are we sending?

I want you to catch drift earlier. Stop absorbing system failures personally. Design environments where performance holds — even when you step away.

Because that’s real leadership.

For years, I kept these notes privately. Sketches of patterns. Observations about signal and drift. Models that explained why the same failures kept repeating.

But eventually I realized: if we don’t name the mechanics, we keep repeating them.

So this book is my attempt to name them. Clearly. Without fluff. Without theatrics. Without blaming.

Leadership Isn’t Personal isn’t a promise that performance becomes easy. It’s a promise that it becomes understandable.

And once it’s understandable, it becomes designable. And once it’s designable, it becomes stable.

That’s the shift. From heroics to systems. From personality to structure. From stress to signal clarity.

If you’ve ever felt like you’re working harder than you should have to just to maintain standards — if you’ve ever suspected that strong people are being used to hide weak systems — if you’ve ever wondered why good intentions don’t reliably produce good outcomes — this book was written for you.

Subscribe to be notified when Leadership Isn’t Personal is released.

— Ivan