Five more things I hate about corporate IT

Patrick Gray continues his list of the most annoying characteristics of corporate IT.

In the last installment, I explored five things I hate about corporate IT. These have been picked up in my travels through small, medium, and large IT departments, at everything from government entities to household brands as an employee or consultant. Here are the next five in my unofficial top ten:

6. Listening to condescending consultants

Most IT departments have whole offices full of "hired help," from contracted technical specialists to high-end management consultants. As someone who occupies this profession, I have high standards for how consultants should interact with their client company, and I cringe when I see what I consider one of the worst behaviors, save for dishonesty: condescension. I hate seeing a consultant swagger into a client site, with their mouth open and ears closed, interrupting every explanation of the client's business model or problem with "Well, when I was at Client X, we did..." This type of consultant doesn't need to hear your problem before having the solution and does a poor job explaining how it will actually help, other than implying "I'm the consultant and I'm smarter than you."

This is the corporate equivalent of that annoying and classless coworker who arrives every Monday morning and berates you with tedious stories of his or her "conquests" over the past weekend. As consultants, we're obviously paid for our past experiences, but more importantly, we're paid to listen and provide a solution or steps to arriving at a solution to our client. Dropping names and framing every challenge facing a client in terms of a past experience does little to build credibility and usually causes the very people paying your fee to tune you out.

7. Setting unrealistic estimates

There seems to be an unwritten rule that some people in IT management will promise a wildly unrealistic, shortened timeframe to implement a system or process, then the people actually doing the work will provide a wildly pessimistic estimate. After rounds of back-and-forth negotiation, several missed deadlines, and stress on all parties, the system is implemented in what would have been a reasonable amount of time if only everyone was honest with their estimates. We all know developers that will "pad" estimates, just as there are managers who cut all estimates in half in an attempt to weed out this "fudge factor" or impress their superiors, creating an "arms race" of sorts. With a bit of honesty from all parties and prioritization of tasks (not everything can be a number one priority), this could be eliminated to the benefit of all parties.

8. Putting up with "wet noodle" middle management

In my previous post I mentioned a lack of leadership development as one of my main concerns with corporate IT. What results from lackluster leadership development is "wet noodle" management. Most of us have worked for a manager that is a "wet noodle"; he or she bends to the slightest whims of the most forceful person in the room, refuses to make any decision, and avoids helping his or her team develop and grow their strengths, since helping someone identify their strengths and weaknesses might be a bit too "pushy." The wet noodle may think he or she is everyone's friend, since they live not to offend, but in reality working in an environment where management has no backbone and does not help high performers creates a low-performing and indecisive environment where everyone suffers.

9. Following a broken compensation system

No, I'm not talking about that new payroll software, rather the means by which IT staff are evaluated and compensated. To put it bluntly, most corporate IT departments I have worked with do a poor job helping staff plan their career, set objectives and milestones, then identify and reward the strongest performers. It is easy to keep staff around during an economic recession, but with the invariable economic recovery that is beginning to glimmer on the horizon, the top performers who consistently received average or poorly considered evaluations will be clamoring for the exits. Staff across the company know what they are worth, especially in IT where communication in the industry is much more fluid than other functions. While money is not everything, it is the best scorecard most of us have, and the highest performers tend to be the most sensitive to their "score." This also goes for low performers. Peppering an evaluation form with feel-good remarks may make everyone feel warm and fuzzy, but it is a disservice not to provide a road map for someone to improve, then laying them off after years of telling them everything was fine.

10. Setting up IT as an island

Apparently most corporate IT departments have not read their John Donne, who suggested that "No man is an island." Nor should IT exist in an island-like form in many companies. The comments to my past post suggested that many of the items transcended IT and impacted other departments as well. This is an obvious truth, and many corporate functions have developed systems for assuaging each problem that IT could leverage. Sales is effective to the point of ruthlessness in performance-based compensation; many core functions do an excellent job of staff and leadership development, etc. IT's insistence that it is unique and distinct has become more of a hindrance than a help.

Simple acts like ensuring projects are "business projects" rather than "IT projects" and are staffed with an IT and a robust business presence would alleviate many of the problems that kill complex IT initiatives. Rotating business staff through the IT department and vice-versa helps spread ideas and even shared sympathy to the complexities of each function. I personally believe the days of a large, distinct, and monolithic IT department are numbered, and frankly, the IT profession will be better for it as many IT functions become part of each business unit, rather than a separate beast altogether.


Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...


To be brief, point #10 is either understated or naive. Forcing all projects into a "business project" mold pushes broadly beneficial infrastructure improvements into individual projects, which often results in funding denial. Said project then abandons the infrastructure requirements in favor of a band-aid solution in an effort to obtain funding, and when failures result down the road IT gets the blame. Point #10 needs better consideration.


I guess I will work my way down the list: 6. I agree that anyone internal or external who has the answer without listening is a fool, but why is it that many companies refuse to challenge consultants if we are out of line? I worked with an individual who decided he didn't like the work, so he did and told everyone he was just riding out his contract. The client did nothing! 7. developing proper estimates is an art, but so few companies actually tech people that skill. I think (7) is often a side effect of (10). The island leaves people thinking, "I am a god at (insert tech here) so my estimates are as good as my work!" and the business management always enters "negotiations" with it over schedule and the de-coupled nature of relationship leads to unrealistic numbers. 8. is an issue everywhere, it is not unique to IT. If you have three layers of management, there will always be a wet noodle somewhere in layer two. 9. The other problem is when you have compensation adjustments when the budget isn't there. I don't believe money is everything, but when you hand out raises knowing that people will be cut due to the budget increases you just handed out, that isn't right either. There is a lot to be said for stability and visibility to what the real numbers are. 10. I couldn't agree more. I would add that the business side is often to blame for IT being set up as an island as overreaching IT management. Sometimes it stems back to the out Data processing days when IT was merely a report generator.


Most, if not all, of these points have to do with the failure of management. Also, one point mentioned was the promotion from within of someone with the IT skills, and then being surprised when a project fails. The reason for this is they don't promote someone from within with the IT Skills AND IT EXPERIENCE. Think about it, who are the ones that decide who gets promoted to the Head of IT and subsequent positions? People without a clue. IT Management is especially known for its inability to understand CURRENT technologies, and projects, and the inherent problems that go along with configuring them. I don't care how many lines of COBOL that last program you wrote 20 years ago was!