by Systems administrators are magical wizards that know everything and can make computers sing, dance, and do various other parlor tricks. As someone who carries the title, everyone assumes you can do the same. Whether it is a brand new application that no one has ever seen before, a telephone system that has nothing to do with computers, or a very old server running an OS where the vendor went out of business in the last century, you’re a systems administrator, you know all about it. And, for one of a various hundred or so possible reasons, you are afraid to let that image falter.
In our martial arts training, we are constantly told to know our limits, to acknowledge our limits, to stretch our limits, and when we train with someone, to tell them our limits. Knowing, acknowledging, stretching, and expressing our limits is useful for many reasons: it teaches us humility, it teaches us to seek assistance, it teaches us to overcome our limits, and perhaps most importantly, it prevents us getting hurt. If we don’t recognize our limits, we cannot improve beyond our limits. If we don’t stretch our limits, we may try to do something significantly beyond our ability and hurt ourselves or others. If we don’t express our limits, our partner may assume we know or can do more than we can, and may accidentally hurt us (or us hurt them).
Early in my martial arts training, I was struggling with my round house kicks. I was on a training bag practicing my kick when one of the senior instructors came over to me and asked what I was doing. I responded fairly non-committal that I was practicing my kick. He said “Well, if you need any help let me know” and walked away. A few days later, I was again practicing my round house kick and the same senior instructor asked me the same question. This time, I said I was having a problem with pulling my kick before I got solid contact and did he have any suggestions. He responded that he also had problems with his round house kick, and perhaps we could work together to figure out our problems. He showed me how I should pivot my standing foot and turn my hips to snap the kick out past the center line. While I’m certain he knew his problem, I was able to point out to him that he wasn’t pivoting properly on all his kicks.
When you are dealing with customers, they may _assume_ you know something about a certain technology. Unless you tell them that you’ve never dealt with that particular issue, they may feel that you aren’t supporting them properly or you may put a project time line at risk because they may assume a level of knowledge and capability that you don’t currently have. Very rarely will you find someone who actually _exects_ you to know any particular piece of knowledge (unless that really is what you do day to day). By explaining your limitations, they will gain a better understanding of what exactly to expect from you and will be able to make allowances.
Twice I had very similar incident with members of my team. Both were fairly senior people, but had absolutely no experience with some of the ancillary products and applications that we used. They were being asked to do things by their project teams that they didn’t know how to do. Both were trying to figure out how to do those things, sometimes escalating to the vendors for help, sometimes telling the project they were busy with other tasks, and sometimes trying to cover up by feigning ignorance of the specific task being assigned to them. This eventually bubbled up to me as them being unresponsive, not completing necessary tasks, and putting high visibility projects at significant risk. They told me the situation was so bad with the end customer that if I didn’t do something quickly, I’d be asked to remove them completely.
Remember, these were two different people, two different projects, two different times. With the first, when I spoke to him, he was unaware that anyone had any issues, he didn’t know what to do, and he was unwilling to ask for help. I counseled him on asking other team members for help, about telling the project or me when he didn’t know something, and on making sure he kept good communication and task lists. Nothing changed, and after another week, the project asked me to remove him. I had to pull one of my other engineers in to take over the project, clean up the issues, and get things back on track. He was able to do it, but only by working overtime and weekends, and it took another three weeks before the project manager was willing to move the project back from red status.
When I went to spoke the second one, he also was unaware there were significant issues. He said since he was the senior engineer on the project, he thought he was supposed to be the one to know everything and he was afraid of what people would think if he told them he didn’t know something. We spoke about acknowledging his limitations, about being sure to communicate properly with the rest of the project, and leveraging other team members (even if they weren’t on the particular project) to overcome his limits. Once we spoke to the project manager and the customer team, they were happy to rearrange some of the project work, and I was able to bring an extra resource onto the project to help out on the things he didn’t know. Some issues that had been high priority were able to be cleared up in a day, and the project was brought back on track.
In the first case, the engineer was unwilling to embrace him limits and caused longer term problems. In the second case, the engineer was willing to embrace him limits and we were able to work together to resolve the problems.
Oh, and I still pull my round house, but by working with the instructor, I’ve figured out it isn’t my form that is the problem. It’s related to an old injury which needs additional physical therapy (and overcoming a mental block that the kick won’t hurt the injury).