Why Information Technology Director Is The Most Hated Job In America (An Anecdotal Account)

CNBC ran a story on Friday about the 10 Most Hated Jobs In America.  I was pleasantly surprised to see that job I left in corporate America after 15 years was represented generously on the list.  In fact, technical jobs in generally made-up almost 1/2 the entries. However, today I’d like to focus on the #1 most hated job in America: Information Technology Director, since I have some very intimate knowledge of why this jobs sucks on so many levels.

Sure, I was only a “Manager” of information technology, but I still understand what they are getting at with this job and why it made the list.  The details here are generalities, and while this doesn’t describe every corporate I.T. department exactly, it’s my experience and I think it is representative of what is happening on large scale at companies similar to the one I left.

Let’s say you got your start in I.T.  leadership 10 years ago.  If you are director in I.T. let’s hope you have at least 10 years of experience.  Let’s hope you were not granted the job right of MBA school, or rose up really fast after a few years at a major consulting company and think you can be a successful  Manager or  Director in a Fortune 500 I.T. department right away.  Back ten years ago, you probably had a good sized team of technical people working for you.  These could be any level of technical profession: from desktop support, all the way up to systems and software architecture.   In fact, it was probably multiple teams, each responsible for creating solutions for existing problems. The work was difficult, but it was also very rewarding.  You solved problems on a daily basis, while working with a group of very interesting people.  On good days work could actually be fun, or at the very least, it was not boring.

However, in the past  10 years, times have changed.  First, the company  started moving from internally developed applications, to off-the-shelf software packages.  This probably occurred after the huge staff-up and lead-up  for the year 2000 Millennium Bug.  The finance department was tired of hearing about how much support your internal apps needed and wanted someone else to pay for it: software vendors.   However, enterprise-scale software packages are not cheap. Little by little, your budget for internal development was siphoned off to pay for the yearly license and maintenance fees for said software packages.  While you were promised training to your technical staff to support and augment those off-the-shelf packages, your training budget was instead used for getting you team up-to-speed on things like ISO-9000 and ITIL.

Next, the company you work for decided that they had too large of a development staff, especially since they were bringing in so many off-the-shelf applications.  Since your team still could not support those apps (where did that training budget go again?) a good portion of them are laid-off and are replaced…first with on-site contractors, and then as the projects entered a support mode, an offsite or offshore team.    Still though, you kept your “lifeboat” employees around, because the “good” work was  just around the corner. You see, that first round of outsourcing and off-shoring was not indicative of anything…at least that’s what your higher-ups told you.  Instead, it was done to help “free up your staff” for “higher value” work.

However, that “high value” work only trickled in.  Instead, more rounds of outsourcing occurred. First the desktop support and the help desk went.   Your business customers then begged you for help with these issues because the turn around from the offsite/offshore team is too slow with the support tickets.  Little by little, your team was thrust into those support roles because no one else is around to help.  Next, the infrastructure team was outsourced, and then most of the rest of the development staff. You are left with a few systems analysts.  Instead of technical people, a new breed of “Business Analyst” invaded your ranks.  They are like people you have never met in I.T.  before. Not only are they not technical, but they don’t want to be technical.   They see technical people as a breed that is not needed any longer on the internal I.T. team.

And here you are today. No longer are you responsible for a team (or teams) of technical people who are serving customers on a daily basis.  Instead, for the most part, you are in charge of non-technical (or almost) non-technical analysts who rely on outside contractors for technical work (either offshore or on-site consultants), and large integration/consulting companies for technical leadership.  By de-emphasizing “individual contributors” and “subject matter experts” (read: terms used to marginalize technical people),  the I.T.  department tried to remove themselves from the functions that were seen by Finance as ripe for being sent offsite and offshore.  Instead of becoming a technical powerhouse, corporate I.T. reinvented itself as a “business partner” that wanted its’ employees to be business people first, and technical people second (or third, or tenth, or never).

The only problem with that plan was that the “business” already had “business” people for their business functions, and they expected I.T. to actually add technical value.   However, with no technical people (because who needs “subject matter experts” and “individual contributors, right?)  I.T. must now find those resources outside at sourcing and consulting firms.   With so many outsiders providing technical work, I.T. had to staff-up on analysts and project managers, and build-out their capabilities in security, governance. time-tracking and managing service level agreements.  None of this leaves much space for actual technology.   I.T. can’t just go advertising that they don’t think they are a “technical function” any longer, because they forgot tell the rest of the company about this big change. (Well, let’s be honest, they couldn’t tell anyone, because who would want to admit that the Information Technology Department was no longer interested in technology? That would sound silly, right?) At the same time, I.T.’s internal business customers still expect technical leadership (at least until they are burned) from the I.T. department and still believe I.T. is a technical function. However, since I.T. has tried to reinvent itself as a “business function” they lack the capability to provide technical leadership in the course of day-to-day activities.

If you are an I.T. Director (or Manager), and you have been around since the time I.T. actually DID things, this can be a terrible situation, especially if you once pleased your business customers with technical innovations and achievements.  Your business customers still expect the kind of high-value work you once provided, but the I.T. department no longer thinks it has any value (internally anyway).   You find yourself in completely ludicrous situation of pleasing your customers while getting in trouble with management, or pleasing your management while your customers look elsewhere for technical expertise.  Soon, the business (who now need to get their work done in-spite of I.T. instead of with I.T.’s help) hire their own specialized technical people with their own product budgets.  Even though those business customers still want to work with (what’s left of anyway) of their loyal (but confused, depressed, and shattered ) internal  I.T. development staff (read: those same  individual contributors and subject matter experts) they have to squeeze those people out of their projects because I.T. red tape has made successful projects a near impossibility.

With no real projects left to do, your technical staff is depressed and unmotivated as they see the best work and projects disappearing to outside agencies.   Even though these people were once told that their jobs would be to “lead” the big projects, the customers no longer trust those big projects with I.T.  because the I.T. leadership has proven (finally) that their are not technical any longer, and need to call an outside consultant every time a technical issue arises.   Your best employees are no longer be able to sit by and watch others get to do the work they once were very successful completing (when they had the support of I.T.).  As an I.T. Manager or Director, your best, most technical employees are leaving the company.   The upper management I.T. will makes no effort to keep those people around, because their exit appears to help solve a “problem”  that will allow them to hire more analysts and project managers.  This situation snowballs the issue as these are the “real” people the business customers trust in I.T. and without them around, the  business customers have stopped trusting I.T. judgement.  You are stuck between a rock and hard place, with all the people you  once relied on for for technical work and day-to-day camaraderie, leaving the company to go elsewhere.

However, there is some good news.   You will get to work with your technical staff again, some of them anyway. Months or years down the road, they will appear again, employed by (or more likely, having started their own) small technology and consulting firms working  directly for your customers, doing some of the same work they used to do for you, but without the I.T. department getting in the way.  Which means you really won’t get to do any part of it, and even if you do, it will  feel unsatisfying.  In the back of your mind you know, the glory days of I.T. as a game changer in corporate America are far behind, left in distance, and much smaller than they appear in the rear-view mirror.

And that’s why it sucks to be a manager or director in I.T. in 2011.  At least, that was my experience.

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.