Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

IT Manager's Handbook 129

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.
This discussion has been archived. No new comments can be posted.

IT Manager's Handbook

Comments Filter:
  • ILM (Score:4, Funny)

    by nine-times ( 778537 ) <nine.times@gmail.com> on Monday March 19, 2007 @03:39PM (#18405779) Homepage

    "What does ILM stand for again, and what is it?"

    What does Industrial Light and Magic have to do with IT management?

    • Re:ILM (Score:4, Informative)

      by Stile 65 ( 722451 ) on Monday March 19, 2007 @03:48PM (#18405897) Homepage Journal
      Information Lifecycle Management. :)
    • What does Industrial Light and Magic have to do with IT management?
      Have you seen their server farms recently? ;-)
    • Or perhaps...
      Isolated Lamer Masturbation?
    • I looked everywhere, but could not find the matching Player's Handbook for IT employees. And is the company going to hit us up for a million different manuals on things from how to run an email server campaign to how an SQL admin prestige class should be played, or will it only be the core books including the Monster Manual. I expect that last book should be very complete this time and not leave out such beasts as:

      Outlook Golem
      Drunk Old Liche at the Front Desk
      Guy with the Swampy Looking Keyboard
      Deletinous
  • Abridged version (Score:5, Insightful)

    by qwijibo ( 101731 ) on Monday March 19, 2007 @03:41PM (#18405797)
    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. =)
    • by dreamchaser ( 49529 ) on Monday March 19, 2007 @03:52PM (#18405979) Homepage Journal
      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...
      • by dave562 ( 969951 )
        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 have been very fortunate in my own career to work for two very good bosses. Both of them were masters of managing client expectations. The first boss recognized that I had the abilities but not the experience to get the job done. He was able to keep our department shielded from upper management as I tra

      • No, no, you've got it all wrong. Always pad your your estimates. How else do you expect to convince them you're a miracle worker [wikipedia.org]?
      • Re: (Score:1, Funny)

        by Anonymous Coward

        Not all IT Managers have pointy hair...

        Yep, just like not every clover has three leaves.
      • by jackv ( 1068006 )
        Not to mention, having the confidence to impose certain principles , such as freezing specs once the job is underway and making sure the client thinks in terms of versions.
  • What gives? (Score:5, Funny)

    by cyberbob2351 ( 1075435 ) on Monday March 19, 2007 @03:43PM (#18405829) Homepage
    Where's the chapter called "Dealing with uninformed upper management"?
    • Re: (Score:3, Insightful)

      by nine-times ( 778537 )

      Yeah, as an "IT manager" of sorts, my first thought on this was a question: is IT management really such a different process than management in general? I mean, forgetting the technical IT issues, is the management of an IT department different from the management of other departments?

      Immediately, I answered myself "yes". Two big factors that change things:

      1. those under you are probably autistic
      2. those above you probably have little/no understanding of what your department actually does
      • Re:What gives? (Score:4, Insightful)

        by qwijibo ( 101731 ) on Monday March 19, 2007 @04:05PM (#18406159)
        Correction:

        2. those above you are probably sociopaths

        This means that a good IT manager should be a autistic sociopath. At least that's my theory. I'll let you know how it works out. =)
      • by dave562 ( 969951 )
        I completely agree with number two. As I gradually transition into management I realize how much time has to be spent educating the other department heads. It usually becomes really obvious during budget time. Every department has expectations of what the computers should be doing for them. Very few of them want to place line items in their budget to enable what they want.
        • Re: (Score:3, Funny)

          by nine-times ( 778537 )

          I try to be very informative when I talk to people, but it's tricky business. As far as most people are concerned, the IT staff are a bunch of wizards that make computer magic and keep computer demons at bay. Little do they know, your computer needs daemons to work!

          • by dave562 ( 969951 )
            I try to be very informative when I talk to people, but it's tricky business.

            I know what you mean. It takes some careful calibration on your own part to communicate with upper management about technical details. It can be tricky to give them the understanding that they need without devolving into discertations about the underlying technologies.

    • Re:What gives? (Score:5, Insightful)

      by Skyshadow ( 508 ) * on Monday March 19, 2007 @03:54PM (#18406015) Homepage
      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...
      • 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...


        You're right, and it's definitely those types of upper management I am referring to. Regardless, they seem to be in the majority :/
      • by dodobh ( 65811 )
        I like the CTO knowing about network setups and stuff. I don't want him (or her) telling me how to do my job, but to communicate the business requirements to relevant people in IT management and staff, and technical issues to management.

        Seriously, it shouldn't be the CTOs job to worry about details (budgeting or technical), but they should know enough of both sides to be able to worry about those things if needed.
    • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Monday March 19, 2007 @03:55PM (#18406021) Homepage Journal

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

      You'll find that chapter here [amazon.com].

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

      Modded "funny", but you have a point. I see a lot of things in this review about managing IT work, and that includes an overload of assignments, pointy-haired bosses, and idiot customers. Is the management of geeks in such a work environment so different from managing other kinds of people in a similar environment? I don't have that much experience with managing geeks, but I have not found it hard because they were geeks.

  • by Skyshadow ( 508 ) * on Monday March 19, 2007 @03:48PM (#18405903) Homepage
    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.
    • Well, that's true - unless you're talking about about perforce. Perforce is just crap.
    • it's maturity. (Score:1, Informative)

      by Anonymous Coward
      You can't really teach those people.

      "Men are basically smart or dumb and lazy or ambitious. The dumb and ambitious ones are dangerous and I get rid of them."

      Destory their ability to advance until they realize (or you can successfully explain) that there is more than one way to do things.

      I work w/ XP, run a Mac at home (yuck) and keep my data on BSD boxes. I find the solution to the problem. Open source or closed, the solution must fix my problem.

      I use to be a Windows only guy until I ran into different pr
    • by khasim ( 1285 ) <brandioch.conner@gmail.com> on Monday March 19, 2007 @04:30PM (#18406449)

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

      Okay, you've found the people that aren't complying with the project.

      Now, find out why they aren't. This can be tricky. You don't want to TELL them that they have to (the implication being that they'll be fired, because they're probably pretty sure that they won't be). But you want to find out why they aren't using it.

      I've gone through similar instances and it was usually about protecting turf.

      Knowledge is power.

      Knowledge shared is power lost.

      Are they insecure about their skills? About their job? About the market? Or something else? Is it some reason other than insecurity? Is there a conflict in the department? Something else? Find out and keep an open mind about solutions.
    • by dave562 ( 969951 ) on Monday March 19, 2007 @04:34PM (#18406505) Journal
      I know it's not a new problem, but I've never worked out a good way to handle folks like this.

      You give them enough rope to hang themselves with, and then point out to key individuals in the organization that the person will hang themself. Then when it happens, make sure that you point your finger and tell them, "I told you so." The key element to making the whole strategy work is to make sure that you can recover for them, but make sure that the recovery isn't too easy.

      Quick antecdote. I used to work in IS for a medical device manufacturer. The lead developer kept all of his work on his local hard drive and refused to put things on the server because his perception was that the server was unreliable. We told him, and told his boss that a good portion of the information that the company relies on was sitting on this guy's 2GB hard drive (it was 1996). He refused to back up and his boss didn't have enough command presence to make it happen.

      Sure enough, the drive crashed and the company went into a panic. We told them, "told you so" and then proceeded to take their drive to the data recovery place. $2500 later, they had their data back. Not long after that, upper management decided to enforce a policy stating that all users must store their critical work to the servers so that it could be backed up on a nightly basis.

    • Yeah, I know... It's like putting a VoIP phone in front of a user and all of the sudden he forgot how to pick up a telephone receiver and dial a number. 'I'll never manage to make a phone call again!'. Some people are nostalgic when it comes to technology.
    • 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?

      It's all about respect. If decisions are made without these people, they are expected to act like sheep and go whichever way management tells them. This can very disconcerting. It's like when management make decisions about what to put into a product, but never bothers asking technical support what they think. Tech support
      • by Skyshadow ( 508 ) *
        That sort of thing is possible at a smaller company, but as I mentioned in another post I work for a very, very large company. We made the decision with the involvement of the heads of the major departments and pilot teams that they specified, but we did not make the decision together with everyone because there is no possible way to do something like that. It's just a fact of life.

        That aside, you should consider the fact that in cases such as this one the developer is not the only one who recognizes ben
    • Wait a minute.. so someone in upper-management decided that spending a few thousand bucks on a shiny new tool would be a good idea. Without asking about the opinion of those that should use this new tool? And you were tasked with executing the plan? It actually seems like you are the one who needs to change strategy. Try asking the devs that are supposed to use the new SCM system about what they think. Conversation is the first step in "handling people."

      Plus, you didn't say what SCM it was, so it probabl
      • "Buy in" happens at all the levels. Almost anyone will react negatively if they get told 'here is the new way. You do it this way now.' That goes for users, developers, managers or ... well almost anyone really.

        Now, if you'd got them involved in the actual process of speccing and choosing the new toys, you'd probably have a very different reaction, to the same end result. Or you'd have a different, and better 'end result' that _might_ mean you don't have to spend as much money on bells and whistles in the

      • Re: (Score:2, Funny)

        It can often be a big deal to switch to a different SCM system, so I agree that you should be taking an "information first" approach to the problem. Find out why the holdouts are unwilling to switch, what the impact on their project will be, etc. Then address their concerns.

        bjourne took a jab at ClearCase, but it actually is a very good tool if it is set up properly and people have a rudimentary understanding of how they're supposed to be using it. Of course, it is expensive and requires some decent hard
      • by Skyshadow ( 508 ) *
        It's not ClearCase.

        You (and several of the other people who commented) are making the assumption that we're a small organization. We're not -- the technical term for the size of my company is "holy crap that's a lot of people". So while we did identify a significant number of pilot groups and involve them in the decision that was being made, obviously we couldn't possibly involve everyone or even most everyone. Instead, we got sign-off on requirements from the heads of each of the major divisions and pil
    • by anomaly ( 15035 )
      I appear to be "one of those people." The problem is worsened by the fact that my boss owns enterprise CM, and one of my peers is accountable for adoption. The REASON is not zealotry.

      Frankly the way that tools are implemented (which my peer inherited) makes usability particularly poor. (Can't check in large files, takes several minutes to open projects, poor integration of tool with developer platform, pessimistic locking) Because of that, people on my team NEVER checked code in or out unless compelled t
      • by Skyshadow ( 508 ) *
        Our tools works well -- I have the environment it runs on spec'ed out to handle more people than my company could put on it, so we don't have performance problems (and thanks to my background in systems administration I'm ready with a "shit just happened" plan for dealing with a slowdown if one were to occur). We use clustering for the primary servers for performance and fault tolerance, the database runs on a SQL cluster and the data is all stored on a SAN, so we can grow easily and absorb a pretty signifi
        • I think that there will *always* be a community whose needs are not well served by the enterprise tool, and the organization needs to decide whether to allow departmental implementations in specific situations or whether the enterprise will run that tool, too.

          In our example, if the silly tool in place worked well enough (or even close to as well as what we're running) I'd make our group "take one for the team" and use a tool that is less than optimal for enterprise benefits. There are situations where ente
  • "It talks about not only how to write a good SLA but also how to avoid burnout in your employees." ...and you can read in curled up in bed about 10PM on a sunday night.... ...about the time your employees are going into their 14th straight hour of bug fixes, for tomorrow's 'make or break', as yet, untested software release! :)
  • by Joe The Dragon ( 967727 ) on Monday March 19, 2007 @03:51PM (#18405955)
    where is the chapter on TPS reports?
  • In a nutshell (Score:5, Insightful)

    by Skadet ( 528657 ) on Monday March 19, 2007 @03:52PM (#18405977) Homepage
    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.
    • by qwijibo ( 101731 )
      That's what works for you in your job. The old school suits didn't get where they are through results, they got there through face time. If you don't produce results, you're no longer needed. What you see as a goal, they see as a minimum level of performance.

      For someone who doesn't understand your job, whether you did a great job getting 100% of the job done well or the most visible 10% barely functional, the result is the same to them. The difference is that when you do the 10% and ask for time for the
      • You've hit it here. In the ideal world, some positions would be solely results oriented, but the fact remains that most of the current management pool made it to where they are through face time. I think we need to promote performance-based management (and I think the broader corporate world will eventually warm to it), but for now we need to live with what's offered or head out on our own.

        In order to make such ultra-flexible work arrangements possible, however, managers will need to be much more familia
    • Re: (Score:3, Insightful)

      by Jaeph ( 710098 )
      I'm a big believer in flexibility in the IT field. Relaxed dress codes, flexible hours, etc. However, your point of view seems hopelessly self-centered and extreme.

      "Results" is simply the start. I need people who are an active member of a team, who promote a friendly, helpful atmosphere. You should shower, come to work on time, keep abreast of situations, and be available.

      To put it another way, for every self-centered,"results" person, I can find someone who produces results and shows up to work on time
      • by Skadet ( 528657 )
        I understand your point of view. In fact, I've worked for people exactly like you since I've been working, and I don't think it's a bad management style to have. What I'm trying to point out -- and I think you missed this because you're so entrenched in your way of thinking -- is that while your style is good, there can be styles that are *even better* depending on the people you have working for you. If you're pleased with things now, how much more pleased would you be with a 10%, 15%, or even 20% producti
        • Re:In a nutshell (Score:4, Insightful)

          by Jaeph ( 710098 ) on Monday March 19, 2007 @05:18PM (#18407077)
          So we are clear - I'm an old-school c programmer, a SQL programmer, an oracle DBA (I've used many RDBMS packages), RHCE, and generally unix-savvy. Not boasting, because anybody who posts here has this and more, but just indicating my bonafides. Also, I now refuse to become a manager. I will be a team lead, take charge in a crisis, substitute for mgmt in a pinch, but I will not accept a post as a manger. My few-year stint as a manager was not fun: I want to keep my hands dirty.

          In the military, I would be a sergeant.

          It's not a question of my "entrenched" view. It's a very, very educated view working at a large number of clients in many business, including a number of wall-street businesses. I've done the 70-hour a week thing. I've worked with the so-called geniuses who said that they couldn't get up early (and they didn't have WoW as an excuse either). I've seen how much the night owls produce.

          It's not worth it, in every case. I'm not saying that the night-owl, anti-social types can't produce; I'm saying that for the same money you can always find someone else who can produce in the same ballpark, plus be available for team meetings, work with other people, appear in front of the client, etc.

          You are like a designated hitter looking for a job in the National League. We got lots of hitters, but can you field too?

          -Jeff
          • by Skadet ( 528657 )
            Thank you for providing a well-reasoned and experienced point of view. It has given me something to consider.

            Nothing more to add, I think you make a lot of sense.
          • Re: (Score:2, Interesting)

            by Phukko ( 841877 )
            I think it's a matter of expectations. If there is an expectation that you will be there at 8:00, be there at 8:00. I'm lucky. I work in development. For now, anyway, I'm contract and my boss doesn't mind that on Mondays I show up around 9:30 AM. I drive 3 hours to get here, since I live out of town on weekends. But guess what? I'm here till 10:00 at night. and I show up BEFORE anyone else the rest of the week, then leave early on Thursday. I get a lot done, but many of my "out of band hours" are only sp
      • by dodobh ( 65811 )
        And calling in someone early in the morning, especially when that person is not a morning person tends to vitiate the atmosphere.
    • I agree with portions of what others are saying to you, but I think the real point is that many managers don't just want "results", they want a certain sort of reliability/predictability.

      At least, I'll tell you what I, as a manager, have found frustrating about people who don't show up at 7:30. I don't mean people who literally don't show up at 7:30, but rather that don't show up when expected. If I expect them at 7:30, and they know I expect them at 7:30, then they ought to show up at 7:30. If I, as yo

      • However, in my experience, people who think they're above the rules often over-estimate their value, and it's often because they're under-estimating the value of reliability.

        Do you realize, you just pointed out how Microsoft got to where they are?
      • I do believe that your experience on the support side is a valid reason why you come in on the other side of this argument. In the support world, you're dealing with coverage against a schedule and a SLA. There, predictable schedules of arrivals and departures may be (but are not always) necessary to guarantee that adequate coverage is maintained. When dealing with developers, whose only real deadlines are the project milestone dates and deadlines, live in an entirely different world.

        Managers who want
        • Even though I work on the support side, and I agree that this may have flavored my viewpoint, that doesn't mean I've never had to manage someone who had deadline-based projects rather than being entirely reactive to trouble-calls.

          Also, I know plenty of people who think all meetings are stupid, but it can be very important for working on projects that require people work as teams. I guess it's possible that your work might be entirely isolated and require no coordination with anyone else, but most of us ha

          • You've read me too far to one end of the spectrum, and perhaps I've done the same for you.

            I'm not suggesting that we can get away from all meetings and face-time, but I have lost too many hours to meetings that are held "just because we have a weekly meeting." I think everything we do should be based on business value, whether in the office, working offsite, or in a meeting. I think that a healthy balance can be developed that facilitate alternate work arrangements for those who want them while still ack
  • IT people require lots of snacks.
  • It talks about not only how to write a good SLA but also how to avoid burnout in your employees.

    Did they mean to title the "avoid burnout" chapter "Don't promote the dumbass who looks good in a tie to advanced support, promote the guy who is smart and works hard to make your company succeed."

    Or gal. I'm not sexist.
    • fire them before they burnout and bring in a fresh batch of folk for cheaper. Of course you then get nailed on the knowledge transfer problems
  • by Awksjaw ( 1073874 ) on Monday March 19, 2007 @04:11PM (#18406221)
    I think the most important thing with any job is to be able to look back at the end of the day and have some sense of satisfaction with the work you've done. In college, I used to work construction/concrete and have laid many of foundations, sidewalks, gutters...etc; and I enjoyed the job, regardless of the crap pay, because I could always look back and see the results of my labor. Now in IT, sometimes I have a hard time looking back at the end of every day and seeing the results of my work.

    At the end of the day, managers need to let employees know that they make a difference; that they have contributed.
    • Re: (Score:3, Insightful)

      by nine-times ( 778537 )

      There was an article on /. a while back which said, basically, that workers are more productive when they feel that their work matters. Sure, sure, there are other factors, but apparently this factor has been highly underestimated. It's not always enough to know that you're being compensated through pay or other means. Appreciation (i.e. saying, "thanks, you did a good job") only goes so far. But if people really believe that there would be a big problem, or that people would suffer, if their job were n

      • The benefit of good IT work can be hard to quantify, since a lot of it is preventative (i.e. "no change" is a good result) and a lot it is only contingent (i.e. you only see it when something goes wrong)
        Well said! That one sentence can go a long way to explaining to upper management what it is that makes a "good" IT department. Just because a business network is "quiet", doesn't mean there's not a lot of work going on behind the scenes to keep it that way.
        • Yes, in every job I've had, I try to stress that point: If you can't tell that any IT work is being done, that doesn't necessarily mean your IT staff is lazy. On the contrary, it might mean we're very good.

          Along with everything else, even relatively big changes, handled properly, can be completely transparent to the users. I've had conversations (very roughly) like the following:

          PHB: Things seem awfully quiet. Do you guys have things you're working on?

          me: Why yes, as a matter of fact, we just replaced

    • I have to second that sentiment. After getting RIF'ed from my MIS job about five years ago, I went to work for a while with my uncle as an electrician's helper/apprentice, as well as doing a great deal of general construction/remodeling... just for some pocket money. I learned a lot that would come in handy for home repairs, but more to the point, the job satisfaction was incredible. We went to work at 7AM, took a half hour lunch, Miller time was 3:30PM... and at the end of the day, there was a tangible e
  • Its really quite simple if you think about it.

    I give them everything they ask for........with the understanding that they will give me everything I ask for, AND when I ask for it. Two way reliability. That is all there is too it.

    • I give them everything they ask for........with the understanding that they will give me everything I ask for...

      This is fine in theory, but I have yet to be in an organization where the IT manager is given carte blanche with budget dollars and staff resources. There are simply times you cannot give them what they want because it is not within your power, the scope of the project, or the budgetary constraints to give it to them. That's where the wheat splits from the chaff, because a good manager will be

      • I was speaking for myself, as I am the CEO of my company. This is why I can goof off on Slashdot whenever I choose. My guys know that in exchange for no excuses, they can pretty much have any toys they want. When our clients are happy, I have no problem if my whole staff spends the whole day playing on their Wii's and X-Box's, because I trust them to do their jobs 24/7 if that is what it takes to please the customer.

        So far, so good.

  • managing geeks is hard

    I am not a geek! I am a human being! :-P

  • by grudgelord ( 963249 ) on Monday March 19, 2007 @04:36PM (#18406545)
    Where are the chapters on "Managing Things You Don't Understand, with Authority" and "Second Guessing Those Who Understand It Better Than You"?

    Over the past several years I've noticed a growth of IT Management out of decidedly non-technical disciplines such as sales, architecture (as in drafting), human resources, and a plethora of other "how do I delete my cache" disciplines. If I recall correctly, I've met one Manager who had a background in IT in the last two years. While I'll be the last to deny that it is possible to move laterally into a technical discipline, in almost every instance that I've witnessed, these faux IT Managers have sorely lacked in the necessary traits and understanding to adequately fulfill the responsibilities of their role. This commonly results in a department of bitter techs and engineers slaving to overcome the hurdles of an understaffed, under budgeted department while the management boob takes the pat on the back from upper.

    I'm just not too sure how I feel about a book that has the potential to encourage yet more "non-techs" to move into a discipline they are ill equipped to comprehend, much less manage. It has nothing to do with the ability to "manage geeks", it's about the ability to manage the technology. Management plays the "geeks are hard to manage" card all to often to obfuscate their piss-poor grasp of the process of dealing with a technological infrastructure and they naturally assume that it's the "geek's" fault.

    As an added caveat, this guide could also promote the principals du jour of IT Management, which have been developed from a managerial path-of-least resistance, pass-the-buck mindset, or watch-the-bottom-line paranoia (not to imply that budget consideration isn't a valid part of the job) rather than from actual methods designed to achieve security and efficiency in regular information systems operations.

    On the flip side, if this book actually imparts the knowledge to enable individuals to develop their own management methods based on actual needs then it might be a good thing. And if all of the technical jargon and silly acronyms frighten the unqualified from other areas then all the better.
    • Re: (Score:2, Insightful)

      by MrR0p3r ( 460183 )
      At my company we have many IT managers that aren't technically saavy. They may be able to speak the buzzwords and whatnot, but they can't sit down and write code if pressed to do so. And you know what? I wouldn't have it any other way. I'd rather not have a boss question me on why I wrote this function this way when the damn thing works. I'd also rather have a boss that is fantastic at dealing with people and at least acts like he actually cares about me as a person, and not just a resource.

      If I have a codi
  • by gujo-odori ( 473191 ) on Monday March 19, 2007 @04:37PM (#18406553)
    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.
    • It depends how you see this management this. If by managing you mean control (I tend to agree with this approach), then, yes it is hard to manage geeks because it's more difficult controllling intelligent people, it's not as easy to feed them with bullshit.
      In my view the sole reason middle management exists, is that they make you do more for less, which is profitable for the company. Now if you think logically, this obviously means that engineers are more valuable assets to company than middle managment (if
      • No, by "managing" I definitely do not mean and I don't regard that as being in the definition of a competent manager. Yes, we all have to be in control to the point of achieving our goals on time and on budget, but control in the sense of keeping people under your thumb and feeding them BS, well, that's not management. That's using control-freak/micromanager strategies to conceal a lack of managerial competence.

        Middle management does have a legit role, although there are certainly middle managers who have n
    • My opinion is that if I hire someone who really needs to be "managed" I have made a mistake.

      Thats what your cattle-prod is for.
    • Serious question, and I am aware that your answer may not be applicable in all legal locales.

      How do you avoid the pitfalls of employment law that state you can't not hire(*) someone based on certain personal traits. I completely agree that personality is a huge factor, and in the roles where I've had to employ people or not, it's usually the technically able that are also the best fits all round. But it's not always going to be that way - you may have a good technical applicant who's an arse, and someone wh
      • by BVis ( 267028 )
        Don't tell the one you're not going to hire anything past "We appreciate your coming in to speak with us. We're not able to offer you this position at this time."

        If pressed, reply with: "We didn't think you were a good fit for the role."

        You're not required to say anything more specific. If they choose to try to sue you over it (on the grounds that they're most qualified) they're going to have a hard damn time proving their case without knowing everyone else who applied, their backgrounds/personalities, d
        • Thanks for pretty much confirming what I thought.

          I think it a bit odd that the laws in place to "help" applicants uphold their right not be discriminated against are very difficult to enforce, if not downright impossible unless it's glaringly obvious.

          Ah well :)

          Thanks again.
          • by BVis ( 267028 )
            I don't find it odd at all. Who pays lobbyists to get laws passed that are in their interests? Big business. Of COURSE they're going to make it hard to prove discrimination. If they were forced to make hiring decisions based on who's best qualified, they'd never be able to hire the CEO's niece's husband to run a division into the ground.
      • Re: (Score:2, Informative)

        by gujo-odori ( 473191 )

        How do you avoid the pitfalls of employment law that state you can't not hire(*) someone based on certain personal traits

        IANAL, but AFAIK there is no law that I've ever heard of that makes personality a protected category, at least not in the United States.

        Protected categories that I'm aware of include race, gender, sexual orientation, national origin, physical disability, and things of that nature. Technical skills aren't a protected category either; that is, there's no law that says you have to h

  • by dogbowl ( 75870 ) on Monday March 19, 2007 @05:09PM (#18406965) Homepage
    Anyone else think this write-up is a little lacking. Its as if the author has barely mastered 9th grade English...

    "This book gave me enough detail to talk about it."
    "I don't want to say I could not put the book down, because I could."

    I would expect this level of writing at Digg, but I've come to expect better at Slashdot....
  • 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.


    So...the author started managing in the 1950s?

  • by wsanders ( 114993 ) on Monday March 19, 2007 @06:38PM (#18408101) Homepage
    I have never had an IT manager that has spent less than 10 times as much time managing the whining, crybaby, obnoxious users ("customers"), as managing technical talent. Unless the technical telent are idiots or sociopaths, that is, which occurs some of the time.

    But mostly the job consists of drawing fire so the technical telnet can do their job, and I am eternally grateful to my better IT managers for doing that.
  • Select your developers very carefully because top-notch developers are 100x as productive run-of-the-mill developers. Make sure the users/customers goals and tasks are clearly understood by the team members. Usually by sitting down the developers and end users in a room together with a little bit of structure. Then, get out of the developers' way and do not let untalented bozo's from other teams suck your team's time. Test. Test some more. Read their code. Automate tests if you must. Keep testing.
    • Sure you want the developers talking to the users? That's the designers' job and should be distinct from the developers' job.

      Developers should code, not design, and especially not test. (I note you didn't say that they should do the testing, but it bears mentioning).
  • Obviously not a tech-oriented guy. The Dino Book was the only textbook I've enjoyed reading in University. It's a collection of great ideas, page after page. Nothing boring about that. Operating systems are the culmination of architectural ingenuity (at least as far as software goes).

There are never any bugs you haven't found yet.

Working...