8/28/2001 -- I get e-mails. Lots of e-mails. From readers of my column, seeking advice on how to make it as an IT professional. From headhunters claiming they have the perfect job for me (see my column this month). From people I've met in the course of my IT career, wanting to know any secrets I can share on how to survive in today's tumultuous technology environment. Yeah, I get e-mails!

And from all these e-mails, together with my own experiences (both good and bad), I've identified five critical career mistakes that IT professionals seem destined to make. So, grab some java (the brewed kind you might get from Starbucks, not something you download from Sun's Web site) and read on. You'll not only learn what these mistakes are, but how to correct them, or even avoid them altogether.

Mistake #1: Relying Solely on Technical Skills
When I was a systems analyst for a large corporation several years ago, my technical skills were never in dispute. In fact, my colleagues in the MIS department would often come to me when they were stumped with a technical quandary. I thought I was on the fast track to career advancement. But every time I applied for better positions within the organization, I was passed over in favor of someone else, often with less technical expertise than me.

When it was time for annual reviews in MIS, I began to understand why true career advancement was eluding me. You see, I scored at or near the top in all the technical categories, but the technical portion of the review only accounted for about 25 percent of my performance assessment. The other 75 percent dealt with people skills, company culture, teamwork and other decidedly non-technical areas.

After I was given my review I made it a point to observe other techies in the department. I paid close attention to the way they worked with personnel from other departments. I took notice at how they conducted themselves at staff and project meetings. I even took them to lunch from time to time, hoping to gain more insight into all these non-technical skills.

I found out that the people they supported thought they were terrific -- even when they didn't know how to fix their problems. Department heads and other managers appreciated how much concern they demonstrated to their staff. Intrigued, I decided to take my research further, and talked to folks outside of MIS. I interviewed end users, I spoke with managers, I even talked to a director or two.

What I learned was surprising: Outside of MIS, I was not considered such a technical guru. In fact, many users interpreted my highly technical approach to things as a way for me to convince them of my expertise -- they thought I was trying too hard to prove my technical prowess. Of course, from my perspective that's not what was going on at all. But that's how I was perceived.

How can you avoid this mistake? First, find out which IT professionals in your organization have the best reputation within the company as a whole. You may have to swallow a little pride, but seek these folks out and pick their brains: "Hey Lisa, everyone in accounting thinks you know exactly how to handle any IT issue they have. I'd love to know your secret!" (Give me a break here! I know none of you out there would actually make such a trite statement -- I'm just trying to get a point across.)

Second, don't flaunt your tech skills. Let me say that again. Don't flaunt your tech skills. Oh, I know it's tempting to show how you know that arcane registry hack off the top of your head, or that you can spew forth subnet masks without even thinking twice. Save it for the tech conferences.

Finally, in addition to all the technology training courses you attend and all the computer books you read, try to squeeze in a people skills seminar or a couple of business books as well.

There are some obvious exceptions to this point: If you were hired to address a specific technical problem that others couldn't solve, you certainly want to articulate your technical expertise in that area. You also want to ensure that your manager (and coworkers) knows what you can do.

This issue isn't as crucial for programmers as it is for IT operations folks, but even a hardcore Java developer will benefit from a skillset that includes more than algorithms, object classes and function libraries.

Mistake #2: Lack of Specialization
You know Windows 2000, you have a good understanding of networks, you like tinkering with system security, and you're even pretty handy at coding Web pages. You're a dream come true for all the CTOs, CIOs and IT managers out there looking for good talent, right? Guess again.

These days, companies want specific expertise for specific projects. There are several reasons behind this:

• Technology is increasingly more complex. The old adage (and I do mean old), "If you've seen one database/accounting package/graphics program/firewall/etc. you've seen them all," just doesn't cut it today.
• It's got to be done right the first time. In the pre-Internet, pre-eCommerce days, it was O.K., even expected, that project life cycles were measured in months or even years. Now, organizations need to have project deliverables in weeks, if not days.
• With an ever-growing pool of IT talent to choose from, companies look for specific skill sets in potential employees to help narrow down the hiring process. For example, suppose a company needed a systems administrator to help manage a Windows 2000 network running Exchange, Act, and SQL Server. Why would the IT Director want to hire someone who had solid experience with Win2K and Exchange, but just a smattering of SQL Server, and whose contact management experience was in Goldmine, instead of Act?

"O.K., Kevin," you may ask, "How am I supposed to know what to specialize in?" That, my friends, is the question of the day. You could stick with what's most common, used by the majority of organizations (Windows NT & 2000, Exchange, SQL, Cisco, etc.). The good news in this scenario is that these areas are where most of the demand is. The bad news? Just about every IT professional out there knows this stuff too.

So what's my advice? Learn everything you can about a not-so-common technology, in addition to the mainstream stuff. For instance, not every organization uses Act, but the ones that do seem to always require assistance in maintaining it. An all-around Windows admin who also knows a thing or two about Act would be highly desirable by these companies.

Another good approach is to focus on a particular combination of technologies. Knowing Act is a good thing. Knowing how to properly integrate Act with Exchange without befuddling your users is a great thing.

But beware: Like many things in life, being too specific can be a bad thing. I once contracted a SQL Server consultant who absolutely amazed me with his arcane knowledge of SQL's internals. He could manipulate log files like I've never seen! But he didn't even have a clue as to how NT user authentication worked with SQL 7. This fact, combined with his other non-SQL technical shortcomings, so diminished his value as a SQL consultant, we ended up ditching him for another guy.

Mistake #3: Job Hopping
"It's expected in the IT industry for people to switch jobs often." "You can't really advance your career in IT unless you move around a lot." "I would never have been able to learn the different technologies I know if I had stayed with one company."

All direct quotes from yours truly. And when I made these statements, I truly believed that they were correct. There is a period on my résumé that reflects this philosophy -- I had worked for five different organizations in about as many years. And although I still believe there is some merit to jumping around, the drawbacks far outweigh the benefits.

For starters, a checkered job history almost always requires an explanation. And when you're up against several other candidates for a position, having to explain anything puts you at a disadvantage.

Another thing to be concerned about is the taste you leave in your former employer's mouth after you leave. Even if you give proper notice and do your best all the way to your last day, your soon-to-be-ex boss may not be inclined to give that glowing reference you think you've earned. (I deal with this topic in more detail in the next section.)

But the real problem with job hopping goes much deeper than that. Most folks see a job hopper as someone who is self-centered and decidedly not a team player. I was interviewing for a sales engineering position some time ago, and everyone I spoke with thought I was great. But the person who would've been my boss also told me straight out: He had serious reservations about my commitment to the company. He was worried, rightly so, that I might bail on him after a year or two. I found out they offered the position to another candidate with far less experience than me.

Does this mean you should stay in a position even if the situation is terrible? Or that you should pass up a great opportunity because you haven't been with your current employer that long? These are tough decisions. Factor in today's volatile IT-job market, and the dilemma gets even tougher. My advice would be to first ascertain just how terrible your current situation, or just how great that new opportunity, really is.

If you still feel you should move on, make sure the organization you're moving to is where you really want to be for the next several years. Here's where corporate America shows its benefits: In a larger, well-established organization, you're likely to have more opportunities to switch positions within the company. No one looks down on that!

Mistake #4: Burning Bridges
Job hopping is bad enough. But making sure your ex-employer can't stand you is worse. Yet I've seen many an IT professional do just that, time and time again. There must be some kind of DNA that causes IT folks to go out of their way to ensure that they can't go back.

Now perhaps a couple years ago, when the demand for IT professionals was greater than the supply, you could afford to be so flippant with your previous employers. Don't do it now!

I know how much you want to stick it to that clueless manager! I know how much you were taken advantage of. I know how much better you could have run things, if only you had the chance. And I know how much your contributions were undervalued by the company. Hey, these are all probably reasons why you're leaving, right? Fair enough.

But think of it this way: What better way to have the final word than to manage to leave on good terms, and have that clueless manager be happy to give you a good reference?

Remember, too, to keep the doors open with coworkers and peers. Not only may you need references from them, you might cross paths with them down the road (the coworker you leave behind today may very well be the manager that hires you tomorrow).

Mistake #5: Taking on Management Responsibilities
Oh, how the mighty have fallen! I've seen truly exceptional IT professionals -- programmers, network admins, project managers, and the like -- ruin their chances for career advancement within a company by taking on management positions when they weren't ready or qualified. It seems many IT professionals (and many existing managers as well!) think that because they are so good with a particular technology, they must be good at managing others who are also good with that technology.

You see this evidenced in job postings as well. Take a gander at a techie job site on the Internet -- you'll see plenty of postings for managers, directors, even VPs that ask for a slew of technical skills and experience. Yet these same listings rarely ask for true management experience.

See the problem here? You've got IT professionals thinking they can manage. You've got managers thinking that these professionals can manage as well. And the industry in general expects that IT professionals should move into management. Everywhere you turn, the message is clear: You should strive to manage.

But is management really the right move? Take a moment to consider things. What do you really enjoy doing? Would you rather solve complex network issues, or deal with an employee who comes in late all the time? If you had the choice of taking a new evaluation CD home to play around with or working on a departmental budget all weekend, which would you choose? Would you rather be developing a really cool Web site or convincing other managers to approve the development of a really cool Web site?

One last thing to consider on this issue. When times are tough, the people who actually do the work are less likely to be "downsized" than the people who manage the people who do the work. I know this isn't true in every case, but it merits consideration.

Tell Me Something I Don't Know!
I know some of the issues I've raised may appear clichéd or trite -- you've heard a lot of this stuff before. But I'm just calling it as I see it. Too many good people are messing up their careers by not paying heed to these issues. I know. I was almost one of them!
But thankfully I took an honest look at my situation and recognized what was happening. It may well be prudent for you to do the same.

What career mistakes have you made? What's your advice for other IT pros? Post your comments below!