Workplace conflict

“The machine’s down because nobody kept an eye on it”: production vs maintenance conflict

On this page

TL;DR: After a breakdown, production counts the time lost, while maintenance asks about earlier warning signs. Both questions matter, but it’s not worth starting by looking for the department to blame. First you need to reconstruct the sequence of events and check how information about the symptoms was passed on. Only then can you agree what to change in how faults are reported and how the two teams work together.

  • Don’t judge who is to blame before reconstructing how the fault developed and how it was reported.
  • Record who noticed the symptom, who they passed it on to and what was done next.
  • Keep getting the machine running again separate from analysing the causes of the stoppage.
  • Agree a clear reporting route and a way of confirming that warning signs have been received.

How does Empatyzer help you talk after a stoppage without mutual accusations?

Em helps prepare a conversation between production and maintenance in which both sides can separate facts from interpretations.

Features that will help you:

  • Talk to Em about a specific person: Preparing a conversation with the manager of the other department.
  • Talk to Em about your team: Naming different expectations and agreeing rules of cooperation.
  • Personalised micro-lessons: Practising feedback and resolving cross-functional conflicts.

The scene: a stopped line and two conflicting explanations

The line had stopped for the third time in two days. In front of the operators, the production manager said: “The machine’s down because maintenance didn’t keep an eye on it again.” A mechanic who had just arrived on the scene replied: “Nobody reported a problem until it was too late.”

An operator mentioned that he had heard an unusual noise that morning and told a colleague, but didn’t know whether he should raise a ticket. The mechanic had an entry in the system about a different fault. The production manager was worried about a delayed order, while the maintenance manager was facing a queue of unresolved tickets.

After the repair, both sides left the meeting convinced that the other was hiding mistakes. Nobody established when the symptom first appeared, who the information reached, what route the report took or what could be improved before the next stoppage.

The words spoken in front of the operators made the mechanic start defending his department before he had even had a chance to assess the fault. The operator, meanwhile, may have concluded that admitting he’d heard an unusual noise would make him the one held responsible. In a climate like this, the team loses the information it needs to prevent further stoppages. The conversation should give people back the chance to say “I saw a warning sign, but I didn’t know what to do”.

What really happened

For production, the stoppage is what matters most; for maintenance, the ticket queue and the limited number of mechanics available matter too. Each side is describing the same stoppage from a different point of view. The breakdown may have been caused by a technical fault, an inaccurate description of the symptom, a delayed report or several of these at once. Until that is established, “they didn’t keep an eye on it” and “you didn’t report it” are interpretations, not a diagnosis. A separate problem is the public accusation, which will make future cooperation harder. An operator who watched this exchange may not pass on an early warning of a malfunction next time if he’s afraid of being dragged into a dispute between two departments.

Three things need to be separated: the technical cause, the route the information took, and the decisions made under deadline pressure. The production manager may be right that the breakdown shouldn’t happen again, and the mechanic may be right that he didn’t receive a proper ticket. Both points remain incomplete if nobody knows which symptom could have been recognised earlier and who had the authority to stop the machine.

Making sense of it: what the research says

In research on teams, task conflict easily becomes intertwined with relationship conflict. A 2003 meta-analysis by De Dreu and Weingart found that both types of conflict were, on average, associated with poorer team performance, so you can’t assume that every heated argument about technical matters helps achieve better results. Research on debriefing, on the other hand, points to the benefits of jointly analysing an incident, provided the analysis is based on facts and leads to specific conclusions. It is not a substitute for a technical investigation into the causes of a breakdown.

Rather than applying general findings from conflict research directly to machine breakdowns, it’s worth treating them as a warning against escalation. Once the other side starts being called “irresponsible”, the conversation shifts from the machine’s parameters to defending reputations. At that point, even a sound technical idea can be rejected for relational reasons. A good debrief should make it possible to challenge hypotheses without belittling the people who put them forward.

How to approach it

Start the meeting by reconstructing the sequence of events together: the first symptom, how it was reported, the decision to keep the machine running or stop it, the intervention and the moment it was back in operation. For each item, note the fact, the source and any missing data. Then ask: “What should have reached the next person sooner, and in what form?” Instead of saying “maintenance let us down”, it’s better to say: “There was nothing in the system about the first symptom. Let’s agree at what point and how it should be logged.” Every agreed action should name a person responsible and a date for checking the result, not just a slogan like “better communication”. Also agree what an operator should do when they notice an unusual symptom but can’t yet describe it in technical terms. If people are afraid to report observations they’re unsure about, the problem will stay hidden, however good the ticketing system is.

If you don’t know the cause of the stoppage, say so clearly in the report. An operator’s guess and a mechanic’s finding are different kinds of information. Where safety is at risk, the relevant stop-work procedures apply, regardless of the production plan. Only once the hazard has been removed can you calmly discuss the quality of reports and the rules of cooperation.

What to say at the meeting after a stoppage

The production manager might open with: “The line was down for two hours today. I want to establish what we knew about the symptoms before it stopped and what was missing in the way information was passed on.” The maintenance manager replies: “Let’s check the entries in the system and ask the operator when he first heard the unusual noise.” This way both sides acknowledge the cost of the breakdown without prejudging its cause.

The operator might say: “I heard the sound change this morning. I told a colleague because I didn’t know whether it needed reporting.” He shouldn’t be met with an immediate accusation. It’s better to ask: “What information or rule was missing that would have told you what to do?” Only once the data has been gathered is it worth deciding whether someone skipped the applicable procedure or whether the procedure wasn’t clear enough.

Every ticket should have an owner and a response

A shared standard might require four pieces of information: a description of the symptom, when it occurred, where, and how urgent it is. The person reporting it should know where to send the information and how they will know it has been received. If a fault requires the machine to be stopped immediately, the procedure must specify the decision to be taken without waiting for a discussion between departments.

After a month, it’s worth checking the number of tickets, response times, cases where information was passed on only verbally, and recurring symptoms. Fewer arguments alone isn’t the measure of improvement. What matters more is whether information about malfunctions reaches the right people faster and whether both sides can agree on work priorities. That’s how you build cooperation without blurring responsibility.

After a machine stoppage, production and maintenance should reconstruct events together rather than trade accusations. Clear tickets, confirmation that they’ve been received and rules for stopping work help prevent a repeat. The technical causes need to be investigated, and the conversation should make that easier.

How Empatyzer and Em can help

Before the joint meeting, the managers can each talk to Em about what they actually know, what they’re assuming and which decisions matter to them. Em will help them prepare questions that don’t imply blame and a way of talking about the other department’s constraints. In the relationship context, Em can take into account different communication preferences, such as a need for detailed data or for a quick decision. Em doesn’t analyse the condition of the machine or replace the ticketing system. Em helps prepare a conversation after which production and maintenance can reconstruct the incident together and agree what they will change the next time information is handed over.

Em can help managers practise opening the joint meeting so that the first message is about facts and safety, not blame. The user can describe two conflicting positions and ask for a set of questions that will bring the missing information to light. Once the procedure has been agreed, it’s worth checking with Em whether the message for operators is simple and easy to follow. That way both sides go into the meeting with a list of questions rather than a ready-made accusation. Separately, you can practise your response to the line: “Your department has held everything up again.” Em will help formulate a reply that acknowledges the cost of the stoppage while directing attention to tickets, response times and the decisions that need to be made. This is also useful preparation before a conversation with the operator who noticed the first sign of a malfunction.

Sources

  1. De Dreu CKW; Weingart LR (2003). Task versus relationship conflict, team performance, and team member satisfaction: a meta-analysis. Journal of Applied Psychology. https://pubmed.ncbi.nlm.nih.gov/12940412/ 10.1037/0021-9010.88.4.741
  2. Tannenbaum SI; Cerasoli CP (2013). Do Team and Individual Debriefs Enhance Performance? A Meta-Analysis. Human Factors. https://pubmed.ncbi.nlm.nih.gov/23516804/ 10.1177/0018720812448394
  3. Edmondson AC (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly. https://journals.sagepub.com/doi/10.2307/2666999 10.2307/2666999