What is firefighting culture in maintenance — and how do you stop it?

Every day starts with urgency. The schedule changes constantly. Lower-priority work keeps slipping. Improvement initiatives begin and quietly disappear again. Planners spend their days reacting instead of controlling. The same overdue work keeps returning in different forms.

And over time, urgency slowly becomes the organisation's default operating mode.

This is firefighting culture.

It exists in some form at almost every heavy asset site.

And most organisations struggle to escape it because they misdiagnose the root cause.

The issue is usually not:

• laziness
• lack of discipline
• unwillingness
• or lack of technical competence

Most maintenance teams already know what should happen operationally.

The real problem is that urgent work consistently beats planned work for structural reasons.

And once that cycle becomes normal, the entire maintenance system slowly reorganises itself around urgency.

How you recognise firefighting culture

You can often recognise firefighting culture without looking at a single KPI.

The signals show up operationally everywhere.

Priorities stop meaning what they officially mean

Operations may know a notification is not truly: Priority 1 or Priority 2.

But they also know that if they assign: Priority 3, the work may never happen in time.

So they intentionally escalate the priority simply to get execution attention.

Eventually the priority system stops reflecting: actual operational criticality

and starts reflecting: "what do we need to mark this as so somebody actually executes it?"

At that point, the prioritisation model itself has already broken.

Older work quietly loses against louder work

Operationally, a Priority 3 overdue for weeks may now represent far more risk than a Priority 2 raised yesterday.

But firefighting environments rarely behave that way.

Instead:

• whoever escalates hardest wins
• whoever shouts loudest gets scheduled
• whatever hurts most today gets attention first

Meanwhile, lower-priority work slowly waits itself into becoming tomorrow's urgent work.

Spare-part behaviour changes

In firefighting environments, teams often stop trusting spare-part systems operationally.

Searching the warehouse takes time. Validating stock quality takes time. Finding correct material references takes time.

Under constant urgency, ordering new material directly from vendors often feels operationally faster than navigating unreliable spare structures.

Even when inventory already exists somewhere inside the plant.

That creates:

• unnecessary spend
• duplicate material
• inventory growth
• planning inefficiency

But operationally, the behaviour makes sense inside a firefighting environment.

Lower-priority work escalates through delay

This is one of the clearest signals.

Workorders initially created as: Priority 3 or Priority 4

keep slipping repeatedly because urgent work continuously interrupts them.

Eventually the underlying condition worsens enough that: the exact same issue returns as: Priority 1 or Priority 2.

Not because the original assessment was wrong.

Because the organisation never created enough operational space to execute the lower-priority work before escalation happened.

This is not random disorganisation.

It is a maintenance system structurally adapting itself around urgency.

How firefighting culture actually forms

Firefighting culture usually develops slowly over years.

Two structural conditions almost always exist underneath it.

The process either does not exist operationally — or it is not realistically executable

Most sites already have:

• maintenance processes
• workflows
• procedures
• planning structures

on paper.

But operationally:

• parts of the process are unclear
• parts create friction
• parts are bypassed under pressure
• parts are impossible to sustain consistently

And eventually the organisation develops a parallel operational reality underneath the official process.

The second condition is lack of operational visibility

This usually appears in three forms simultaneously.

The organisation does not fully know

• what needs action
• what changed
• what slipped
• why execution failed
• what should happen next

Even when the information technically exists somewhere in the ERP system, it often does not surface itself operationally.

The organisation has no time to manually discover everything

Finding answers often requires:

• searching ERP transactions
• opening workorders manually
• reading longtext
• checking statuses
• reconstructing timelines
• comparing multiple systems

Under operational pressure, this becomes impossible at scale.

The system provides no passive awareness

This is one of the most important points.

At many sites, nothing actively tells the planner:

• this vendor never responded
• this technician added a note
• this overdue item is now escalating
• this workorder became stale
• this prerequisite still is not ready

The planner only discovers those things if he actively searches for them.

And under firefighting conditions, people only have enough time to chase what already feels urgent.

The WhatsApp comparison

A simple thought experiment explains this problem extremely clearly.

Imagine WhatsApp worked like many maintenance ERP systems.

No notifications. No sorting by recent activity. No unread indicators. No prioritisation.

To discover whether anything important happened, you would need to manually open every conversation every day.

Operationally, what would happen?

You would:

• forget conversations
• miss important messages
• prioritise only urgent people
• react late constantly
• spend enormous time searching manually

That is essentially how many planners already work.

The information exists. But the system does not surface what matters at the right moment.

So planners naturally chase: whatever already feels urgent.

Everything else quietly accumulates underneath.

Until eventually: the non-urgent work becomes urgent too.

How the loop compounds over time

Once firefighting conditions exist, the loop starts reinforcing itself.

Backlogs grow. Overdues grow. Lower-priority work keeps slipping. Slipping work escalates into higher priorities. Urgent work consumes more planner attention. Administrative cleanup gets delayed. The backlog becomes polluted. Visibility becomes worse. Planning quality drops further.

And eventually, the organisation spends more and more energy reacting to symptoms instead of controlling the system underneath them.

By the time leadership formally calls it: "firefighting culture"

the operational patterns are usually already deeply embedded.

Deeper read: Why are maintenance backlogs always polluted? — on how this exact loop produces backlog pollution as a structural byproduct, and why the pollution then makes firefighting harder to escape.

Why escaping firefighting culture is so difficult

Most organisations try to escape firefighting culture by asking the team to do more.

For example:

• follow the process better
• improve discipline
• update statuses faster
• schedule more consistently
• document work better
• improve planning quality

But operationally, the team is usually already overloaded.

That is the key problem.

For example:

Almost every organisation knows backlog cleanup matters.

And almost every organisation struggles to sustain it.

Not because planners disagree with clean backlogs.

But because the planner attempting cleanup gets interrupted continuously by:

• urgent breakdowns
• missing materials
• vendor issues
• operational escalations
• production requests

And after each interruption, the ERP system provides almost no meaningful mechanism for resuming backlog review cleanly.

The same pattern exists in scheduling.

Primavera-level scheduling often becomes too heavy for daily maintenance. ERP scheduling visibility is too weak. Excel schedules drift away from reality.

So many maintenance organisations stop truly scheduling operationally.

Instead, they simply execute: whatever work happens to become ready first.

That is a major difference.

Controlled maintenance means: making the right work ready for execution.

Firefighting maintenance means: executing whatever happens to be executable under pressure.

Deeper read: Why your maintenance schedule isn't driving execution — on why the schedule slowly becomes a representation of work rather than the mechanism actually driving it.

And even when planners know exactly what should happen next, another issue appears:

The organisation often cannot clearly see why work was not ready.

The explanations become generic:

• production did not release
• materials unavailable
• contractor unavailable

Those explanations are often technically true.

But underneath them usually sit smaller operational failures nobody saw in time.

For example:

Material was "late."

But the real root cause was: the vendor never returned the quotation, which delayed PR creation by five weeks, even though actual material lead time was only five days.

That is the kind of hidden operational delay that creates firefighting structurally.

What usually does not work

Once organisations understand they are firefighting, they often attempt predictable solutions.

Most only partially help because they still ask more from the already overloaded team.

Process redesign

A redesigned process layered on top of the same operational friction rarely survives.

If the organisation does not remove:

• chasing
• searching
• manual coordination
• workflow overload

the process eventually collapses back into urgency behaviour.

Training

Most teams already know more than leadership assumes.

Training rarely solves:

• operational overload
• hidden signals
• ERP friction
• workflow interruptions

Restructuring

Changing reporting lines or role structures does not automatically reduce the amount of operational chasing the organisation still requires.

More dashboards

Dashboards help visibility.

But if planners still need to manually extract operational meaning from ERP transactions all day, dashboards alone do not change the workflow itself.

Hiring more planners

This often creates temporary relief.

But if the underlying operational system remains unchanged, the new planners eventually get trapped in the same reactive structure.

What actually works

The first real shift happens when organisations stop asking: "How do we make people work harder?"

And start asking: "What operational work should the system itself be helping with?"

The highest-leverage improvements usually come from:

• reducing manual searching
• reducing administrative friction
• surfacing operational signals automatically
• simplifying execution follow-up
• making priorities visible earlier
• giving planners time back

Because once planners regain operational space, entirely different behaviour becomes possible.

Now they can:

• proactively prepare work
• walk down jobs before scheduling
• verify prerequisites
• review lower-priority work before escalation
• clean backlog continuously
• follow the process properly

Not because discipline suddenly improved.

Because the operational environment finally supports the behaviour.

The first practical step

The most practical first step is usually: reduce the amount of operational searching planners must do manually.

Most organisations already know which questions planners repeatedly investigate:

• has material arrived?
• did the technician update the workorder?
• is the vendor responding?
• is this work technically complete?
• did this overdue item change status?

Those signals should come to the planner automatically instead of requiring constant ERP searching.

That is where firefighting culture usually begins reversing.

Not because urgency disappears overnight.

But because the organisation finally regains enough operational visibility and capacity to start controlling work instead of endlessly reacting to it.

Deeper read: Maintenance maturity: from firefighting to control — how firefighting culture sits at the top of the maturity curve, and why advanced maintenance investments fail when this layer is broken.