This IT boss is all talk, no action

In this IT tale, the tech boss' first goal was to look good to top management; completing projects and taking care of employees came last

Earlier this year I worked in the content management department for a major re-insurer in the Midwest. Our IT boss -- we'll call her Sue -- was, to put it mildly, tough to work for.

Sue's management style was all about her, and she was obsessed with proving to senior managers that she was the right person for the job. She could certainly sell an idea. She'd tell businesspeople in the company that we could do all of these projects to make their life easier. They'd buy into it, then couldn't deliver because she was still trying to deliver something to another department that was three months behind schedule. The senior managers for some puzzling reason didn't step in. For instance, she frequently went directly to the CIO for support to get things done that others wouldn't sign off on, and the CIO would back her up.

[ Want to cash in on your IT experiences? We are looking for an amazing or amusing IT adventure, lesson learned, war story from the trenches, or an instance when something went very right. Send your story to If we publish it, we'll send you a $50 American Express gift cheque. ]

It was obvious that her loyalty lay in looking good to everyone else in the company but those who worked for her. She constantly stretched her department too thin, demanded that we kill ourselves to deliver these projects, and then the projects were buggy and didn't work as expected because the deadlines were more important to Sue than the quality. She had the attitude that she was right and everyone else was wrong and wouldn't listen to suggestions. Some of us jumped through the necessary hoops to voice our concerns about her, but since she had the top brass in her pocket, to our knowledge nothing was done.

One disastrous incident that stands out in my memory was an upgrade to our document management software to a newer version. Everyone in the company (about 600 people) relied on this software at some point in their daily lives, so it was a major undertaking. We did the upgrade over Valentine's Day weekend, which happened to be a three-day weekend.

The upgrade was off to a bad start in a couple of ways. First, Sue gave us about a week's notice and told us to all be ready to work every day Valentine's weekend if need be. Most of us on the team were married, except one person who was in a pretty new relationship, so doing such a major project on a weekend when most of us had made plans left a bad taste in our mouths.

Second, it was obvious that Sue hadn't put any planning into the upgrade. We all voiced our concerns, but one person on the team in particular questioned her, pointing out that a major upgrade should have a good migration plan and testing before going live. He said that he'd been through a few of these upgrades in his career and agreed that a three-day weekend is a perfect time to do it, but more planning was necessary. Sue assured him that she too had been through many of these and knew exactly what she was doing. And as usual, nobody above her told her to do things differently.

[ Tired of being told to do more with less? Participate in InfoWorld's Slow IT movement: Rant on our wailing wall. Read the Slow IT manifesto. Trade Slow IT tips and techniques in our discussion group. Get Slow IT shirts, mugs, and more goodies. ]

So we upgraded over the weekend with the help of our network admins and two reps from the software company on site. We tested the install in our production environment, and within five hours, Sue triumphantly declared success and sent us all home.

Tuesday morning when the rest of the staff (about 600 people) came to work, most of them couldn't do their jobs. We're talking everyone from document scanners to accounts payable. The problem was, we didn't have any real-world users testing the upgrade. The only testing was done by the software admins who had the most access and the least amount of restrictions. The reps from the software company didn't tell us that since the lower users (about 500 people) weren't local admins on their machines, we'd have to grant access to each PC, download new ActiveX controls, and then unregister old version DLLs and register the new DLLs. That detail would have been good for us to know. Maybe they told Sue.

It took us over two months to get everyone's computer working normally. The next two months were marred in lost productivity and very colorful exchanges between Sue and the vendor, as well as Sue and the CIO.

Well, Sue still has egg on their faces from the whole mess. Thankfully, I am no longer working for her, although I do keep in touch with my former colleagues who report to her, and it sounds like top management and others in the company are getting fed up with her attitude and failure to deliver on projects. It's a shame because the software really is a gem, but you just can't ram ideas down people's throats. You need to have realistic goals for deliverables, and you need to treat co-workers with respect. Hopefully, she'll realize that one day.


Copyright © 2009 IDG Communications, Inc.

How to choose a low-code development platform