Читать книгу Excellence in It: - Warren C. Zabloudil - Страница 7
ОглавлениеCHAPTER TWO
Bad Habits
No matter how life-defining a career may be, it often follows a less glamorous path than the one dreamed of in childhood. A person can aspire to be a doctor but leave medical school to end up in advertising. Another can learn to work on fast cars from a favorite uncle only to become a school teacher instead of a famous race car driver. Still another might join the army for a temporary stint fresh out of high school and end up retiring decades later as a gray haired officer with a great military legacy. Any path that a person stumbles on can become a life calling, even if it was never their original intention.
This’s how it has always been. So it’s not surprising that some people don’t care as much as they should about the quality of work they do. They show up at their place of employment and sit in their cubicle, stand at their station, walk their beat, or whatever, and move through their day one minute after the next, never giving any thought to how they can improve their performance or how their performance affects others around them.
As a computer professional you can never fall into that mindset, even if you never dreamed of working with computers when you were a kid. It’s an old adage that there’s no such thing as a bad job, only jobs that are badly done. Certainly the IT world is full of badly done jobs. Some IT service providers seem to be getting more adept at disappointing their customers every day. People regularly complain that calls to customer service mean confusing voice menus, long hold times, inconsiderate staff, marginal repairs, and so on. Nevertheless, just because badly done jobs seem to exist all around you, it’s no excuse for you to allow poor performance to become part of your career too.
Something you should keep in mind is that great buildings are never built by as many people as they eventually occupy. A few well motivated people can make a big difference in the lives of a much bigger group of people around them. It’s an important truth that anyone who rises a bit higher in their daily job can help raise their co-workers’ efforts a bit too. In any economy, old or new, every little bit helps. The idea is to accept the career path you’re on (even if it wasn’t your original choice) and stay true to it by rising to the calling it presents, even if others around you haven’t. This’s where the approach you take when working on computers starts to matter.
As an IT tech, you have a workplace impact that extends far beyond your desk. How well you do your job affects the lives of all the people working around you. Being a tech is not an assembly line kind of job where you only affect a small part of a whole. You can directly impact the careers of everyone else in your company by how well (or how badly) you handle your own career. Everything you design, everything you build, everything you maintain and upgrade…in fact, virtually everything you touch in your working environment…will be used by everyone else in your company to earn their living. This is not a small responsibility.
Your coworkers’ ability to make their mortgage payments, their car payments, their kid’s tuition payments, and even get that oh-so-rare Christmas bonus, can be immediately impacted by how well you do your job in the IT department. If you’ve ended up choosing to work on computers for a career, what you’ve really chosen is to help provide and maintain a large part of the foundation on which the world operates. Sure this may seem an overstatement at first glance, but it’s the flat truth. You must never forget that how well you do your job in IT on a daily basis determines how well your coworkers will be able to do their jobs on a daily basis too.
Unfortunately, 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 book, but suffice it to say, it’s not your boss’s fault if you weren’t able to convince him the expense is worthwhile.
You must remember that a system’s efficiency is one of the hardest things for companies to quantify. While they can easily add up the cost of every pen and box of staples in the office supply room, they cannot easily compute the financial cost of the difficulty involved with employees completing routine tasks with their computers. All those intangibles like morale, fatigue, and overall productivity must be clearly included in your argument when you’re explaining the true value of your request to your boss. You also must be thoughtful with how you present the subject of spending money when making your case to management. You can’t just toss in comments haphazardly when the boss isn’t expecting them. Like it or not, there’s a certain amount of salesmanship involved.
For instance, a good move when opening your argument is to use an old sales trick called Sign Posting. Salesmen have been using this trick for years. It’s where they tell the buyer ahead of time how they’re going to sell them something before they do it. It’s meant to put the buyer at ease so they’re less guarded when the salesman starts the pitch. For example a car dealer might say “I’m gonna sell you this car today and I’ll tell you how I’m gonna do it: by showing you that we not only have the best cars here at So-and-So Motors, we have the best prices too.” Of course you would use more appropriate wording for your work environment. The thing to remember is that if you’re in the boss’s office for a quick visit, passing them in the hallway, or even chatting in the cafeteria, you want to avoid ambushing them with a request out of the blue for something that’ll cost money. Some planning ahead with sign-posting first will go a long way to not being rejected out of hand.
There are other approaches you can try too. Instead of using sign posting like a car salesman, you could also try something more subtle, perhaps some little hints you throw into conversations with management as an aside while you’re discussing something completely different. Do it casually and smoothly enough every now and then and you may actually find them reminding you to pursue the upgrade as if it were their idea from the beginning. Regardless of which approach you use to sharpen your argument, be sure to always include the notion that the improvements being asked for will compensate for the costs.
At this point the whiner may complain, “Look, I’m a computer technician. Why should I have to learn about car salesmanship? It won’t make me better at fixing computers.” To which the reply is, “Get with the program.” It’s part of every IT professional’s job, regardless of how tiresome it may be. In fact, in a world where every system in production today will be obsolete within the next few years, having the ability to sell upgrades to management is one of the most important skills you can have.
Whiners may also feel they aren’t solely to blame for problems that arise. They may argue that it’s the company’s management that’s causing all the issues. Well, even if management doesn’t have a clue about what’s going on or what a good solution should look like, it makes no difference. You’re job as a professional is to get the systems you’ve been assigned to run at 100% operational efficiency by everyone’s standards. If management isn’t supportive enough in your efforts, then it’s up to you to find a way to cut through the confusion, politics, or whatever, and get the job done anyway.
There’s another approach that can also be used to get your way without whining. It can even work in companies that have unreasonable management. It’s based on the fact that some managers respond to computer requests the same way they respond to new ideas...the only good ones are their own. It’s important to develop the skills to deal with this type of manager because they are everywhere and won’t go away. This’s the type who always suggests the opposite of what you suggested. Perhaps they feel it makes them look knowledgeable when they dismiss the ideas of others out of hand. Nonetheless, this type of manager is easy to handle, but it takes some practice. The old trick here is to start off by suggesting the opposite of what you want and count on them to inevitably suggest the opposite of that. Sound crazy? Then you have no idea just how often this kind of thing actually helps techs get what they need to complete tasks they’re handling. Spend enough time in an IT career and you’re sure to experience this scenario at least once. Just be sure it doesn’t backfire. They might accidentally agree with your first suggestion right off the bat and you end up with the opposite of what you wanted. Again, this takes some practice.
Another type of manager is one who is afraid your request will affect so much of the company, it could elevate you into a light that’s brighter than their own. The trick here is to let them share the credit. Drop their name around as someone who came up with some of the original ideas. Sure it’s not true, but you want those new systems right? So bite the bullet and get with the program. Chalk it up to the tough life of a computer tech…all pain and no glory. The bottom line here is that if you keep the systems in shape and up to date, your legacy will gradually come to the top anyway. The truth is, legacy is always better than moments in the spotlight. So don’t let your pride get in the way of your good work. Rise up in your company through providing solid systems and not through craving attention. If giving up some credit in the short run means others will be commenting a year later (perhaps over the e-mail systems you built) on how good the computers seem to be running since you’ve be around, then you’re on your way to achieving excellence in your field.
Yet another type of problematic manager is the “been there before” type. Whatever you suggest, they’ve seen it done differently at a company they used to work for. To them, that other way is better than what you suggest, regardless of how well designed your new system is. Now you’re competing against something which is totally outside of your control, but this one is easy. Just remind them that their current work environment is different from their old company and that the solution you propose will work better and cost less in this situation than the one they remember will. On rare occasions they may actually consult a tech they know from their old company about your operations and how they can improve them for you. The problem here is that in the IT world no two systems are ever exactly the same and therefore second opinions are terrible ideas. This’s one of those few occasions where lowly techs get to say no to upper management. Unless the other tech is as up to speed on your systems as you are, then their ideas will probably do more harm than good.
Your systems are your domain and no outside intervention is allowed without your approval. If management lacks confidence in you, then improve both your knowledge and your communication skills. It’s a different story if you requested the outside support on a professional level basis from a trusted vendor or through a manufacturer support agreement, but under no circumstances are you to turn over the keys to your systems to another tech who is behaving less than professionally. This’s the one thing you should openly fight for with management. Just be sure to demonstrate good arguments without showing any frustration on your part. Once you finally get the improved solution in place and running well, it’ll always strengthen your opinions in any future crisis. Just make sure those opinions never involve whining if you want them to really matter.
Too Busies
Even if your schedule really is overloaded, it’s best to learn to stay ahead of the curve and keep the jobs you’ve been assigned on track. The most important tool for this is good time management. Few things are less forgivable in the fast paced 21st century than bad time management skills. In today’s fast paced economy, time management is a critical part of nearly every job out there, IT or otherwise. Being able to manage your time is the same as being able to manage your usefulness. How much work you can properly do within a set timeframe is how your contributions to the company will be measured. In IT, this means managing multiple timelines while you move between the different jobs you’re working on.
A major component of time management is the ability to prioritize each job as soon as it becomes known to you. Prioritizing means different things to different people. Some techs prioritize their tasks by focusing on end-user complaints. Others base priority on what they think will get the overall workload done the quickest. Still others prioritize based on where they’ll be at any point in the day. Even local geography or a building’s architecture can affect how you choose the order for getting things done.
Nevertheless, even if you’re doing a great job with your own prioritizing, you can still be impeded by others who aren’t as focused. However, to achieve excellence in IT you must always find a way to not let things slow you down. If the offending party is a boss who throws you a last second task, you still need to stay on track with all your original ongoing tasks. If he/she received a call from a customer that needs attention immediately, adjust your plans and add this job to the list and continue. Just stay flexible enough to be able to scale out your work load without stumbling to the point you end up getting nothing significant done that day, but don’t go beyond your limits. The point when you become saturated by your workload and prioritization concerns should be well known and understood by you. If management doesn’t know it also, then let them know. Your honestly and openness on an ongoing basis is a good thing and will make your boss’s job easier too. After all, it’s your boss who feels the most pressure from upper management and ultimately the end-users too. The more you can help them cope with the pressure by giving them honest feedback on the impact of the workloads you’re being given, the better.
As far as end-users go, those affected by a computer problem usually feel their own needs are the most important. This’s human nature, especially in pressure-filled work environments. It’s just another variable for you to work through when prioritizing. When all the variables are working against you, don’t panic or get frustrated. Just make good choices about how best to proceed and then stick to those choices.
There are a few things you can do to help manage time and make your work easier. They are:
Always respond quickly
The more you wait, the bigger the workload will be down the road. Today’s jobs are likely to overlap with the ones you’re sure to get tomorrow. Even if you’re tired and worn out, quickly jumping on jobs as soon as they arise will serve you well in the long run. The more things you can cross off you list today, the better off you’ll be tomorrow and in the future. Otherwise, you risk getting stuck in perpetual catch up mode. If several jobs come up at once, prioritize each appropriately but move on all of them as quickly as possible while remaining mistake free. Remember, habitually slow techs are easy to spot. They’re the ones complaining about the work load even when they have less to do than other better producing techs around them.
Don’t call a job done too early
This’s a recurring theme in this book. Calling a job done before it truly is done just adds to your workload down the road. Few things can hurt your morale more than having to stop in the middle of the day and redo a task you thought you had finished earlier. Priorities become confused and even the easy jobs feel a bit harder as you work to catch up. Doing a partial job only defers the core of the fix to some other time when your workload will be every bit as hectic. That kind of approach will always wear you out faster than doing a complete job does; especially after spending weeks, months, or even years perpetually catching up from behind.
Some techs try to make an art of balancing quick fixes like it’s some kind of dance. In reality, they’re more like the performer balancing a bunch of spinning plates. They move from job to job while hoping everything stays balanced and holds long enough for them to reach the endpoint. Unfortunately, this can only go on for so long before one plate eventually falls and causes the tech to loss focus; throwing the other plates out of balance, too. It’s best to not get into this rush-job frame of mind in the first place. The tech shouldn’t move on from any plate until each is confirmed to be stable and no longer at risk. Getting into the habit of sticking around long enough to honestly confirm a job is complete may seem a burden at first, but will definitely save you time over the course of your career.
Handle time management now
Start planning for an easier future by including time man-agement into the systems you’re working on now. You do this is by performing the preemptive fix. If you’re working on something and notice something else isn’t quite right, do the second job too since you’re already there. After all, that other problem isn’t going to fix itself after you leave. If you ignore it in the hope you can sneak back later and handle it then, you’ll only be wasting perfectly good time later on. Usually, with that approach the problem will just smolder until it eventually flares up before you return…and also when you least need it to. You’ll allow the phenomenon called “putting out brush fires” to start taking over your work life. Leaving a tiny hot cinder of a problem unattended because it doesn’t seem all that important at the moment will always cost you later on.
If you believe you’ll get back to the problem at a more convenient date, you’re likely fooling yourself. No one can predict the future, especially in the busy world of IT, so there’s no way to really know exactly how much new work you’ll be assigned tomorrow or the day after that. It’s a gamble to think that a convenient chance to return to that proverbial “later” repair will even happen. In fact, things may be even worse later on if that shouldering cinder of a problem flares up when you’re busy with another job that needs to be finished in a hurry, too. You’ll always lose more time running back to put out brush fires than you would have spent had you corrected the problem in the first place. Best practice is to remember there’s never a better time to make something right than the present.
Get used to inspecting the stuff you’re working on and fixing all the issues you see even if they’re not on the ticket. If it’s a big problem that can’t be fixed on the spot, you’re at least ahead of the curve and can schedule a future repair in a reasonable non-brush fire fashion. The preemptive approach is an important and useful way to improve time management. Conscientiously working to stay ahead of the curve by nipping new problems in the bud makes the systems more reliable over time and your life a lot easier. Not only will you have less surprises, the systems themselves will be more bug free. Less bugs equals easier time management and happier end-users. It also helps you to establish a reputation for excellence in your field.
If you’re running your own shop or are part of a development team, you have the power to be preemptive at the very beginning while in the design phase. Anything you can add in the beginning that will make solutions easier to fix later will make you a happier tech down the road. This isn’t to say that things still can’t get crazy with your work load, it just means the more you do up front in the design phase, the less you have to do later on. Every good design includes ease of follow-on maintenance.
No matter how busy you are, don’t skimp on the front-end work for any system you’re working on. Time management begins before you begin the work. Design your systems to be silent and trouble free. It pays dividends by giving you a system that’s easier to maintain, causes less stress, and leaves you with more spare time on your hands. The old adage that you don’t look busy because “you did it right in the first place” holds true here. Building things from the beginning with ease of maintenance in mind and then staying ahead of that maintenance makes task scheduling much easier over time.
It’s a common misunderstanding by non-techies that the guys who are running around putting out the brush fires caused by poorly designed systems are hardworking heroes. Excellent techs know this is not true. Many brush fire guys are simply imitating a heroic effort while chasing after marginal systems that should have been designed better from the start.
Take brief notes outlining your work as you go
While this does mean doing paperwork, admittedly a painful subject to many techs, it rewards you with a good way to minimize your time on a job. This isn’t about System Design Life Cycle, documented user requirements, IQ, OQ, PQ, or any other part of systems validation. This’s about your own approach to keeping up with the things around you. It really can help to keeps notes as you work. Be sure to use plain words in simple sentences. Notes won’t help much if they cause your eyes to glaze over when you try to read them back later. Techs do enough reading anyway. You should take just enough notes to help you from unnecessarily going over the same ground twice. Writing a few quick things down as you work means you won’t have to reverse engineer what you just did when you go back to do it again at a later date. The notes are to help you keep track of what you’re doing during a busy day.
