Tech Manager
by: Mark Kiker
Assume it’s Your Fault W
hen 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…
16
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
AUGIWorld Magazine | September 2021 augi.com
