Every implementation has that meeting where someone crosses their arms and says: "This system is slow."
The manager takes a note. IT opens a ticket. The vendor measures the screen's response time: two seconds, within the contract.
The next week, the same sentence comes back, word for word, from the same person.
Because nobody answered what they were really saying.
Last week we talked about the small wins that keep someone using the system. Today is the other side of the coin: what to do with the complaint — and why treating it only as a technical problem is the fastest way to lose the person.
🔧 In maintenance, we learned not to ask twice
Our field has a healthy kind of pride: we fix things. A problem shows up, we go straight to the solution. The pump vibrates, replace the bearing. The panel trips, measure, find it, fix it.
On the shop floor, that reflex is a virtue. In a conversation about a new system, it becomes a trap.
👉 If you treat every complaint as a defect, you fix the screen and lose the person.
There's also the cultural side. In a lot of plants, technicians learned early that saying "I don't know," "I'm afraid of getting it wrong," or "that left me exposed" comes at a high price. But "this system is useless" is acceptable. It's technical, it's impersonal, nobody walks out of the conversation looking smaller.
In thirty years I've heard plenty of complaints about systems, from both sides of the table — as a manager receiving the tool and as the one delivering it. Very few were about the button.
👉 A technical complaint is the socially acceptable way to voice a discomfort that has no name on the plant floor.
🧠 The sentence you hear is a summary of the one that stayed inside
When people speak, they hand you a compressed version of what they're living through. What comes out is generalized, with pieces deleted: "it's slow," "it's confusing," "it doesn't work for us." What was left out is exactly what matters.
"Slow" compared to what? To paper, which they filled out at their own pace, with nobody watching? "Confusing" for whom? For someone who never used a computer at work and now makes mistakes in front of the intern? "It doesn't fit our reality" — which part of the reality? The part nobody asked them about before choosing the system?
👉 A good question undoes a generalization. A good answer, given too early, confirms it.
There's a second principle that changes how you listen: behind almost every behavior there is a legitimate intention. The person complaining is trying to protect something — their time, their competence, their autonomy, their place in the group.
The map I see most often:
- "It's slow" → now my time is being measured, and I don't know by whom.
- "It's confusing" → I'm afraid of looking incompetent.
- "It doesn't fit our reality" → nobody asked me anything.
- "Paper was faster" → on paper, the information was mine.
- "That's an office thing" → I don't feel part of this.
And one detail that flips the reading: complaining takes effort. Whoever complains is still spending energy on the system. They still expect it to work.
👉 You don't have to agree with the complaint. You have to find out what it's protecting.
⚠️ What happens when a complaint only gets a technical answer
The signs show up in sequence, and they're almost always read as a software problem:
- The ticket closes and the sentence comes back. The screen got faster; the discomfort stayed the same.
- The complaint changes subject. You fix the slowness, now it's the layout. You fix the layout, now it's the phone. When the reason changes and the conclusion doesn't, the reason was never the reason.
- The person who complained stops complaining — and stops using it. Silence after an unresolved complaint isn't adoption. It's giving up. The silent resistance we talked about in #66 almost always starts here.
- The manager becomes the system's defense attorney. Every conversation turns into a defense of the vendor, and the team concludes the manager chose the tool over the team.
- The legitimate complaint gets lost along the way. Sometimes the screen really is bad for that use. If you don't listen to the human side, you also stop seeing the technical side.
👉 An ignored complaint doesn't go away. It changes shape: first it becomes silence, then it becomes window-dressing data.
🛠 What the system can solve — and what stays with you
From my side of the table, frankly: sometimes the complaint really is about the system. A workflow designed for the office and not for the shift, permissions that block the people who need to work, master data set up without listening to the people who use it. That happens, and fixing it is the obligation of whoever delivers the software.
In Manusis4, a good part of this can be adjusted in configuration, without waiting for a new release: approval workflows, group permissions, and master data shaped to the reality of each plant. The mobile app works with no signal and accepts photos and voice, which clears away a lot of complaints that, deep down, were "I don't have time to type." And when a request is genuinely good, it becomes a product improvement — a good share of Manusis4's improvements were born from a customer complaint that was listened to well.
What the system doesn't do is listen. No software notices that "it's slow" meant "I'm embarrassed." No update gives someone back the feeling of having been consulted.
👉 Configuration fixes the screen. Listening fixes the person. An implementation that works needs both.
💡 Five moves to hear what's underneath
- Say thank you before you explain. "Thanks for bringing it up." The first technical explanation, given on impulse, closes the door the person just opened.
- Ask for specifics. "Slow on which screen? Doing what? At what time of day?" The generalization falls apart in the example — and sometimes a real problem shows up that nobody had seen.
- Ask about before. "How did you do this before the system?" The answer shows what they feel they lost: time, autonomy, recognition.
- Separate what's about the screen from what's about people. Screen problems go to whoever configures the system, with a deadline and a follow-up. People's discomfort stays with you, in a one-on-one conversation, away from an audience.
- Come back with an answer. A complaint that is heard and then forgotten teaches people that complaining is pointless. Come back within a week, even if it's to say "this isn't going to change, and here's why".
👉 People who feel heard will accept even a "no." People who only get answers will reject even a "yes."
🧠 This week's reprogramming
Think back to the last complaint about the system you heard from your team. Now think back to the first sentence you said in reply.
If it was an explanation, you answered the screen. The person is still waiting.
Those who complain still believe. Those who have given up just agree.
This week, take one complaint about the system and ask three questions before giving any explanation. Notice what comes up on the third.
📣 That wraps up Block 10
Five weeks on the same point: the first login, the ambassadors, the "yes" that never turns into use, the small wins and, today, the complaint. If there's one thread running through them, it's this: no team adopts a system. People do, one at a time, each with their own fear.
Next week we open Block 11 and turn the camera to the other side of the table: the leader.
👉 There is a day when a manager realizes the team wasn't following them — it was afraid of them. #69 is about that day, and about what changes after it.
See you then.