IT Manager's Handbook

An anonymous reader writes "I have managed a lot of technical people in my career, and one thing I know: managing geeks is hard. Rewarding, interesting, challenging — and hard. Hard to do well. Dealing with all of the complexities of a modern IT environment is extremely difficult. There is precious little time, even less (skilled) help, and many, many "mission-critical" demands. This book is written for that over-worked, tech-savvy (and perhaps business newbie) IT Manager (and IT Manager wannabee.) It discusses both sides of the IT department equation: both the technical, as well as the business issues. It talks about not only how to write a good SLA but also how to avoid burnout in your employees." Read below for the rest of the review. IT Manager's Handbook 2nd Edition author Bill Holtsnider and Brian D. Jaffe pages 589 publisher Morgan Kaufmann rating 8 reviewer anonymous ISBN 012370488X summary discusses both the technical and business side of being an IT manager

This book has 20 chapters that discuss both the concepts and the details about critical IT tasks. The first ten chapters discuss the Business of Being an IT Manager: What is an IT Manager?, Managing Your IT Team, Staffing your IT Team, Project Management, Changing Companies, Budgeting, Vendors and Their Products, IT Compliance and Controls. The second ten chapters discuss The Technology of being an IT Manager: Getting Started with the Technical Environment, Operations, Physical Plant, Networking, Security, Software and Operating Systems, Enterprise Applications, Storage and Backup, User Support Services, Websites, User Equipment, Disaster Recovery.

Back in the day, IT was a relatively well-defined activity. Not a lot of people knew about it, it was complex but pretty isolated, and there was precious little "interaction" (interference) with the business side of an organization. When I started managing, there was the technical side and everything else. Now things are very different. IT Managers not only need to have the latest patches installed on the network but they also need to know the five standards steps in project management. They have to know to write a disaster recovery plan as well as what the relative value of a certification is, what phishing is as well as what not to ask in a job interview.

The concepts discussed in this book are relatively classic; the principles of project management, implementing physical security or estimating costs for a budget are not new areas. The authors discuss these topics with a lot of hands-on detail, specific information that a manager can grab quickly. This book let me read ten pages on "Change Management," for example. I knew what change management was, but I needed more that a buzzword before I met with my boss. This book gave me enough detail to talk about it.

From the preface: "We wrote the book for new IT managers and future IT managers. Much of the material in this book will be familiar to experienced IT managers — those people who have been managing IT departments since the space program in the 1960s. But for many individuals, the late 1990s and early 2000s have brought a radical change in responsibilities with little or no help along with it." While that is not me, that is a lot of people I know and have worked with. They got shoved into management because they knew what a "service pack" was and the previous IT manager had left. One minute they were connecting CAT 5 cables and the next minute they are in a ten-person meeting trying to explain why the department needs two new server racks, and two more servers, and two more service techs and three more fill-in-the-blank.

It can be a challenge to make text about operating systems interesting, but I liked their comparison of the Linux/open source and/or Windows discussion. They point out the strengths and weaknesses of each. There are Pro/Con tables scattered throughout the book that I like a lot. Give me the facts, and I'll make up my own mind.

I don't want to say I could not put the book down, because I could. It's designed to let me. I can jump in, get the data I need ("What does ILM stand for again, and what is it?") and jump out. With a fourteen page, two-column Index, a Glossary and each of the chapters ending with both websites and book citations, I can find the stuff I need quickly.

Most individuals in IT today could benefit from a book like this. No one knows everything, and most people don't even know the range of what they are supposed to know. This is a good book for the current IT manager — there are going to be some topics that they are not familiar with, such as the details of Compliance. It is also a good book for a person that wants to or thinks they want to be an IT Manager. He or she can read through this book and determine, if these are the kinds of issues they want to deal with daily.

You can purchase IT Manager's Handbook 2nd Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Abridged version

[qwijibo]

The fortune at the bottom of the page when I read this review was "Deliver yesterday, code today, think tomorrow." This seems to be the IT management strategy employed in many companies these days. I wonder if this $50 book covers this subject as well as the fortune cookie. =)

Re:Abridged version

[dreamchaser]

That's the common theme, but not always the case. A *truly* good IT Manager also manages client relationships and expectations to the extent that a decent product can be delivered within a reasonable amount of time and for a reasonable amount of money. I've found that managing customer expectations is every bit if not more important than managing your people.

Not all IT Managers have pointy hair...

What gives?

[cyberbob2351]

Where's the chapter called "Dealing with uninformed upper management"?

Re:What gives?

[Skyshadow]

That's a rather redundant chapter title, don't you think?

Actually, upper management should be somewhat uninformed. I want my CTO thinking about budgets and etc rather than knowing too much about network setup -- aside from the fact that the ones who do know a lot of details being the ones who micromanage, I want them to take care of that sort of trash so I don't have to.

The trouble comes, of course, when upper management is uninformed *and* doesn't listen to the people they hired to take care of that sort of thing for them. Heck, I've had jobs where I felt like I needed to dress up like a consultant to get management to give me the time of day...

Re:What gives?

[drinkypoo]

Where's the chapter called "Dealing with uninformed upper management"?

You'll find that chapter here.

Everybody IT needs these skills, not just bosses

[Skyshadow]

That sort of information isn't only needed by IT managers -- just working in tech jobs, you need a lot of those skills.

For example, I've found myself having the deal with a real spike in software zealots (you know, the people who are way too devoted to a certain software package or OS). I dunno if they all went away after the dot-com bust, if they were just laying low after seeing so many people lose their jobs or if I just got lucky and didn't encounter them for a while, but it seems like all of the sudden my company is crawling with people who absolutely positively can only use their one preferred product and how dare you suggest they use something else?

Right now, we're working to push all the source code in the company into a certain version control system that we set up. Someone in upper management finally realized that we had zillions of dollars in developed code sitting on desktops and servers that aren't backed up, so we spent the bucks to set up a high-availability, secure, backed up system.

With certain people, you'd think we'd asked them to cut off a pinky. We've had all sorts of trouble, from people ignoring the efforts to convert them over to outright "malicious compliance" where they check in once and then go back to the old way of doing things. I mean, c'mon, one SCM system is basically like the other and this one is pretty easy to use. Is it really that onerous for the people who are paying you to develop things to ask you to put them someplace in particular once they're done?

I know it's not a new problem, but I've never worked out a good way to handle folks like this.

In a nutshell

[Skadet]

Look, I've got lots of experience working with old-school businesspeople who value "face-time". Let me explain to them what's important:

Ready?

Results. That's it. Are projects done on-time? Up to standards? If so, don't bitch at me because I was 15 minutes late today. Maybe I was working on your project, maybe I was playing WoW. Whatever the reason, I work best between 11pm-2am. Those are my peak productivity hours, whether I'm writing songs, making headway in a game, or coding. But I'm also not real good at coming in at 7:30am.

I think IT managers need to realize that different people have different ways of working. If they could (or had the power) to leverage that, far more would get done in far shorter periods of time. If my boss came to me today and said, "Ok, you can telecommute 3 days a week. But if your productivity drops even a little, you're back here 5 days a week", I'd take it -- and they would see just how productive someone can be when you let them take on projects on their own terms.

Geeks hard to manage? Since when?

[gujo-odori]

Not to take anything away from the book - I'm sure it's excellent - but I do have to question its basic premise that geeks are hard to manage.

They can be, like anyone else - but like anyone, that depends a lot on who you hire. I managed a staff of eight full-time developers and two interns, and to throw some extra complexity into the mix, they were all all at a location quite remote (~2000 miles) from my location and I only got to go out there about once every six months.

They were never hard to manage. Even the one who required the most management (and whom I might not have hired were it not for a particular rare skill that he had and we needed) was never a problem.

Why was this so? Because of how I hire. Technical chops matter, but personality fit with me, my other staff members, and with the corporate culture matter just as much. Probably more. If you don't fit in, no matter how good your technical chops are, you're never going to be right for the position and will probably need a lot more active management than people who do fit in.

As a result, my staff didn't need much active management. I positioned myself as a BS filter between them and corporate politics, so they could focus on the work, and I made sure they knew they were appreciated, got recognition, and could see the results of their work. And raises. I made sure they got good raises. Money may not be everything, but it matters.

My opinion is that if I hire someone who really needs to be "managed" I have made a mistake. Maybe I can get the person from there to a point of not needing to be managed much, but most probably I have made a mistake of personality fit, and those are hard or impossible to fix. My personality, the personalities of my existing staff members, the company's culture, and the personality of any new hire are all unlikely to change, so I'd better get it right at hiring. If I don't, I'll just need to re-fill that position after a while because no one will be really happy and it will eventually lead to a parting of ways.

In my experience, if you hire the right people and keep them as insulated as possible from BS, all you need to do is give them clear goals and get out of the way and they will meet and exceed them all.