Tech Manager—Assume it’s Your Fault
When something goes wrong with a design file, people come running to you. They ask for help. You provide it. That is the way it works. Supporting end users is one of your main tasks. When people come running, you go into troubleshooting mode and start asking a lot of questions. You may get to the root of the problem really quick and get them back on track, but other times the problem runs deeper than a quick fix.
When troubles take longer to fix, I go beyond question. This article is not about questions, it is about attitude. Some support staff want to place blame or deflect blame. They want to see what “others” have done that caused the trouble. It may very well be that “someone else” has created this problem, but I usually do not start with that perspective. Here is where I suggest you start…
Assume it’s your fault
Yep, that is where I start. I think about anything that I might have done that caused others to have problems. I know that when things are changed, (i.e. configs, data sets, libraries, families) it can cause what appears to be unrelated problems. It may take a while for them to appear and it may not look like it is related to their issues, but I suggest you think about what you have done first and eliminate that as a suspected cause. I have had many people tell me that after I changed something totally unrelated, they think it was making their problems arise. “You know that plotter you just replaced on the third floor, well it made the coffee maker in the break room no longer work”, (I am kidding, but they try to connect things that are not associated).
It is so easy to think that others have caused the derailments. You should not start with that. You should start with yourself and the things that you have done. Then you can move on to other things, but first look to your own hands as a probable cause.
Think about everything you changed or updated. Check everything you did recently. Was it a week or even a month ago? It still might impact projects that finally start using what you created or adjusted. Just think for a while about the recent past and how it might disturb current events. It might not be something you just changed, but it is worth thinking about before you think about others.
When what you have done is in doubt, double check. Ask others to verify that you did it right. We all get it wrong sometimes. Having someone else look over your work is a good way to get a fresh set of eyes and new ideas into the mix. They may notice something that you overlooked; like, some slight adjustment that needs to be done. They may just ask, “Why did you do it that way?” Which can send your thoughts down another road, and you might come up with the fix. Let others help.
Put it back the way it was. If you can turn back the clock and remove the adjustments to see if that fixes the current issue. If it does, then you have some work to do. If removing the changes does not fix the issue, then you can move on to other things. And if you can’t roll back the clock, then make sure that in the future, you do have a way to “go back” to a prior version or state (like a backup or copy of edited files).
If it was you, admit it. It is easy to deflect blame by ducking and jiving, or tossing out “tech jargon” that the end user does not understand. If your changes caused a problem, just admit it. Tell them that you did not know it would cause the issue and apologize. Offer to help make up lost time by lending a hand. Let them know that you will be more cautious next time and do a little more homework.
Own it till it’s fixed
Don’t pass it off to others. When you have eliminated yourself as the cause of an issue, don’t just leave it to others. What more can you do? What more should you do? You are the support person that others depend on. Don’t take an attitude of it being, “Not my problem anymore”. Stick with it until it is fixed. Others may help you figure things out, but you need to stay involved, which leads to the next attitude.
Stay with it. Once you are involved with a problem, own it until the end. Others may actually take on the problem, but you still need to circle back and verify that it was all working when others are involved. Let’s say that you find out that it was a network problem and not a file problem when a model won’t update or open. You bring in the network person and they take the problem on. They work and get it fixed. When it is back up and running, check in with the end user to verify that everything is okay. Also check with the network team to find out the root cause and what it took to fix it. If it comes up again and you know the cause/fix, you might recognize it.
It may not take a long time to think through what you have been doing lately and realize that the problem you have now is unique and not connected to anything you have done. But something may have changed even if it was not your doing. So now you can move on to other troubleshooting techniques to define the cause and develop corrective measures. But at the start, make sure you review how anything that you did might have contributed to other people’s problems.
