How Do I Become an IT/IS Manager?

link915 writes "For the last seven years I have moved around from job to job climbing the rungs of the IT ladder. I've worked in tech support, network operations, sys admin, and as a programmer. Two years ago I took a job with a company that has a small IT department. We are now hiring on more people and doubling the department, and along with this growth comes an IT manager. Now, I could stay and wait things out with the goal of taking over the IT manager's position someday; or I could look for a new job as a manager elsewhere. What are others' experiences with moving up the ranks in IT? Is it best to move on to another company or to stay where you are and try to get ahead there?"

Comments

Are you sure you WANT to ?

[JSmooth]

After 16 years in IT I finally accepted a management position in a large company. Yes it is more money and more responsibility but what it isn't is hands on. If you like the techy stuff then stay away from management. In just a few months I already feel like the guys I use to make fun of. If your goal is more money pick up some more certification and then start tossing your resume at the large IT consulting firms. I worked for six years traveling the country as an security consultant. Tough, difficult stuff but I was never bored.

Run away! Run away!

[Desmoden]

IT management is the most thankless, horrible job/career path on the planet. I know this from much experience and many friends.

I know it's very hard when you are a seasoned experienced IT person to know where to take your career, but IT management is NOT it. May I suggest some other options.

Sales Engineer: My favorite. Great pay, good hours, lots of good lunches, some very technical and challenging problems. It's just like being in IT, but you are paid well and everyone appreciates you.

Consultant: Takes a special personality, but hours and pay can be very good.

Field Engineer: Better pay, hours can be rough, but if you don't like dealing with the business side it's better than the previous two options.

Technical Marketing: Little harder to break into, but good pay (not as good as sales), great hours and you really get to make an impact.

Whatever you do, just say NO to management.

Two routes

[hey!]

The hard way: apply for a management job, in a firm that doesn't know you, and with no management experience on your resume.

The easy way: tell your boss he needs you in management, using the credibility you've built up with him. If you don't have any credibility, then this is the hard way.

Generally, if you are person that makes things happen, and if people on the management team like working with you, and you have a good argument for why putting you in that position would make save money or make everyone's life easier, it isn't hard.

The third way is probably even easier, but it backloads some drama. You simply start managing things. You find something that needs to be managed and you do it. You remove burdens from weary managerial shoulders. You fix things everybody knows are broken but nobody has the energy to do anything about. In short you become a manager. Now comes the drama: you point out that you are managing, and you want the title and a better salary. If you get both, great. If not, settle for the title, wait a decent period, then apply for a job elsewhere.

Come to think of it, that's how I got into IT management.

I was hired to maintain a custom software system that was written in C and an obscure database system I happened to know. The department had a backlog that nobody had ever bothered to characterize, so I did, just to figure out how much work I had. The backlog was over three years. So I went to the various people who had various things on the list which I didn't quite understand. I talked with them and heard countless stories of frustration and anxiety over various business functions. While I began to whittle down the list, a pattern began to emerge of people asking for things because they needed the answer to a problem that shouldn't exist in the first place. So I diagrammed out the worst processes, what they were supposed to do, who participated in them, and who used the things the process produced. Then I convened meetings of people who had things on the list.

There was a lot of stuff like this: "Betsy wants a status projection on such and so. Look here. Bob, did you know when you don't get this stuff done by a certain point in the month, this other thing doesn't make it to Betsy in time, and her whole department ends up working late to make deadline? No? Well, why are you in charge of this at all? Betsy could do this, it would take a task off your plate and a load off of her mind." Then people would scratch their heads, and wonder why it hadn't been set up that way all along. There were dozens of meetings like this, where we found critical pieces of information that were never available on time because it was on somebody's desk who had no idea of its significance to somebody else. Several critical information flows that could be cut from three weeks to less than a day; several instances where incoming checks got filed in somebody's drawer because they happened to be attached to a particular form instead of going to finance to be cashed right away.

To make a long story short, the three year backlog became a three month backlog, practically without a lick of programming. little programming and the backlog went under the 1 month benchmark. After a couple of years of taking the bull by the horns, I had streamlined most of the critical business processes, identified numerous serious problems with financial control and reporting, which I addressed by finding a tech saavy CPA and suggesting he be hired to fix them. As a result, over the course of a year a new finance department was in place, headed by a Sloane school MBA with a CPA as comptroller, and professionals with years of experience heading up AP and AR.

Now to me, this wasn't management. It was engineering. To solve a problem, you identify what really needs to be accomplished and document the environment it has to be done in. You discover metrics by which a system's performance can be measured and improved. You persuade people to agree with your d