Five Dumb Mistakes IT Pros Make (And How To Avoid Making Them)

One avoidable mistake might be all that stands between you getting promoted or being caught out by a "resume-updating event". Here are five common areas where IT pros mess up — and how to ensure you don't make them.

Mistakes picture from Shutterstock

These hints come courtesy of a presentation by BCS president Jim Nelson at Data Center World in Las Vegas, which I'm attending as part of our ongoing World Of Servers coverage. As with our recent list of useful tactics for deploying metrics, these hints were originally directed at data centre managers, but have a broader applicability in many cases.

1. Not documenting processes

The mistake: "IT people suck at documentation," Nelson pointed out, bluntly but accuratle. "It isn't sexy, it isn't fun, and you don't have time to do it." However, the consequences of not documenting can also be wide-ranging: "If you do not define expectations, your staff will make them up."

The solution: Set aside time in your calendar to produce documentation, and keep it simple. "Write it down; write it at a 10-year old level," Nelson said. "'This is what you do, and make sure you don't do this.'"

If your documentation needs are extensive, consider hiring a technical writer on a contract. Broadly speaking, technical writers are much cheaper than actual IT professionals. Interns are also another potential source of documentation.

2. Not recognising the impact of outages

The mistake: You might view planned downtime as essential, but your users are unlikely to feel the same way. "There's the idea unplanned outages are bad and scheduled outages are good, but they're still an outage," Nelson said. "When you schedule things because you need to, it still costs you time and money and it impacts your customers."

The solution: Some systems really can't be tested or updated without taking them offline. When that happens, make sure you communicate it in plenty of time to affected parties. Be prepared to be flexible: your perfect timing might be entirely imperfect from the point of view of a user with a crucial deadline.

3. Not accurately tracking costs

The mistake: In a world where maintenance budgets are often a best-case scenario, you'll never get funding for new equipment or software if you can't demonstrate business value with hard numbers. "How the heck can you build a cost justification when you don't know what's at risk?" Nelson said.

The solution: Be as specific with numbers as you can, whether those figures are positive (efficiency gains) or negative (the costs associated with outages). "Say an outage costs $1 million a minute and all of a sudden you have management attention," Nelson advised. But be sure you can back those numbers up.

4. Paying too much attention to external metrics

The mistake: While you need to know your own costs, you don't necessarily need to know everyone else's. Knowing the average cost of downtime might tell you you're performing better than your peers, but just how confident can you be those figures really apply to you? "80 per cent of the market isn't the huge shops," Nelson said. "It's the poor slob who can't get any staffing or support or budget."

The solution: Focus on your own numbers. "Why do you care about averages?" Nelson said. "Protect your own organisation; that's what you're being paid for."

5. Setting yourself up as the sole expert

The mistake: Everyone wants to be recognised as skilled in their field, but branding yourself as the sole source of IT wisdom can backfire. "Try not to put yourself on a pedestal — you make a much better target," Nelson said. "Positioning yourself as the expert means you get the blame."

The solution: "Don't set yourself up to be perfect," Nelson said. "You're just the caretaker of the data centre. You're just supposed to keep this thing running on behalf of the organisation."

Lifehacker's World Of Servers sees me travelling to conferences around Australia and around the globe in search of fresh insights into how server and infrastructure deployment is changing in the cloud era. This week, I'm in Las Vegas for Data Center World, looking at how the role of the data centre is changing and evolving.


Comments

    ... Sorry, but I know 17 year olds with no experience or education who know instinctively to do every point of this after just on site training. If you're an "IT pro" (still the worst branding ever imo) and this is a mistake you're making.. You probably won't be a "pro" (as in, getting paid) for very long..

      Judging by many of the Australian websites I've encountered in recent months, no one has thought much about the processes governing the design, as any thought of documenting them for the user would demonstrate poor they are. Designers of resume-submission pages, I'm looking at you in particular.

        I guess that's true - a lot of companies DO just hire anyone, or make bad hiring choices that lead to poor results, but then decide to settle rather than finding someone better for the role.

      I find that it doesn't matter that you have documented process, whingers will complain to someone high up until they can break the rules anyway leaving your process pointless.

        Processes should be able to stand on their own merrits. It's important not to mix pride with business logic - if you cannot explain why it SHOULDN'T be changed, then it should probably be changed. It's in very rare circumstances (like where you simply are not allowed to disclose details of why to the employee in question) that you should ever really veto an idea.

        More important in my experience thus far is just to control the mechanism of change. You don't want to be constantly questioned day in day out on mundane details of trivial tasks, it's not productive to anyones time. Personally, I make probably 5-10 minutes a day where I make a point to ask my team what's going on, thoughts, etc etc as well as a team meeting of sorts once a week where we combine and run through any accepted changes from each of these sessions, and a review process once a month which is mainly about how well the team are following processes (which in turn decides how much their monthly bonus will be in comparison to others on the team).

        It sounds complex when I write it all out - but in reality what we're talking about is a very small amount of time funneled in such a way as to accept or rebuff changes very rapidly, and the employee's go away feeling that they're valued (even if you find reason not to) which in turn leads to a much greater feeling of being respected for the best possible reason.. Because they actually are.

        If it's a coworker - this is still very applicable, but might require a different tact - and the end goal more being to make your team mate feel shamed by how much better at the job you are then them, which - as long as you ARE better at it/smarter than them - will generally lead to them going "Well, maybe I should just listen to them next time.."

        That all said - some people ARE just bad role fits and THAT is the point at which you should be taking that issue higher.

          No see i get that, im ITIL certified (along with many other certs out the wazzoo) so i understand the importance of procedure and correct ways to initiate change, in my experience however its normally the idiots who are in those positions that don't have the qualifications.

          In this case i wasn't talking co-workers i was talking usually clients who have no clue WTF they need, and go on what they think they need, 9 times out of 10 their wrong, but its usually their way or the highway, until it goes wrong and even though you told them so and you had the processes and the documentation to prove it, its now you're fault and you have to fix it, within the most BS time constraints.

          I find that "IT managers" and "Project managers" have 0 clue how things work in reality, so you throw process and procedure in their faces, you normally get over ruled anyway, so my attitude these days is why bother?
          i'm still great at my job, i know more than 90% of the people i work with, i've done almost every facet of IT over the last 17 years, and i get significant promotions based on my skills every 12-24 months, cant ever complain about that.

          But that's because I find it easier to go over stupid peoples heads to get stuff done the right way the first time, which usually means i have to ignore documentation, and if done right you reap the rewards.

      Yet I know 30+ year olds in the workplace who don't do any of this because 'they're good enough to not need to...'

    I would have guessed #1 would be not making a backup, and/or not having an escape route if something doesn't turn out as expected.

    The excuse 'I don't have time to make a backup' is no excuse at all :-)

      Well, all of that would be documented in the process...

    I think step 5 applies to many Professional jobs. never put yourself in a position of responsibility or indemnity if you're not required to.

    Definitely something to live by.

      Maybe if you make a lot of mistakes. Personally I dont see why anyone would ever act like they are perfect, the thing to me that makes all the difference is how you handle it after it comes to light.

      Why view a technical fault as a personal problem when really its a time to show everyone how capable and dependable in an emergency you are.

        I agree with you here for sure, i don't make a lot of mistakes at work, and never make the same one twice.

        But there is nothing wrong with believing you are perfect at your job if you're skill level matches the belief, remember that confidence as long as not misplaced is a powerful tool to promotion.

      I'm not sure I 100% agree. If you don't put your foot forward then you will forever be stuck in the pack. Taking on responsibility isn't the same as being reckless, you can put yourself out there without necessarily putting yourself at immense risk depending on how you go about taking on those duties.

      Not always, but sometimes there are times where it is refreshing to take a leadership role and to succeed in it. If the risk of failure is greater, then in many cases the rewards of success also are greater too.

      I also don't think it means you should go at something alone.

      Last edited 04/05/13 1:30 am

    In my experience, 1 and maybe 5 are often combined, not as mistakes, but as "job security".

    "If I'm the only one who knows how this works they can never fire me."

      They can never promote you either.

        Yep. Too true. I've literally seen someone make themselves 'too valuable to promote' in a position. Sure they got nice enough payraises, but now they're in their 12th year in the same position at a school in the IT dept (private school), they're the Network admin, website admin, telephone guy, hardware repairman etc. They're so valuable when they asked to manage the IT dept which is a less hands on hardware/software role and more business side, they were told 'no'.

      At my last job they didnt want to give me a pay rise, so i quit. They expected me to create documentation for everything in the last 2 weeks at the company so the fresh out of Uni person could take over for a lower wage. I did create that documentation but i tell you now it wasnt complete or entirely correct :)

    Number 5 I've been guilty of quite a few times at my present job, but the main reason it's something I'm working on to avoid is not because of blame (we're all quick to take responsibility here), but because if you're the only one who knows a critical set of systems, you're the only one that can fix them if something goes wrong.

    I've tried at various times to get a week or two off work, but due to working on some very critical systems pretty much by myself, nobody else had knowledge of how they worked, and couldn't give me time off in case something went wrong.

    My point is: document everything. Document how it works, what could go wrong, how to fix what could go wrong, and anything else you can do that means another developer could easily fix something without needing to call you.

    Last edited 03/05/13 3:29 pm

      I think some workplaces are addicted to living in crisis mode.

      I transferred jobs in one company, and wrote an exit document to help successors locate everything from digital resources to important contacts, and a reference guide to policies and legal issues framing the job. Within two weeks of me posting it to my ex-manager, my successor and posting it on the group's intraweb site, they claimed to have lost all copies. Mistakes from the past started being repeated almost immediately.

      I rented out my house for a while and wrote a friendly owner's manual for it so that if anything broke (or appeared to) then there were links to user manuals, suppliers and repair agents. I left two copies in the house, gave another one to my agent and sent them the PDF . On returning to the house it appears that it was totally ignored as property manager and tenants basically chose to flounder around helplessly for days to months each time something came up. Hopeless.

        ...and there's your mistake. You expect people (usually dumb people) to RTFM. When does that ever happen?

Join the discussion!

Trending Stories Right Now