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

Rubber meet road.

[Anonymous Coward]

"It talks about not only how to write a good SLA but also how to avoid burnout in your employees."

Simple really. Keep fast cars, and fast women away from them.

ILM

[nine-times]

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

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

Re:ILM

[Anonymous Coward]

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

My thoughts exactly. I hate people who use acronyms that are already in common use elsewhere. Acronym overloading is bad because it is even more confusing than plain English.

Re:ILM

[Stile 65]

Information Lifecycle Management. :)

Re:ILM

[Anonymous Coward]

Pfft!

Making worthwhile PowerPoint presentations. That's the only way to get the big budgets.

Re:ILM

[Anonymous Coward]

ILM

I Like Macros

Re:ILM

[Anonymous Coward]

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

My thoughts exactly. I hate people who use acronyms that are already in common use elsewhere. Acronym overloading is bad because it is even more confusing than plain English. I agree, AO is very annoying. Do we need to use acronyms for everything?

Re:ILM

[Anonymous Coward]

Idiot Lackluster Morons.
Let's hope there's a balanced view on all of this:

If you're on a project and meeting the scheduled milestones and suddenly...someone decides if you can meet the milestones without killing yourself, let's cut the calendar a bit shorter and all people have to do is work a little harder & faster. Of course, they go to their boss and point out how they've guided things ahead of the original date.

There are far, far too many death marches in the industry. And for the most part, it's those in charge vs. those at the keyboards.

In terms dress code, personal touches, it seems management wants people to be creative and figure compromising with the infamous business casual is the way to go.

There are just as many morons who want to be in charge and make a crash & burn out of their report.

You could almost bring someone in who is fresh out of school and took a couple of classes in college and do better than most of those around now.

Tech managers (now) seem to be like s sport coach: they played in the sport for a small number of years...enough to know what's really going on with players, mgmt, etc. then want to become mgmt. Personally, using that model in the tech world means those who weren't good enough to cut it after three or four years and figure they can always go into mgmt.

Re:ILM

[The Angry Mick]

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

Have you seen their server farms recently? ;-)

Re:ILM

[PPH]

Come on. Haven't you had to demo a product for upper management? Its all smoke and mirrors.

"Pay no attention to the man behind the curtain."

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...

Re:Abridged version

[dave562]

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 transitioned from well rounded hobbiest into network administrator for ~50 workstations and 5 servers. Granted I stumbled through a few things, but at $10 an hour as an 18 year old college student, what did they expect? =) My second boss was a pro at speccing out scope of work, and making sure to pad the estimates. Our estimates were almost always on the high side of things, but we came in under budget and ahead of schedule 99% of the time. The other 1% of the time is the reason those schedules were padded in the first place... Things don't always work the way you want them to. It's better to give yourself some extra time that you don't use, than to need extra time that you don't have.

Re:Abridged version

[nine-times]

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?

Re:Abridged version

[Anonymous Coward]

Not all IT Managers have pointy hair...

Yep, just like not every clover has three leaves.

Re:Abridged version

[jackv]

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?

[cyberbob2351]

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

Re:What gives?

[nine-times]

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?

[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.

Re:What gives?

[JaredOfEuropa]

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.

Re:What gives?

[qwijibo]

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. =)

Re:What gives?

[cyberbob2351]

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 :/

Re:What gives?

[dave562]

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:What gives?

[nine-times]

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!

Re:What gives?

[dave562]

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?

[Anonymous Coward]

In the late 80s, I remember quite well when a new software system geared for hospitals (SMS) was in progress of migrating to an inhouse.

IT management examined all of their options. They had a good deal with the 3270 budget, but...IBM offered to match any competing offer for PCs. IBM also had to go to their BOD to deal with supporting 3rd-party hardware in an IBM-only box. That passed. It was one of the few times it had been done (if at all). The idiots went to the executives to put together a plan and obviously slanted their presentation.
They figured the 3270 deal was so tempting it wasn't worth dealing with PCs
When TPTB sat down and looked at their options, they figured they'd go for the 3270s.

Within the next twelve months, each of the 3270s had to be replaced because of inherent defaults: someone screwed up on the assembly line. (or so we were told)

IBM then offered to let the hospital field test a new digital system which could keep all of the various x-rays & whatever other info was available. IBM offered to provide service (for free) and make sure the hospital was current for some undetermined period of time. Whatever it was, it was good. (I'm just not remembering how suh-weet it was. The hospital turned it down. Several departments (including IS|IT|MIS) were turned down for expansion because they brought all of the x-rays from wherever they had been so life would be easier. IS shared a wall with this archive. Was IS allowed to expand? (are you kidding? no, they didn't take down that wall. They're still where they were when I left in '90) This is one of the larger hospitals in the city.

I've got a dilly of a story about how they were willing to write off some errors in order to balance the books during their quarterly deadlines. Two consecutive quarters.

I'm of a firm mind those who wear ties, particularly those who do so willing to do so, and even worse, those would wear a suit & tie to paint their house if their wives would let them: the ties cut off oxygen to their brains.

I'm just as baffled by those operations which require their IS people to wear suit & tie, despite the fact they don't deal with anyone outside of the department and no one visits the department. Casual, not Business Casual (Dockers & golf shirt) should be a perk.

Re:What gives?

[Anonymous Coward]

Our management relies real heavily on this
here

Re:What gives?

[Anonymous Coward]

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.

Whenever people start ranting about the huge sums of money wasted by the government, on massive failed projects, I like to point out the the private side does exactly the same, just is better at keeping it quiet.

My company canned a project after seven futile years and half a billion dollars. Right now, another huge project is being quietly phased out ... a couple of hundred million over the last five years, and it will probably suck back another 100 million in the next couple of years before it finally gets completely decomissioned.

It's not that management doesn't listen to the people they hired ... there's an unfortuante problem where the people who can present the best are listened to. So some idiot who spends 99% of their time on PowerPoint and MacroMedia presentations gets listened to more, by upper management, than someone who spends 10% on presentations, and 90% on actual management.

Right now, frex, one of the lead *architects* of the above two failures is currently working on the latest, all encompasing program. I thought the project had a chance, until I learned Mr. Kiss of Death was associated with it. Crap, I just got his latest PowerPoint ... I'm guessing it would take me about three weeks to put something like that together. I could do a lot of coding in that time ... but what's the point?

Management listens to the people who have mastered the art of saying what Management wants to hear, while quietly advancing their own agenda (which, most of the time, means either padding their own pockets, or getting promoted (the Peter Principle at its finest)). Witness the huge success of consulting firms like D&T, KPMG and their ilk.

And I'll second the comment about sociopaths. One of the things keeping me out of upper management is an inability to lie. "I'm sorry, you're performance is just acceptable ... here's your cost-of-living raise" is so much easier to say when it's true, rather than having your manager tell you "I don't care that you've assembled a team of ace programmers. The department raise level is four percent, and we've had to give six to Bert's group, 'cause the CFO went to school with Bert, so you've got two percent to split as you see fit." I actually walked away from a $98/hr job, after being told things were "tight", and being held responsible for something completely outside my control (i.e. the company lawyers screwed the pooch on the wording of a contract). Followed, a week later, by the company president sending an e-mail congratulating everyone for a record profit year, and special kudos to my group.

When the company CEO fights like hell to have stock options NOT recorded as liabilities;when stock options given to people in the top few tiers are worth tens of millions every time they cash them in;when a couple of hundred peons are dumped, for the incompetent decisions of management ...

Actually, sociopath is the wrong term. Large corps are run for one purpose only ... lining the pockets of the board members, and that is primarily done through stock options. Canning a few hundred workers? Raises stock prices. It's a theory that seems to work. And, sad as it seems, making jokes about how the market will react positively to a new product almost guarantees your project will get funding. Lying is rewarded immediately ... failure ... well, the company doesn't really want any news released that could adversely affect their stock value ... just remember to jump ship before the final collapse.

What were those final points? Punishment of the Innocent, and Praise for the non-participants.

Re:What gives?

[dodobh]

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.

Change Management?

[Anonymous Coward]

I knew what change management was, but I needed more than a buzzword before I met with my boss.

Then, after you met with your boss, you discovered "change management" is just a fancy euphemism for "panhandling" -- the eventual sad fate of most IT managers in the USA.

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.

Burnout..

[D-Cypell]

"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! :)

where is the chapter on TPS reports?

[Joe The Dragon]

where is the chapter on TPS reports?

Re:where is the chapter on TPS reports?

[AKAImBatman]

Right here:

http://standards.ieee.org/reading/ieee/std_public/ description/se/829-1998_desc.html

(For those who didn't know, yes they really exist.)

Re:where is the chapter on TPS reports?

[aztektum]

I have a friend who works for a large insurance company and he actually runs TPS reports. I don't know what the hell it stands for and since he's in the IT department, I don't think it has to do with the insurance stuff. Probably just a nickname those wacky IT guys used.

Re:where is the chapter on TPS reports?

[AKAImBatman]

IEEE 829 - "Test Procedure Specification"

It's a "standard" for software quality control. A bit like the ISO 9000 certification that Scott Adams likes to make fun of. :)

Re:Everybody IT needs these skills, not just bosse

[Scott Lockwood]

Well, that's true - unless you're talking about about perforce. Perforce is just crap.

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.

Re:In a nutshell

[stratjakt]

You may be a prima donna diva who's so scary talented to get away with that.

All this "different way of working" is bullshit, you want to sit at home and scratch your nuts, and get the same amount of pay. You think you're a valuable asset, despite the fact that you obviously lack any sort of interpersonal skills.

Well, wake up, sport. High level boxed apps are taking over, and we've reached a point where almost anybody can write enough "code" to get what they need done.

What the workplace is looking for is motivated professionals, who are pleasant to work with, not condescending, and are comitted to the job.

You're going to find it harder and harder to get payed to sit at home noodling on some C function. The workplace doesn't work that way, never did, and never will.

You are less and less necessary every passing day, as the average employee picks up more and more computer skills. Your technical skills will not carry your career on their own. Get the fuck out, show up 15 minutes early. Impressions are everything. The guy who's consistantly late looks like he doesn't care, he's not the guy you count on, he's not the guy you promote to a position of importance.

Or get all haughty and look down at everyone else, and assume you're more important. Doesn't matter to me.

Re:In a nutshell

[qwijibo]

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 90% still left to be done, they dismiss you as not understanding the business needs.

Since they don't care if your results are wonderful or mediocre (they're the same thing to them), they rely on what they know. If face time is their measure, you'll be gauged on that regardless of anything else you do.

It's not a good system, but it's one that's quite common. Your options are to find a job where they genuinely care about results, be a consultant where results are exactly what the customer is paying for, or learn to live with it. Learning to accept that things don't work the way they should is a decent tactic until you get one of the more desireable positions.

Re:In a nutshell

[jedidiah]

That all just sounds so... 19th century.

Re:In a nutshell

[Jaeph]

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 without excuses, and is good asset to the whole team.

-Jeff

Re:In a nutshell

[Skadet]

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% productivity boost? Just because a lot of people are awake from 9am to 5pm doesn't mean that's when all of those people have their peak production times. It simply makes no sense to correlate the two.

I think it also depends on the job. Support staff? Forget about it, you've got to be there 8 hours. A team of 1 assigned to, say, transfer a very large database from FileMaker to MySQL? I see no reason why not.

I love it when I can live an integrated life with my job and my non-job components. I was downsized last year, and spent a few months freelancing -- those were the best few months of my life. I could be watching a movie, get a call from a client, and spend billable time with him on the phone while making dinner. Then, I'd stay up till all hours of the night working on his projects, taking breaks to mess around in GarageBand or whatever. Things got done, they got done right, and quickly, and I have nothing but positive recommendations from those clients.

Now that I've typed all that out, it seems like freelancing is the way to go.

Re:In a nutshell

[Skadet]

You are less and less necessary every passing day, as the average employee picks up more and more computer skills.

This morning, an employee needed my help logging into Windows because her "delete" key was "missing".

I don't know who your average employees are, but the ones I support are attorneys.

Re:In a nutshell

[511pf]

You are less and less necessary every passing day, as the average employee picks up more and more computer skills.

Hmm...satire, or someone who's never worked with end-users? Tough call.

Re:In a nutshell

[Jaeph]

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

Re:In a nutshell

[nine-times]

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 your manager, show up when expected, I expect the same from you. If you want to negotiate for a later time to start work, I might be open to that, depending on what I view your job responsibilities to be. However, whatever your start time, I'd like you to be at your desk at that time.

If I have a meeting, I want you to show up on time. Being late may not hurt your productivity, but it hurts everyone else's productivity because we're sitting around waiting for you to show up, or spending our time trying to figure out where you are.

I'll admit, I'm not on the programming side of things, but instead on support, but I'll tell you that I'd prefer a single reliable guy who does what's asked of him, or at least does what he says he'll do, rather than 3 geniuses who are unreliable. I was once considered a bit of a boy-genius myself, and that's great for some things, but one of the first things I learned in my professional life is that, for a lot of purposes, being methodical and reliable are much more valuable to a manager. It allows managers to plan, since they'll be able to predict just how much work they'll actually get out of you in a given span of time. It lets them figure out their own work without worrying about whether you're really doing yours.

Contrary to what you some people think, managers often do have their own work beyond cracking the whip on underlings. Whether they do a good job is a different issue, but a good manager has plenty to do without cracking whips. I'll say this in favor of your position: part of what a good manager does is keep moral up and enable worker productivity. Being overly strict and inflexible hurts moral and can inhibit productivity. 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.

Re:In a nutshell

[Skadet]

Well, it just so happens that I'm not good at hiring people that aren't good at coming in at 7:30.
That's fine, I wouldn't want to work for someone with such arbitrary standards anyway.

It's a numbers game. There are thousands (tens of thousands, hundreds?) of people that are more talented than you; AND they are willing to show up to work on time and put in a full day of productive labor...maybe even work for less.
Doubtful, mostly on the "working for less" part. Possibly on the "full day of productive labor" part. Agreed on the talent part, but salaries in my range go up very, very quickly as the employee has my skill set. The next highest 2% skill-wise make around twice my salary (as I learned when I was looking into jobs I was *just barely* underqualified for).

You have a mighty high opinion of yourself to think you have any leverage in this world.
Who said anything about leverage? I'm just astounded at the manager-types here blowing a gasket when an employee-type dares to think outside of commonly-accepted paradigms that are designed to enslave the worker. You argue that there's one right way to do it, and you believe yourself. You're small-minded. You are a victim of an education system that was designed to make you believe you had to grab your ankles in order to get anywhere in the world.

I learned that with little exception, an employer works to sqeeze as much productivity out of their employee as they can, for as little pay as they can, for as long as they can, and then when that worker's dried up, toss them out and grab a new one. Not for me, thanks.

Re:In a nutshell

[Skadet]

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:In a nutshell

[Anonymous Coward]

I tend to believe along these lines also.

I've over 15 years of experience working as senior IT and management for companies ranging from start-ups to Fortune 5. And frankly, the companies which are on my all-time favorites (and which set employee retention and loyalty records) were the ones which advocated the concepts of "core hours" and "flex time". Most of these were family owned and oriented, but there was one Fortune 5 (at the time) company which was like that also.

These were also the companies which not only advocated telecommuting, but installed the infrastructure to support it. My most recent company really went hog wild, with a VoIP system which had softphone software (and when available, IP phones) and a rock solid VPN.
People never knew you weren't in the office (and considering we had three sites, "face time" wasn't an issue).

And lack of productivity certainly wasn't an issue. In fact, we discovered that for many processes, productivity increased (in most cases, the length of time between instantiation and completion) for those telecommuting. Meetings were far more efficient, as they were scheduled and people would come in far better prepared. In promptu meetings, we found, were a major time waster. By supporting telecommuting and flex-time/core-hours, we discovered employees focused far more upon processes, rather than fighting fires (e.g., scheduling a meeting for every little thing).

Eh, to each their own.

Re:In a nutshell

[layer3switch]

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?

Re:In a nutshell

[Phukko]

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 spent on MY projects, so I'm unavailable to mentor / help other team members. And THAT is probably what will keep me fromgoing permanent here. The perception is created that I get my stuff done, but that's it. And for the most part, the perception is accurate, except for the times other team members stay late and come by my office looking for help, I gladly give it.

Re:In a nutshell

[Anonymous Coward]

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. Well gee, good for you.

But keep in mind that many in IT actually have to develop complex applications in complex, dynamic environments -- environments that necessitate, well, actually interacting with one's peers. Hey, it's great if you're handed a good functional specification and can go heads-down on it all on your lonesome, but it that's the only structure you feel comfortable in then you're ultimately limiting yourself. All the recent data show that the ultimate quality of a software product depends heavily upon the quality of communications that take place while it is being developed. Some of the best development methodologies -- like Agile development -- are actually more about the communications than the code.

Also keep in mind that application development -- coding -- is only one small piece of "IT." The broader picture of IT involves the creation, delivery, and operations of services. The lion's share of IT is probably service delivery. Delivering services to the consumers, both internal and external, of those services. You know, the people who where characterized by one not-particularly-insightful poster as the "whinney, obnoxious users."

There has been much lamenting in this topic that management doesn't understand the technologists. But having sat on both sides of that great divide, I can assure you that the misunderstanding flows both ways; the technologists tend not to understand management or the larger business perspective. I would hold your post up as an illustration of that.

Re:In a nutshell

[Anonymous Coward]

Become a Consultant. Then all these drawbacks (asocial, ill dressed, arrogant & ignorant) are positive attributes, if not positively required. The part where you had mad zkillz is no longer required.

Re:In a nutshell

[dodobh]

And calling in someone early in the morning, especially when that person is not a morning person tends to vitiate the atmosphere.

Re:In a nutshell

[HikingStick]

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 the type of reliability you describe are working on an industrial-revolution-based (i.e. nineteenth century) model. Do people need to show up to meetings on time? Yes, but why do they need to be in the office at 7:30 AM? If they have a meeting, sure, but what's the purpose of the meeting? Is it so an old-school manager can micro-manage and tell his team what they will work on that day? Another response cited the need to be available to connect with other staff and systems that may only be available during traditional hours. That may be true, but why can't an employee touch base with others via phone, email, or IM? The big issue must be whether or not the work is getting done, not necessarily how the work is getting done.

If, as a manager, you don't know if your "work-at-home" employees are producing at an appropriate level, I'd wonder if you have a realistic picture of how any of your employees are producing. If you think that your traditional employees are more productive just because you see them in the office and meeting with their peers, you're in for a shock.

Re:In a nutshell

[HikingStick]

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 familiar with the jobs of those they manage. Otherwise, how will a manager know if the amount of code (in lines, objects, or other deliverables/milestones) an employee produces is in line with the time they claimed to work?

Here I break with some of the proponnents of such non-face-time work arrangements. Some in that camp may argue that it does not matter if it takes me only four hours at home to do something that might take me eight hours in the office because the goal is reached in either case. If as a manager, however, I know you can code in half the time of some other office-based employee, I might expect twice as much code from you rather than that you both produce the same amount regardless of the time. In such circumstances, what is really wanted is something like an industrial piece-rate (e.g., earn $x for each garment sewn). If they are getting paid by the deliverable (like most consultants), than it is a fine model. Most employees (if salaried), however, are hired with an assumption that they will give the company a core number of hours each week in exchange for their pay--it has nothing to do with deliverables! That's one of the main factors that the old-school of management still plays when looking at these issues (even though, in my opinion, they play it only when they are not willing to trust their employees).

Re:In a nutshell

[HikingStick]

You're missing two factors that actually may push the industry toward some of these sit-at-home-scratchers and away from the face-time crowd: globalization and facilities costs. I know it may sound like a lame card to play, but the globalized economy means that some programmer's preferred core hours (e.g. 11 PM to 3 AM) may sit smack in the middle of some other team's workday. Also, virtual presence technologies and a realization that many aspects of development projects are not linear make development one of those jobs that fits this new model. I have a friend who wrote code for a major US Bank. Most of his coding work was done overnights and on odd weekends. He still made his face-to-face meetings when they came up, but there was no practical business reason to constrain his working hours to 8 AM - 5 PM Monday through Friday.

The other factor that is not getting much press is the cost of maintaining commercial real estate. Every employee you can push out the door (to a cybercafe or home) saves a quantifiable number of dollars every year. There are no longer any costs for wiring a floorbox, providing lighting or electricity, water and sewer, HVAC, or cafeteria services. Unused floorspace can be reclaimed for other uses, or leased out to other companies. I've already seen offices with large numbers of traveling staff get rid of designated offices/cubes--now floor space is on a first-come-first-served basis. In my last workplace I estimated they could save over $2,800 per year for every employee that works from home full-time (and that's after factoring in increased costs associated with increased remote access support).

It will be interesting to see if the decentralized model gains in popularity. My guess is that it will not happen (broadly) until the current generation of managers ages and dies. Until then, some companies (e.g. Best Buy) will forge ahead and experiment with a decentralized workplace.

Re:In a nutshell

[mrjohnson]

You're out of your mind. The average user may be learning some more about installing video games and downloading music on the web. But many are even less interested in programming and the actual internals of computing than generations before them, even though they've grown up with computers and are comfortable.

I think this is probably caustically related -- the computer is no longer special and no longer gets the "cool" factor it once demanded. Look at the enrollment for Computer Science degrees falling. Regardless, the need for skilled programmers is not going away.

You seem to think languages are getting easier, so easy that skilled hackers are no longer useful. That their creativity is not needed, but they are just a cog.

I'll agree that some things have gotten easier. Where in the past you might have created a massive and difficult client program, you can effectively put many things on the web. However, programming on the web has become a whole matter much more complicated than throwing up some HTML and Javascript menus if you've been struck by a creative moment.

Yes, we spend less time "noodling" C functions. But a whole lot more time integrating libraries, templates, databases. The size of the project, including 3rd party code, is huge... and always growing.

Also, the number of people in the world who are even halfway good at programming, or hell even interested in it, is small. I don't think his asking for a little 15 minute leeway in the morning or some time away from the office is a big deal, as long as the code is there.

Re:In a nutshell

[nine-times]

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 have to work with others somewhere along the line, and I've seen what happens when we don't have regular meetings.

The results are hard to quantify, but they're noticeable. Getting everyone together in a room, face to face, and hearing each other describe their status/progress-- it ends up raising issues that otherwise go unnoticed. If we don't have meetings, someone ends up going off and solving things "in their own way," which inevitably causes problems for someone else's portion of the project. Or, they just chug away for a while working on a solution that someone else on the team already knew wouldn't work. It ends up being a big waste of time to *not* have meetings.

IM/email/phone aren't really good substitutes. First, you can learn a lot from people's faces and voices. When one of your workers asserts a deadline, for example, it helps to be able to ask your questions right then, and be able to gauge his confidence in the deadline by his face and voice. Also, even being on the phone, people tend to do other work at the same time. They read things, go on IM, etc., and you don't get their full attention. Finally, if you actually need teamwork, it just helps to get everyone in a room and make sure everyone is getting along.

I think you're just looking at the wrong layer of "work". You're just thinking, "I can get my work done without any rules, and so that must be good enough!" Sometimes that just isn't good enough, because your manager might be looking for more than that. If your work isn't isolated, sometimes you actually have to work with other people, and work on common ground, in order to get things done properly, efficiently, and predictably.

Re:In a nutshell

[HikingStick]

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 acknowledging the team aspect of much work. Although I have enjoyed my work-from-home positions, with kids at home there are often times where I would rather be in the office and away from those distractions. I do believe that most of our current management model is outmoded, irregardless on one's position on alternative work schedules, but I am also opposed to throwing away the baby with the bathwater. Those alternate work schedules are a perk desired by many people, so I find them as a valuable tool. As long as people are not abusing the perk, I'll continue to advocate for it.

One important motivator

[Hoi Polloi]

IT people require lots of snacks.

did they mean...

[farker haiku]

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.

Re:did they mean...

[The Great Pretender]

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

it's maturity.

[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 problems.

A humble suggestion

[Anonymous Coward]

>> how to avoid burnout in your employees

Dump the marketing department.

Re:A humble suggestion

[HikingStick]

Based on the fact that no one modded your comment up as funny (if not insightful), I'm guessing that no one else undestands how it feels to have a moving target. "Build this," they say, only to come back later saying, "change this part," "add this feature," or "start over."

In reality, it is less a problem of the marketing department than of having a poorly designed project plan and scope. If the scope is not clearly defined, groups like marketing departments (think they) can come in an make changes anytime up to the release date. I wish more senior managers and project managers would stand up to the tyrrany of the moving target.

Alternate readings ...

[Anonymous Coward]

I have been a longtime subscriber* to the BOFH manuscripts, located at 'the register .com' and other places throughout the web. I find the coverage of topics related to IT to be quite plentiful. The list covers:

- DataCenter Emergency scenario's
- Business Relationship Mannerisms
- Positive Work Environment Guidelines

and

- Understanding The Company Ladder

all to be quite clear in content.

As always, the learning curve varies across the board, and if you find yourself 'lagging behind' in some of the text, I suggest some 'training sessions' with fellow 'co-workers' to really get a grasp of the intended message.

This information is a 'use at your own risk' entity so considered yourself warned after reading ANY word of this text.

Sincerely,

A.Coward
CYA Ind.
101 1st Pub St.
London,
W TF RYT

Didn't you get the memo?

[spun]

Mmmmm, yeah. We sent you a memo about the TPS reports. Everything about the TPS reports goes in a new chapter. Are you looking in the new chapter for the TPS reports? Yeah. If you could just go ahead and make sure to look in the new chapter from now on, that would be great. And, uh, I'll just go ahead and make sure you get another copy of that memo, mmmmm, ok?

Find satisfaction in work

[Awksjaw]

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:Find satisfaction in work

[nine-times]

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 not done properly, they're more likely to come through, they'll work harder, and they'll do a better job.

At least, that's a hybrid of the article and my own experience. I know I feel it sometimes. I realize sometimes that, at the end of the day, I've just shuffled some bits around, flipped 1s to 0s and vice versa. I've spent a lot of time making backups that are just going to be overwritten when no disaster occurs. 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). And to top it off, if you do a good job with the preventative side, things are less likely to go wrong, and you'll be less likely to see a payoff from your work on various contingencies.

So I guess I'm saying that, if you're a manager, try to keep in mind that you're employees might have a hard time with job satisfaction.

Re:Find satisfaction in work

[Norwell Bob]

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 end result of the day's labor. Something to look at and be proud of... a job well done.

Now I'm back in IT, and to be honest I often pine for the days of being covered in sawdust and sweat, tired from non-stop manual labor, and feeling like more of a man at the end of the day for having BUILT something REAL and SOLID that would likely be standing for the next 30+ years.

If I could have afforded to live on the poor pay (for a while, until I started moving up the ranks), I think I would have stayed there... but, alas, with a wife, kids, and mortgage to think about, I was already in too deep and had to find better-paying work in computers.

But, you know the end of Office Space, when Peter is working with Lawrence (the neighbor, that's his name right?)... and Peter is just totally refreshed in his new career in the trade? Yeah, it really did feel like that.

Stupid bills.

Re:Find satisfaction in work

[The Angry Mick]

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.

Re:Find satisfaction in work

[nine-times]

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 the e-mail server last night. Everyone is operating on a new server.

PHB {looking skeptical): Really? Hmmmm... I hadn't noticed.

me: Exactly. The guys did a great job. You shouldn't really see a difference.

PHB: Huh...? If it's no different, why did you do it then?

me: ...because you would have noticed a difference if we hadn't moved it. The mail server would have stopped working within six months.

PHB (again, skeptically): Why's that? Shouldn't those things just keep... running?

It goes on, but you get the idea. Some of the best IT work is planned carefully and executed methodically, specifically so that no one can really tell the difference.

Managing Geeks 101

[LibertineR]

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.

Re:Managing Geeks 101

[Anonymous Coward]

Actually, this comes pretty close to my general job description. My job is to make my boss look good. The best way to do this is to make sure there are no surprises: give honest time estimates, give regular status updates (even if only informal), stay awake at meetings, etc.

The key is that my boss' job is to make sure I have everything I need to do my job. This includes running interference (no unnecessary meetings, defend against technical stupidity, etc.), getting my input early in planning discussions, and providing opportunities for education.

A little off topic, but I have been thinking that a big problem with management structure is that it is top down. Unless you have a really good manager that can handle honest criticism, there is no way for feedback to go up the chain. I think that performance reviews should go in both directions. This way, the team is evaluated, not just the workers.

Re:Managing Geeks 101

[HikingStick]

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 able to keep staff motivated even when the staff can't get everything they want.

Of course, if you are always telling them "no" you are asking for mass desertion. I find that being open about the reasons for a decision can make the difference between a subsequent moan-fest and employees who know I still support and appreciate them even if they are not pleased by the current circumstance.

Re:Managing Geeks 101

[LibertineR]

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.

Blow me

[Quiet_Desperation]

managing geeks is hard

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

Re:Blow me

[Anonymous Coward]

Ironically, "I am not an animal, I am a human being," was the cry of a professional geek, the Elephant Man.

Re:Blow me

[Quiet_Desperation]

Yeah, that *was* the intended reference.

Try to find out "why".

[khasim]

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.

Re:Everybody IT needs these skills, not just bosse

[dave562]

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.

You too can become an IT Manager

[grudgelord]

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:You too can become an IT Manager

[MrR0p3r]

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 coding question, we have technical leads. If I have a question about what I should do because my cube-mate keeps undressing me with her eyes, I have my manager. Two different roles, two different people. Works great.

That doesn't mean we don't have managers who can't be technical leads, but the technical leads don't always have management skills.

Re:You too can become an IT Manager

[Anonymous Coward]

No other professional group treats management with more distain. Technical Management is as legitimate a career choice as being a Sr. Software Engineer or an Architect.

You'll never see a CPA or Law discussion board where people describe Partners as "PHBs".
You'll never see a Marketing guy say a Director or V.P. position is "selling out".
You'll never see a Financial Analyst saying a Controller or CFO position is worthless.

Too many IT workers think management are all PHBs who (if they ever were technical) "sold out" to go into management. Until this attitude changes, and good technical staff see management as a viable career path, you are going to get non-technical people filling these positions.

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.

Re:Geeks hard to manage? Since when?

[elh_inny]

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 they weren't, it'd more cost-effective to not to hire management and have geegs slack off all day). Now what I fail to understand is why such managers get paid more and get the cut and the credit for what the engineers did, but that's just me whining...

Re:Geeks hard to manage? Since when?

[myowntrueself]

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.

Re:Geeks hard to manage? Since when?

[gujo-odori]

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 no really good purpose in an organization (I've worked under at least one like that). With that said, in defense of middle management, I have to say that being a good middle manager is hard, much harder than being a good first-line manager (my own level of experience). Some of the main duties of a middle manager are to be an information conduit between upper management and first-level management, and to make sure the first-level managers and their teams are meeting their objectives.

When you have good upper management and good lower management, being a good middle manager is a lot easier. If one or both of those is not so good, it gets a lot harder. If you're a middle manager and you have one or more teams that are behind, understanding the problem and taking the correct action to fix it is when the good middle managers show themselves as such, and the others, well, don't.

If the good ones will succeed, the bad ones will always act as more of a communications obstacle than a conduit, and if the problem is with either them or senior management, they will pretty skillfully manage to pin the blame on the first-level managers and their staffs. Not that I've seen this happen, or anything.

While many companies may have what looks like too many middle managers, they exist for the same reason an army has levels of officers between 2nd lieutenants and generals: there are only so many direct reports any one person can handle, and only so many details any one person can pay attention to. If a CTO of a large company had to personally manage every team manager and oversee their projects, s/he would have no time to do the things that CTOs are tasked with. Even in a small company, that can be true. At one place I worked we had fewer than 100 people when I joined and fewer than 200 when I left, but even there I had a level of management (the director of development) between me and the CTO. That worked well. Later, another level of management was added in there between the DD and the CTO, with a VP title. In terms of competence he was somewhere in between a good one and a bad one. At the end of the day, I don't think he really contributed all that much. A VP in that spot might have been necessary but I would have preferred a better one.

Re:Geeks hard to manage? Since when?

[gfreeman]

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 who's less qualified but you are sure would increase the productivity of your group. How would you justify employing contestant number 2 and avoid a potential lawsuit from the on-paper-more-qualified applicant?

(*)Sorry about the double negative.

Re:Geeks hard to manage? Since when?

[BVis]

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, detailed specifics on their skill sets, etc. Unless they've got deep pockets, they're not likely to find a lawyer to take their case, unless there's clear discrimination against a protected class (ie race, national origin, sex, orientation, religon, etc., and even then it's notoriously hard to prove.)

If someone is an asshole, that's just as good a reason to not hire them as a gap in their skill set. You're not required to explain yourselves. Employment law is heavily biased towards the employer in the US, when compared to other western countries. In an "at will" work state, you can be hired or fired for any reason, or no stated reason. I doubt there's much exposure to a lawsuit here. IANAL.

Re:Geeks hard to manage? Since when?

[gfreeman]

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.

Re:Geeks hard to manage? Since when?

[BVis]

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:Geeks hard to manage? Since when?

[gujo-odori]

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 hire the most technically qualified person[1], without regard to other factors. If you sue because you think a less qualified candidate was hired over you (and generally, you'd have know way to know; no company will tell you anything about any of the other applicants), you probably wouldn't have a chance. If someone were going to try that approach, they better also be in some protected category and claim "They didn't hire me because I'm _______" instead. And then, they'd better hope the company isn't filled with people in the same category. Being in the San Francisco area, which is extremely diverse in every way imaginable, I expect we could deflect any kind of claim like that easily.

In at least one instance, I passed over someone with a graduate degree for someone who didn't even have a degree. He was a self-taught programmer with little formal education in the subject, but was very sharp and had written a well-regarded BASIC library for gaming. He was a terrific addition to the team on both the technical and personal levels, and no one (not even HR) questioned why I wasn't hiring the guy with the master's in CS. I told my boss "This is my pick" he did a short second interview himself, then signed off on it. If there was anything wrong with that, I'm sure HR or Legal would have said something.

[1] There may be different rules on this for managers at government agencies; I once applied for a job at a county government (looking back, I'm very glad I wasn't hired) and took what was basically a civil service exam for mainframe computer operators. In that kind of environment, I imagine a manager's hands might be a lot more tied WRT who they can hire. Even then, if the most technically qualified person is not in a protected category and the person you really like is, then you're probably gold.

Re:Everybody IT needs these skills, not just bosse

[slashflood]

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.

Review of the review

[dogbowl]

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....

Re:Review of the review

[Anonymous Coward]

hi, you must be new here

Re:Review of the review

[weeboo0104]

Anyone else think this write-up is a little lacking. Its as if the author has barely mastered 9th grade English...

The irony is so delicious, it simply has to be fattening.

Re:Review of the review

[Laserwulf]

You must be new here...

Re:Everybody IT needs these skills, not just bosse

[Chacham]

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 knows what's in the field, and what would really help. If management cared to help, that'd be where they'd address they're first round of questions.

The question here is why they need to use the tool. If it is because management wants to hold onto code, i don't think the coders are averse to storing it. But using it as they revisioning system and using it daily, is not something they'd like to do. So, work something out. Have them check it in once a week, and use they're own favorite tool in the interim. Also, the manager should do the chcking in. Don't pass the buck onto the coder for something he sees no dbenefit from. If the users are being expected to use the revisioning system for their won good, why were they not asked their opinion first?

All in all, most people are team players. But they need to be treated that way too.

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

[xxxJonBoyxxx]

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?

SLA

[MCRocker]

Is it safe to assume that SLA stands for Service Level Agreement?

Re:SLA

[Anonymous Coward]

I was thinking more like...

        - SLA = Special Libraries Association
        - SLA = Symbionese Liberation Army
        - SLA = Sports Lawyers Association
        - SLA = Society for Linguistic Anthropology
        - SLA = Second Language Acquisition

Bahf !! I give up !!

Re:SLA

[pr0nin]

No, it's more like SLI. You know, throwing twice the amount of manpower on a task so it can be solved... eh, twice as fast.

Re:SLA

[lrichardson]

Nope. In IT, it might have to do with the Special Libraries Association. Or, if you happened to be doing to AutoCAD out front, they might have an SLA system (computerized manufacturing toys from heck) out back.

Re:SLA

[GlassWalkerTheurge]

Odd, I thought it was you get half as many people to do 4 times more work. I will have to wiki that again. ;-)

Re:Everybody IT needs these skills, not just bosse

[bjourne]

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 probably was ClearCase. In which case the developers definitely has the right to be very grumpy. :)

As far as I can tell, it's manging USERS not GEEKS

[wsanders]

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.

One paragraph book on managing development team

[Organic Brain Damage]

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. Approach your users/customers with a sense of humility and assume they know the business better than you do...then ask them to forgive you for your humble efforts on their behalf. Let them provide feedback directly to the developers. Make a few diagrams, comment the code, use source control and do not get bogged down writing useless documents. All the rest is crap.

Re:One paragraph book on managing development team

[gfreeman]

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).

A book about operating systems not interesting?

[ScottyH]

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).

Re:As far as I can tell, it's manging USERS not GE

[Anonymous Coward]

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. And that, in a nutshell, illustrates why managing the technical "talent" is so difficult!

Too bad your irony was unintended...

Re:Everybody IT needs these skills, not just bosse

[Sobrique]

"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 first place. Most people aren't completely stupid, and appreciate the virtues of budget constraints and 'cost effectivity'. OK, they're biasd when it comes to 'their stuff' and everyone things they derserve the best stuff in the company, but there's only a relative minority who live in la-la land.

Re:Everybody IT needs these skills, not just bosse

[Grapes4Buddha]

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 hardware for the repository server. Other tools have their relative pluses and minuses.

Of course sometimes individuals or even whole groups within an organization are too headstrong to make any changes. In my last job, I was told to help a particular product team migrate from CVS to ClearCase. They were all quite cooperative to my face, but dug their heels in whenever I wasn't looking. Apparently their director was telling them to do this behind the scenes. If they had just f**king told me they weren't going to switch, I could have helped everyone come up with a code sharing scheme that everyone could have used but instead I got so sick of being stonewalled that I left the company.

Not sure what my point was going to be. I'll shut up now.

Idiot Loser Management?

[NoBozo99]

Or perhaps...
Isolated Lamer Masturbation?

Techniques for detecting bad IT management

[Anonymous Coward]

I am current out interviewing for IT positions. As an experienced IT professional (SAN & Unix System Admin.)

I have heard the 80% of the time, the reason you change jobs is bad management.

My top ten signs management is bad.

1. The person your replacing has gone AWOL. (Double, If the story keeps getting wierder, the more you hear)
2. When looking for a business or mission critical computer solution, MS Windows products make the downselect cutoff.
3. High percentage of H1B visa holders in department. (this is NOT a slam on the workers, just on mgmt budgeting /long term staffing issues)
4. Bonuses have never been more than a paycheck.
5. Everyone in the department has matching ages & time on job.
6. job's salary, duties & schedule are out of balance.
7. When there is bad news, they shoot the messanger.
8. The wiring closets are a disaster area.
9. Use the same computer language for every environment. Think JAVA !
10.Outsourcing has failed and IT functiona are coming back inhouse. (three strikes, you're out!)

Missing Options ?

Have fun !

And I would like to say Thanks to Rhonda Klimzak for the inspiration for the number 1 sign.

Re:Everybody IT needs these skills, not just bosse

[PPH]

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?

Are you sure its a spike? Or perhaps its just a reaction to some unilateral decision on systems architecture?

I've been there. The boss comes in and says, "Today, we're changing to system X". My reaction, "That's nice. I hope you have the resources to support it. I'll stay on and keep system Y running while your new people come up to speed. After that, goodbye."

Re:Everybody IT needs these skills, not just bosse

[Skyshadow]

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 piloted the tool with selected teams.

Which is, of course, an interesting part of the problem. At previous companies, I've been able to deal with my developers one on one and generate a working relationship, but when you have thousands of users that just isn't an option. This also brings us back to the reason for having an enterprise-wide SCM project: As I mentioned, people weren't keeping their code in one place and, in some cases, we found still-active legacy systems for which the source code could not be located.

What it looks like we're going to do is opt for a solution where the CTO makes it clear that use of this new system is a condition of employment, that anyone circumventing it will be terminated. It's an iron-fist approach and that sucks, but (a) you're never going to get tens of thousands of users to agree on anything and (b) honestly when you get down to brass tacks the code belongs to the company, not the individual developers or project managers, and therefore the company has every right (and, in our case, a legal responsibility) to secure that information.

SCM

[anomaly]

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 to do so. "Malicious compliance"

We set up a department-grade solution (linux box under desk, multiple hard disks, scheduled backup to a different physical disk nightly) and began using an open source tool. Presto - large checkins no problem. FAST access to the repository. Explorer shell integration on the desktop. Problem solved. Now we have really good usage of SCC tools.

My boss is not happy with me about this, but until the tools can do the job, we'll keep trying to fly under the radar, and hope we're not compelled to use the "enterprise" tool.

FWIW, I'm having conversations with my peer about how well the tools work (and don't) so that either that tool gets improved, or we get them to officially support the tool we like.

Does your enterprise tool work reasonably well?

Re:SCM

[Skyshadow]

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 significant number of parallel failures before the end users would notice anything amiss.

I wouldn't describe your situation as malicious compliance since your enterprise tool doesn't deliver. The stuff I've encountered is quite different. Lemme give you an example:

We had a user call from another location complaining of performance issues, saying that he shouldn't have to use the system because it took ten minutes to check in a small file. We worked with him, involved our network group, went over server logs, called in the vendor -- nobody could figure this out. Finally, I hopped a plane to his location, showed up at his desk without notice and demanded he show me and, lo and behold, it took a few seconds. He confessed that he'd just been lying to us (although he said "exaggerated"), and as a result we wasted dozens of man-hours (and the cost of my travel) to find that out.

Most of the situations aren't quite that crazy, but they tend to be out there in their own way (for example, we had a user cite particular functionality as a reason he couldn't migrate... except his existing tool didn't have that functionality, either). Again, I think it just comes down to certain people not being able to play along with the team, and at a company as big as mine that just doesn't work out.

Re:Everybody IT needs these skills, not just bosse

[Skyshadow]

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 benefits from the use of the tool -- the system also functions to benefit project management, promotes company-wide code reuse, records data for the financial folks, allows upper management to track the progress via reporting and lets people in different phases of development work together without needing to know how to use multiple tools (saving us huge $$ in licensing and training fees). These sorts of benefits are measured in the hundreds of millions of dollars woth of savings to a company like mine, and they're things that can be sabotaged if developers (or other users) decide that they don't need to play ball.

I know this can seem strange if you're used to smaller companies (like I was until I came to work here), but take it from me that a lot of the stuff you take for granted at a company with a few hundred people is the sort of thing that is very hard to achieve at larger companies.

So I hope you understand when I say that we don't have the luxury of giving developers the option to do what they feel like. My preference is always to explain these benefits to people who object to using the new system, but it's getting to the point where the words "we wish you luck in your future endeavors" are about to be used. I don't like that at all but, and I suppose this is my point for this thread, it's sometimes necessary.

That stinks

[anomaly]

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 enterprise solution "A" simply does not work with development system "B."

Specifically, I'm thinking of when a .NET developer is asked to use a repository on a unix box, rather than VSS, which is tightly integrated to their IDE. (Thankfully my team doesn't do .NET, but you get the idea.)

So, should the .NET group have a departmental implementation of VSS, or should the enterprise CM team offer VSS for that set of customers? I know I don't have the answers, but these are the questions that the organization must deal with.

As far as "there are jerks/idiots/selfish people in every enterprise" I think you're absolutely right. I'd have hit that user's department with an insane troubleshooting fee plus expenses for the plane ride, though! (And I would have had a REALLY nice dinner at his department's expense while I was there.)

I also would make sure that I addressed the benefits of enterprise SCC with the team management. When the departmental tool crashes, their management should know that it didn't have to happen that way.

Frankly I don't want my guys installing Linux patches, checking backup logs to make sure that they ran, and maintaining the SCC tool (which has thus far required 0 care and feeding, unlike VSS.) If I could "hire that out" to experts in systems admin, tool admin, and let my guys focus on developing solutions to business problems, I'd be happy to do it!

Re:Everybody IT needs these skills, not just bosse

[Chacham]

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.

Actually, it is very possible at larger companies. Ask managers to ask all the way down, and come with comments all the way up. A larger consensus is possible.

I also work at a large company. There's over ten thousand people in the building where i work, not counting other buildings around the world. Decisions made high up, like using Dimensions for file tracking, or UDB for LUW, are completely moronic. Noone with even half a sense of their use would choose those. Decisions made on low levels, (usually by ignoring the rules) end up getting projects done.

If they'd only ask, it is posible for basically everyone to be happy via compromise.

That aside, you should consider the fact that in cases such as this one the developer is not the only one who recognizes benefits from the use of the tool

But he is the main user, and therefore should be the major concern.

the system also functions to benefit project management

Which should come second, and the work should be done by the manager or supervisor...

promotes company-wide code reuse

Excuse me one second.

Hahahahahahahahahahahahahahahahahahahahahahahahaha hahahahahahahahahahahahahahahahahahahaha

OK, i think i'm done for now.

Noone ever resuses code. Mostly because people aren't encouraged to work together, and instead are sent to systems that are hard to use.

records data for the financial folk

Sort of. It does that in theory, i highly doubt that works in practice.

allows upper management to track the progress via reporting

It probably lets them see progress, but certainly not track it. Unless you believe i that "lines of code" thing.

and lets people in different phases of development work together without needing to know how to use multiple tools

Like FTP? That new-fangled, really expesive tool that noone ever uses?

(saving us huge $$ in licensing and training fees).

Because you get to consolidate it in one tool? If the individuals are using separate systems, they are usually free and easy to use.

These sorts of benefits are measured in the hundreds of millions of dollars woth of savings to a company like mine

I don't believe you.

and they're things that can be sabotaged if developers (or other users) decide that they don't need to play ball.

No, they are things that cannot be implemented.

My guess is that you arer a manager that has finally seen the light, and that coders actually are monkeys, and that decisions are in place as soon as you think it.

I have a radically different view of people. But, that's probably why you're a manager and im just a programmer.

I know this can seem strange if you're used to smaller companies (like I was until I came to work here), but take it from me that a lot of the stuff you take for granted at a company with a few hundred people is the sort of thing that is very hard to achieve at larger companies.

Only because of stupid managers.

I just saw one person save the company millions of dollars. Literally. He took an outsourced project that costs hundreds of thousands of dollars to develop (very much recurring costs), and supported in with about two people. Basically, because managers liked being dragged around by salesman, noone actually took a second look at it, and it grew out of hand.

It is moronic decisions that managers make without input from the developers that cost companies millions of dollars. If a manager makes a decision and then complains that the developers aren't following his lead and costing millions, just makes me wonder.

Re:As far as I can tell, it's manging USERS not GE

[dbIII]

But mostly the job consists of drawing fire so the technical telnet can do their job

ssh - don't disturb the technical telnet.

Player's Handbook?

[shokk]

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 Cube
Sales Elemental
and Bob from Accounting