“I’ve been doing this for twenty years”: a young engineer and an experienced operator at one machine

The scene: charts meet experience at the machine

Kuba, a young process engineer, came to the line with a proposal to change the machine’s parameters. He brought charts and had already scheduled a start date for the tests. Zbigniew, an operator with twenty years’ experience, looked at the plan and said: “I’ve been doing this for twenty years. You’re not going to tell me how to set up this machine.”

“But the measurements show we’re losing time,” Kuba replied. “The measurements don’t show what happens after two hours of running,” Zbigniew countered. The engineer took this as resistance to change. The operator took the engineer’s words as a dismissal of practical experience. Nobody asked what conditions the measurements had taken into account.

Their manager had already heard two versions: “the operator is blocking improvements” and “the engineer is risking a breakdown”. In reality, nobody had yet agreed how to test the proposal safely or which criteria would be used to assess the results.

Kuba arrives on the shop floor with a ready-made schedule. Zbigniew doesn’t know whether he still has any say in the decision or is simply expected to carry out an instruction. The difference matters: consultation that takes place only after a date has been set can come across as a mere formality. As a result, the operator defends his experience instead of pointing to a specific condition that could invalidate the measurement results.

What really happened

Kuba brought data and a proposed improvement. Zbigniew drew attention to conditions that may not have occurred during the measurements. Both pieces of information can be valuable, but the conversation quickly turned into a dispute about competence. Saying “I’ve been doing this for twenty years” does not prove the operator is right on this particular issue, just as a chart does not prove that the model accounts for all production conditions. It is worth shifting the dispute away from “Who is smarter?” towards “How can we safely check which hypothesis matches reality?”

Behind “I’ve been doing this for twenty years” there may be an accurate observation, but also a fear of losing standing in the team. Behind Kuba’s haste there may be pressure to deliver improvements rather than any intention to disregard the operator. Neither motive should be assumed without talking it through. It is safer to ask, “What do we need to find out before we change the settings?” and only then to discuss any concerns about how you work together.

What the research says

Kahneman and Klein described the conditions under which experience can lead to accurate intuition: the environment must contain sufficiently regular patterns, and the person must have the opportunity to learn from reliable feedback. Length of service alone does not guarantee expertise, but that is no reason to dismiss years of observation. Similarly, a young engineer may have sound theoretical knowledge and measurement data, yet not know all the machine’s operating conditions. The engineer has the calculations; the operator has knowledge of unusual cases. You don’t have to regard the two as equivalent in every respect in order to include both perspectives when assessing the solution. In teamwork, it also matters how questions are asked – without making the other person look foolish.

Research on expert intuition does not show that an operator with long service is always right. Nor does it mean that new measurements are more reliable than every observation from the shop floor. The best approach is to test predictions: if Zbigniew is worried about problems after two hours, write down what symptoms he expects to see and how they can be verified. The conversation then gains a point of reference other than the reputations of the people involved.

How to approach it

Kuba might start: “I want to show you what came out of the data and check what’s missing from it. In what situations might the proposed setting not work?” Zbigniew might reply: “On a longer run, the material starts behaving differently. Let’s check that under test conditions.” Together with the person responsible for safety and process technology, they should agree the permitted scope of the trial, the parameters to be monitored and the conditions for stopping it. Experimenting on the machine outside the procedure is not acceptable. It may be useful to agree two written records: what the engineer’s model predicts and what deviation the operator expects. This makes it possible to check the result without retrospectively adjusting the success criteria to fit the position of whoever turned out to be right. After the test, it is best to discuss the result without any “I told you so”, even if one of the hypotheses is not confirmed.

Before the test, agree the range of settings, who is responsible for stopping the machine and how the results will be documented. If the change requires formal sign-off, don’t replace it with informal agreement at the workstation. After the test, asking “Who was right?” is not enough. You need to compare the data with real production conditions and check whether the result holds over time.

Two kinds of expertise, one conversation: an example of agreeing a test

Kuba might say: “From the measurements, I can see a way to shorten the cycle time. Before we start the trial, I’d like to check with you when these settings might fail.” Zbigniew might reply: “I see the biggest risk after a longer run, when the material heats up. Let’s test a run that covers that stage.” Statements like these don’t require either of them to back down from their position. They do require treating the other person’s knowledge as a possible complement to their own.

When the conversation slides back into judging competence, the manager can halt the dispute: “We’re not assessing your experience right now. We’re agreeing the hypothesis, how we’ll measure it and the conditions for stopping the trial.” Once the test is over, it is worth coming back to both of them: “What did the measurements confirm? What surprised us? What decision are we making, and why?” That way, nobody has to prove their worth by blocking the project.

How to combine shop-floor knowledge with engineers’ work

It is worth establishing a standard way of gathering operators’ observations before a change is implemented. This could be a short consultation at the machine, a list of boundary conditions or a joint risk review. The practitioner should be involved before the decision becomes irreversible. In turn, operators should be told the results of the tests so that their comments don’t disappear without a response.

Good collaboration also requires recognising different roles. The engineer may be responsible for the process model and the measurements, while the operator contributes knowledge of unusual situations. Safety and the approval of changes are the responsibility of the appropriate people designated in the procedures. When the criteria are transparent, ideas can be assessed without a battle between generations. Shared successes are worth discussing in a way that shows what both sides contributed.

A dispute between an experienced operator and a young engineer doesn’t have to end in a choice between length of service and data. You need to name the hypotheses, check the conditions under which the measurements were taken and test the change safely. Respect for both kinds of knowledge makes it possible to improve the way work is done without a fight over prestige.

How Empatyzer and Em can help

Kuba can describe his frustration to Em and ask for help rephrasing his message so that it doesn’t sound like a lecture aimed at an experienced operator. Zbigniew can prepare questions that bring out the practical risks without undermining the other person’s competence. When Empatyzer has the context of their working relationship, the tips help them better understand why one of them needs data and the other needs a concrete observation from the shop floor. Em does not confirm whether the parameter changes are technically correct. Em helps them hold a conversation in which respect for experience and openness to new solutions are no longer mutually exclusive.

Kuba can practise with Em how to ask about the limitations of the data, and Zbigniew how to present a risk without rejecting the whole idea. Their manager, in turn, can ask for a plan for a meeting at which both sides write down their hypotheses and the test criteria. Em will help choose language that keeps the proposed change from sounding like a judgement on the experienced employee’s worth. If Kuba is worried that asking for an opinion will be seen as calling his own preparation into question, Em can help him stay confident about the purpose of the test while making room for the operator’s arguments. Zbigniew can practise describing his observations without suggesting that his younger colleague understands nothing. After the trial, both of them will come back to the conversation with concrete results, which makes it easier to build trust ahead of future improvements.