Tech Manager—Tell Me More
I have written before about expecting things…too little, too much, the wrong things… The too little/too much part got me thinking…what about the information you give to others when there is a problem, and you fix it?
Ever go to the doctor and he pokes and tests and then says take these pills and everything will be fine. No more info than that? You are puzzled when they share so little that you don’t even know what might be the cause or what was ruled out. They just silently go about their business and in their bedside manner they treat you like a slab of meat.
Have you ever fixed something and told someone to try again – it works, and you just say okay, good, and then walk away. They are left puzzled about the initial problem and what they can do to avoid it in the future. They can work now, but they may have little understanding of the nature of the troubles.
When people have issues, they want answers. They need to get back to work. They want their troubles fixed now, but they also want to know what caused it to happen. When you provide solutions to problems, make sure they know more than when you walked up. You need to tell them more.
Providing Too Little
When you go through the troubleshooting process, you may ponder many possible causes, then uncover a few probable causes and finally one root cause and then the fix. So, when you finally get to that fix, you may be tempted to not really tell them much about your process or possible avoidance methods for the future. They are left with a feeling of relief, “the problem is gone,” but not knowing what happened, “but I have no idea what caused it.” You need to let them know what happened, the cause and the fix.
Providing Too Much
Troubleshooting can uncover a lot of information as you run through scenarios, possible solutions and final resolution. Some may be tempted to share all of that info with the end user. They start tumbling out words and the user’s eyes glaze over. The user tilts their head in confusion and soon just wants to leave. The barrage of words overwhelms their ability to take it all in. They end up not knowing what started or ended their troubles. Others may not even care what was wrong and how it was fixed, let alone how they may have contributed to the issue. They just want to get back to work.
Providing it in the Wrong Setting
I have seen support staff return to the end user and tell the story of the repair in a group setting. They do it in person or via group chats or virtual meetings with many who were not impacted by the same issue. They may not intend to do this, but are asked by someone what the issue was. When asked, you need to answer, but it should be measured. The group wants to hear the details and the support staff launch into a lengthy tale of wrongs righted. You should avoid sharing specific causes and fixes with non-involved users because they could attempt to do their own diagnosis and attempt a fix in the future. They apply the corrective that you shared in the past to their current situation. It may not correct anything and may actually make the problem worse.
Providing the Wrong Information
We have all seen it before…it was user error that caused the problem. It was something that the staff did wrong and they got tied up in a knot. What percentage of your fixes involve user error? I would say a good amount. Ten, twenty, thirty percent…more? If it gets too high, it may be time to do some training. Your staff may not know the right and wrong way to use the tools. But don’t sugar coat your fix and NOT tell them when they did something wrong. I will talk about how to gently help them improve, but certainly you do not want to tell them that they did nothing wrong when they did. Don’t tell them it was another issue or provide some vague reason, like a server/network or software glitch.
Providing a Good Balance
Now we move on to a suggested way of sharing info. Just tell them the truth. Be honest, brief and relevant. Let them know what caused the problem and what fixed it.
Let them know the root cause. Even if it was something you did, or did not do, that impacted them. If you forgot to grant permissions to files or features, let them know. If you changed a setting and did not realize that others would be impacted, apologize and let them know. Give them a simple easy to understand explanation. Use little to no technical jargon that they do not understand or might misunderstand. If it was something that another person did inadvertently, explain that and do not blame or disrespect the other person. When the cause was user error, couch it in nice terms “Maybe a better way to do that is…” or “What might have prevented that was not doing…” No need to insult them. And don’t just walk away grumbling about their lack of know-how. Just a gentle corrective might go a long way.
Let them know how you fixed it. Again, keep it brief. Explain the changes made or correctives you applied and move on. If their eyes glaze over, then cut your explanation short. Don’t provide too much info if they couldn’t care less. If it is something they need to correct, explain it in simple details and have them make the changes. Watch them do it, if you can, and verify that the fix is applied and worked.
Check back later. As you walk by their area later in the day or the next day, stop by and just ask “Still working okay for you?” It allows them to give a quick “yes” and move on, or say thanks. It also reminds them who helped them and they can seek you out again. “If you have any other problems with it, let me know.” It also allows them an opportunity to ask another question or tell you about another trouble.
Sharing what you know is key to good support efforts. If you have heard me speak at an event, I usually end my presentations with a final slide that says “Pass It On”. That is my motto. Share what you know. When you fix a problem, let people know what made it happen and how to avoid it. Do it in a measured way. Be honest, brief and relevant and folks will appreciate your support.
