Well it's been a while since I wrote something, and even longer since I wrote something management-related. So I need to play a bit of catchup.
Programmer To Manager
Before I came to Portland, I was the software development director at ShopLocal, a Chicago-based startup that did a lot of growing, a lot of changing, graduated to medium-business status, did some acquiring, got acquired, and became a popular comparison shopping site, among other things. I was with ShopLocal for over 6 years and started out in 1999 as the (main/only) programmer, working in ASP, VB6, and COM+. The company grew & grew, and over the years I had the opportunity to move up in leadership roles, first as a team lead, then manager, then director.
Towards the end I still considered myself a technical person, but I didn't do any programming, and instead dealt with staff, departments, projects, clients. It was an interesting transition, from programmer to manager, and when I left ShopLocal I thought it would be helpful if I wrote down some of the things I learned and/or struggled with, since I felt that there would be a lot of programmers & other techies who would become managers, some reluctantly, some willingly, some in order to get a pay bump, some to grow professionally, and some in order to stay employed.
Whew. Ok, that's out of the way. Blah blah blah, I wanted to write stuff for new programmer-turned-managers. :)
New Managers Need a New Focus
Anyhow, if you're a new IT manager, and you used to be a programmer or other technical person, you have a new focus and role that you need to bear in mind. I'll just assume you used to be a programmer, but you can mentally substitute in what you used to do.
When you were a programmer, your goal was pretty much to produce code. Your personal technical productivity and effectiveness was the measure of how valuable you were to the company and how well you were doing your job. Sure you mentored others, worked on a team, collaborated on things, etc. But at the end of the day, it was mostly about how well you could produce.
As a manager, it's different. The technical productivity and effectiveness of your department (or team, or group, or whatever) is the new measuring stick. You are judged on how well your team does as a whole -- your personal productivity doesn't matter.
Your personal level of technical productivity is of secondary importance. I can't stress that enough, because many new IT managers (myself included) go through a phase where they're trying to "be a manager" but also crank out code, and they sometimes find themselves doing programmer-type tasks because they are "better at it," or they're the only one who knows how to do it, or it's fun, or it's "only an hour" of work, or whatnot. Don't fall into that trap.
To be a good manager, you need to make sure that your department is producing at optimum level. If you're still cranking out code at a rapid clip, and everyone else in your department is under-utilized, or coding slowly, or putting out too many bugs, you have failed. It doesn't matter if your personal code output is stellar.
Your Department is Like a Web Server
Think of it in terms of multithreaded applications, e.g. a web server. Web servers get tons of simultaneous hits, and their output is measured in requests per second. In order to have a fast web application, the total output of all involved threads is what matters. If you have one thread that's really fast, and all the other threads are dog slow, that's not as effective and scalable as if all threads are decently fast, but you can scale out to dozens or hundreds of threads.
You should keep that in mind as you ponder the question, "now that I'm promoted to manager, how can I be even more valuable to the company than before?" Because that's the truth -- you got promoted, and the last thing your company wants is for the IS department to get worse (other than an initial adjustment period). The irony is often really good programmers have an opportunity to get promoted to managers, which can be a big initial blow to the team's productivity. So to be a successful programmer-turned-manager, how can you help the company produce even more software before, when you're no longer coding as often or at all? The key of course is to ensure that your staff becomes more productive. Think of your staff as the threads of a multithreaded application, and work on ways that each of them can be more effective.
That may be harder than you think. If you were a good programmer, think about why you were good. Was it because you typed quickly? Was it because you knew the API and coding environment? Were you good at managing scope and detecting pitfalls ahead of time? Did you estimate well? As a manager, you'll have an opportunity to teach your staff some of your tricks. Plus, you'll probably be involved in projects enough to still utilize some of your skills (e.g. detecting project pitfalls).
Ok that's probably enough rambling for now. Remember, you are now orchestrating a multithreaded application, and your goal is optimimum combined output. Don't worry about the performance of a single thread (e.g. you) if the other threads (e.g. your staff) are doing poorly or average. Instead, focus on ways to make most or all threads better. You can cherry pick caveats to this, but you need to focus in the right direction first.