experience is beginning to show that a few sloppy computer techs might be finding employment in the ranks. It sounds cranky and cynical coming from an old tech…and yes, this’s only the opinion of one person…but in a world where virtually everything is done on computers nowadays, marginal computer support really does cause many people to suffer. The world of IT should never be taken lightly and there’s a no greater sign of a marginally conceived or executed solution than the struggles of the end-users using it.
People who work on computers all day long get to know them on a personal level. Every little glitch, each sticky part, and anything slow will be noticeable and remembered. The company’s employees should be able to remain focused on the work they’re doing and not on the tools they’re doing it with. Any small operational defect will slowly build into a major source of frustration, or worse, into invisible operational overhead that costs the company in ways that management can’t easily see. As a computer tech, you really do have this much impact on the life of everyone around you.
Before covering the characteristics that’ll lead you on a path to achieving excellence in your job, it may help to first outline the common characteristics that lead to something less. There are many types of bad behavior in the IT world, but nine in particular seem to be the most prevalent. If you find yourself developing one of these nine characteristics in your daily work ethic, you should look in the mirror the very next morning and think hard about ways you can become better at what you do for a living.
The Nine Bad Tech Types are:
Whiners
Too Busies
Experimenters
Constant Rookies
Divers
Know-it-alls
Fraidy-cats
Nerds
Breathless Wonders
These labels may seem a bit trite, but each is an accurate description of the person involved. In each case the tech isn’t only performing in a way that’s detrimental to him or herself, but also in ways that can slow their team down, create wrinkles that shouldn’t exist in an otherwise good project, or even affect client relations. If you recog-nize any of these traits in yourself it would be a good idea to take a contemplative step back and review the approach you’ve taken so far in your career.
Whiners
Whining is done by techs who want others to believe that something bad isn’t their fault. The lack of desire to accept responsibility for the occasional negative outcome is a common trait in all people, but the IT whiner brings this trait into the LAN room. The excuses can be routine, too. Either they were overworked, under-informed, or misguided in some way that made it impossible for them to get the job done right.
Even when it really isn’t your fault, you should never whine. Taking responsibility when something isn’t right (even when others know it wasn’t truly your fault), is a great way to build credibility. It makes you the tech who steps up and is accountable for the jobs you take part in. This isn’t to say that you should volunteer to be a sacrificial lamb whenever someone else screws up. What it means is that how well you can carry yourself when working through a tough spot defines how much everyone else can trust you in the long run. Whining that something wasn’t your fault when everyone knows it was is a fast way to lose the trust of others. No matter how the problem came about, if you were the responsible party when it happened, then it was your fault. Whining will only make things worse, not better.
Moreover, there may be times when you have to step up and be accountable even if the problems aren’t of your own making. Most often this happens when taking over a system from someone else who didn’t design, implement, or maintain it well. When this happens, there’s a formula for establishing a timeframe to make things right before those hand-me-down problems start making you look bad too. The timeframe is usually about 50% more time than it took for the other guy to mishandle things in the first place.
Obviously, this formula isn’t scientifically proven; it’s just how things always seem to work out. If it was a bad job done by another tech over a two hour period, you have your own two hours plus one extra hour of leeway to make it right again before people start to see you as part of the problem, too. After that, anything that goes wrong is on you and not the other tech. Whining won’t change this formula so don’t bother trying. Just be accountable and work hard to make things right until the job is done. That’s more than the other tech did before you took over so you’ll still come out ahead even if you don’t feel happy about it. This formula scales out to days, weeks, and even months for more complicated systems, but the math always remains the same.
Multiple system networks change this math somewhat by making it more calendar-based. There’s no paradigm for measuring how long it takes to fix many broken systems at the same time. However, if you’re taking over an entire network with big problems then the common rule of thumb is you have a total of nine months maximum to make everything right. Whether it’s human nature responding to the seasons of the typical fiscal year or the time window for practicable performance, that amount of allowed time remains constraint in virtually every situation. After that, your coworkers will begin to suspect that the problems are coming from you and not your predecessor. His/her legacy will be your legacy at that point; therefore, if the problems are not entirely fixed with the accepted timeframe, you should at least have a clearly defined plan that demonstrates how and when things will be made right. You can use the plan to show progress to management and coworkers when they question how the repairs are going. You only have so much time to make things right, so if you’re in a bad situation like this, don’t waste time whining about it. Instead, it’s best to just get to work and stay focused on the task until the appropriate results are finally achieved. Some ways to do this are:
Review and document everything in your own words and don’t rely on your predecessor’s documentation. It was likely written using the same poor performance level that created the marginal system(s) in the first place. Redoing the old documentation not only helps to clarify how the system(s) should properly work, it also provides a better foundation to affect change. Doing this step creates a basis for further understanding of the company’s overall operation. Digging in right away to work on understanding all aspects of the network from the start will allow you to modify items to your own liking much sooner than if you’d just sat and pouted.
Reverse engineer anything you don’t understand. Don’t allow any left-over mysteries to linger around like ghosts in the machine. Just because you’re able get something working the way the end-users are used to, doesn’t mean you can fix it if it breaks again in the future. While reverse engineering can be tedious, especially when you’re busy acclimating to your new job status, it’s still better to do this as soon as possible. Otherwise, any changes you make to the system(s) could interact with your predecessor’s legacy problems in ways you missed during the initial planning.
Prepare good arguments to give to management for funding any needed improvements. When it comes to good arguments, the only one that matters is the one that involves saving money. If you can’t cost justify the expense, then don’t even bother asking for it. The old adage, “if it ain’t broke, don’t fix it” will be applied every time by stingy management. If you know that the system is seriously dysfunctional and must be fixed immediately, still don’t whine. In fact, don’t even let a high note of frustration enter into your voice. Just go back to the drawing board and come up with a better…meaning more money oriented…argument to present to management. The importance of good communication skills will be mentioned frequently in this
