Phoenix is more realistic. Every problem every shop I’ve ever worked in is in that shop, plus some I’ve (luckily) only heard about. But unlike Office Space, it has solutions beyond burning the building down.
The story goes like this: A midlevel manager becomes the acting VP of IT when the two people above him get fired suddenly. Not long after getting strongarmed into accepting the promotion, he learns he has 90 days to turn the IT shop around, or he’ll join them. It takes about three days for him to find he has about three years’ worth of work backlogged, with his current staff, on top of a project that has to be finished in a matter of weeks. And the CEO is threatening layoffs in his department, because IT is too expensive.
The authors have spent the last decade and a half or so studying highly successful IT shops, and they have some ideas about how things need to be done. At times I wish the stories went into a little more technical detail, but then I remind myself that HR people are buying this book, reading it, and learning from it. So the level of technical detail is probably about right–enough that it’s believable, but without getting bogged down into how the hero of the book went about determining that the first crisis of the book wasn’t a storage or network issue, even though it looked like one.
Once you’re able to keep all the names straight and get to know the characters, it’s a very engaging read. For me, that was the hardest part, and the tendency of one of the most critical characters to call everyone by the wrong name until he or she had earned his respect made that task harder, though it adds a bit of comic relief to a book that’s, let’s face it, largely about the agony of working in a field that few people understand.
Chances are you’ll find yourself relating to at least one character, if not multiple characters. I know of at least a couple of former coworkers who would say I’m like the CISO, John. But at least in my current role, I’m not.
The character who actually hits closest to home is Brent, the stereotypical hair-on-fire sysadmin. A couple of times in my career, I was the guy that a shop brought in to try to offload work from their Brent. I clashed a lot with one of them. He didn’t like my journalism background, and he didn’t like how when he told me to do something, I wrote a script to do it so that the next time he asked me, it would take 30 seconds.
I can relate all too well to the botched software releases. That was an annual ritual at that shop. One year, I got to build web servers, and boy oh boy was it fun. The documentation was 300-plus pages of, pardon my French, complete and total bullcrap. It had screenshots showing how to open the Windows Control Panel, and screenshots showing the longest possible way to shut down IIS, but what there wasn’t room for in that 300 pages was any kind of cross-references. Those 300 pages were spread across three documents, and the steps weren’t consecutive, so you had to bounce back and forth between them, but it usually wasn’t clear until something didn’t work that you had to go to one of the other documents to resolve some dependency.
Needless to say, my first web server didn’t work. I’m sure that was confirmation in our Brent’s mind that I was an idiot.
Adding insult to injury, a guy named Bruce somehow did manage to build a working server. Bruce was better known up until that point for shutting down servers accidentally and blaming my patching. So I had to swallow my pride and work with Bruce to figure out why his server worked and mine didn’t.
Then I wrote a document that was a handful of pages–I don’t know if it was 20 pages or 3, but whatever it was, it was much shorter than the rest. It was my no-bullcrap guide to deploying a new webserver or upgrading an existing one. It didn’t meet government specifications, but I didn’t care. All I cared about was building working web servers. Then I realized I could script most of the process, so I wrote a batch file that automated 90% of my guide, and for the parts that required GUI interaction, I inserted a pause command with a prompt to carry out whatever step in my guide was necessary, then hit a key to continue.
Instead of it taking an hour to spin a server, I was able to roll out just about all the servers we needed in about an hour. Not bad for 2009. That freed me up for the rest of the week to do what this book calls “unplanned work.” That was good, because we had plenty of it that week.
The difference between our shop and the shop in this book was that the developers weren’t on board.
Reading this book seems destined to become a rite of passage for those who aspire to manage rather than being managed. I think it’s also a good read for people who wonder why IT project so frequently go wrong. IT isn’t always quite as broken as it is in the shop in this book, but everywhere I’ve been, they’ve had at least some of the problems this book describes.
I say this as someone who wrote a proposal to turn around a failing IT shop–a proposal that won, by the way. I used my knowledge of that shop, applied some very superficial knowledge of the current hip, chic trend in IT management–ITIL–and we won. It was a posthumous win, because I had left the company by the time the contract was awarded, and if I had to bet, probably not a lot has really changed there. There’s a difference between tweaking what you’ve always been doing just enough to be able to call it ITIL and effectively implementing it. This book doesn’t attempt to be a how-to guide to ITIL, but it’s about the best practical illustration of the transformative effects of ITIL that I’ve seen.
Read it. You’ll be glad you did.