Anyone who’s spent years in maintenance learns to read data with an attention that, to someone outside the field, seems almost instinctive: a two-point drift in OEE, an MTTR that stretches out slowly but steadily, a failure pattern that changes shape before it even changes in number. These are signals an experienced manager spots before they become a serious problem. But reading data well isn’t enough — I learned that myself too, more than once, the hard way: by presenting it badly to the people who held the budget to fix the problem.
The paradox: reading data well doesn’t mean knowing how to share it
These are two different skills, and often inversely proportional. The better you get at interpreting a trend in maintenance data, the more “obvious” that trend becomes to you — and that very obviousness is the trap. A manager who immediately sees what a certain pattern means tends to assume the same pattern speaks for itself to someone looking at it for the first time, without the technical context to interpret it.
It doesn’t speak for itself. A chart that clearly tells a maintenance technician “we’re heading toward a structural failure, not an isolated event” is, to someone outside the department, just a line that ticks up a little. The data is the same. The meaning that comes across is completely different.
The fatal mistake: assuming it’s just as obvious to everyone else
This is the real mistake, the costly one. It’s not a technical mistake — the data is correct, the analysis is correct. It’s a communication mistake: thinking that a drift or a pattern read in the data is just as readable to anyone looking at it. It isn’t. Someone who doesn’t work with those numbers every day doesn’t have the same reference points to judge whether a value is normal, concerning, or urgent.
The result, when this mistake repeats, is always the same: the manager leaves the meeting convinced they clearly showed a serious problem, while on the other side what remains is the feeling of having seen just another technical chart, with no real urgency.
Whoever holds the budget is usually not technical
And it’s precisely these people who, almost always, have to be asked for the resources to fix the most serious problems. Whoever approves a budget for a major intervention — management, purchasing, finance — in most cases has no technical maintenance background, and shouldn’t need one: their job is to weigh risk, cost and priority against every other request they receive, not to interpret an MTBF.
Presenting these people the same data, in the same format, with the same language you’d use with a technical colleague, is the most common reason a budget request gets postponed, cut down, or simply misunderstood until the problem has already turned into an expensive breakdown — in other words, until it’s already too late to prevent it.
What a manager actually needs to do
The solution isn’t to stop using data — it’s to completely change how you carry it outside your own department.
- Translate the data into consequence, not just a number. Not “OEE dropped to 68%”, but “at this rate we’re losing the equivalent of X hours of production a month, worth €Y.” Whoever decides the budget thinks in costs and risks, not technical indicators.
- Show, don’t just list. A simple chart with a clear trend communicates in three seconds what a table of numbers doesn’t communicate in three minutes. Less technical detail, more visual evidence of where things are heading.
- Anticipate the question that’s coming anyway. “What happens if we do nothing now?” is the implicit question behind every budget request. A manager who answers it upfront — in terms of concrete risk, not theory — heads off the most common objection.
- Test the explanation on someone outside the trade, before the real meeting. If a non-technical colleague, hearing the same explanation, doesn’t understand where the problem is or why it’s urgent, that explanation isn’t ready for the meeting that matters.
This isn’t simplification for its own sake. It’s recognizing that technical skill and the ability to secure the resources to put it to good use are two different things — and that a manager who only masters the first one too often remains an excellent technician who never manages to get approved what they know is genuinely necessary.
In summary
The most common — and most costly — mistake a maintenance manager makes isn’t technical: it’s assuming that a drift or a pattern that’s clear in the data is just as clear to someone looking at it without the same background. Whoever controls the budget for the most serious problems rarely has technical skills, and needs to be spoken to in their language — risk, cost, consequence — not the language of your own indicators. Whoever learns to make that translation, not just to read the data well, stops losing the battles that matter most because of how they told them.