People outside the field of Information Technology often falsely assume that IT professionals have been immune to the downsizing trend. Advertisements in the newspaper and on TV seem to suggest that anyone with a bit of technology under their belt will never need to worry about job security. Well, such an impression is quite false.
Indeed, many chief information officers have been saddled with performing a downsizing operation on their IT function, while simultaneously asking them to create even more systems and maintain more systems than ever before. Pressures to streamline and slim down the IT function are just as intense as downsizing efforts in manufacturing, marketing, and other functional areas. And, pressures by all functional areas to use and exploit Information Technology to help support a downsizing imperative are paradoxically on the rise.
Thus, the IT professional who survives a downsizing and remains on-board with his/her present employer faces the daunting task of taking on more work than before the downsizing. The standard joke suggests that your good news is that you continue to keep your job, the bad news is that you now do the job of two or more people.
Now, the preceding comments should not be interpreted to suggest that downsizing per se is a bad thing. I agree with a number of economists who argue in favor of downsizing as a management tool. Firms that are fat should find a way to reduce the fat and become as competitive as they can. And, admittedly, sometimes the diet takes you past the fat and can inadvertently strike at true muscleþhence, the importance of knowing how to downsize and determine when enough is enough.
Having observed and even participated in I.T. downsizing efforts, I offer next some suggestions for IT executives faced with the horrible task of deciding who stays and who goes.
For example, one IT group decided to halt most new development and attempt to move toward the use of off-the-shelf packages rather than continually invent their own systems. Such an approach will normally require a shift from a programmer dominant development group to a systems analyst dominant group (you'll likely need less "coders" and more analysis labor).
In such a circumstance, deciding that 15% of the programmers must go and 15% of the analysts must go is probably not a very sound approach. The better logic is: What strategy should the IT group have for the skills and labor required to meet the IT business objectives, and therefore, where should labor be concentrated and where can it be lessened? In the preceding example the answer might be that 20% of the programmers can be laid off and 10% of the analysts can be laid off.
I've seen some CIOs send an email as a form of announcement to the next-to-be-laid-off IT employees (note: this seems about as bad as receiving a proverbial Dear John letter). Even if the IT culture does tend to accept electronic communication, the use of e-mail for this particular act is likely to be seen as cowardly and cold.
In coordination with the professional guidance provided by your human resources function, I have found that an in-person explanation of the downsizing activity and a one-on-one approach to breaking the tough news is a better method of conducting the downsizing. Plus, the CIO should try to find ways to help the laid-off IT staff members become self-sufficient and pursue their next job (via outplacement services or the like).
I recall one instance where the Help Desk function within IT was severely hit by a downsizing effort. The CIO seemed to assume that the volume of calls to the Help Desk would correspondingly decrease. But why should it? The end-users didn't know or care that IT had to reduce staffing on the Help Desk, so the calls continued to pour in. The Help Desk staff who remained were valiant in trying to handle the call volume, but eventually several of them began to suffer actual physical aliments due to the high stress and overwork.
Thus, it is important that the management of IT try to anticipate how a change in the internal staffing will impact the services provided by the IT function and how the rest of the IT staff will be impacted. In the preceding example, I helped the CIO find other ways to deal with the volume of Help Desk requests (e.g., outsourcing some of the calls, show the end-users how to help themselves, and so on).
Let's take another example dealing with an IT Help Desk function. In this new example, prior to the downsizing, the end-users could call the Help Desk as much as they liked without incurring a cost of any kind. The Help Desk appeared to be a free resource.
The CIO knew that he had to deal with a shortfall in his budget and he wanted to make up for the shortfall by letting go at least three bodies from the Help Desk. I proposed that we explore a way to increase his "revenue" as opposed to strictly focusing on ways to reduce his costs. The CIO doubted that end-users who were used to something that was "free" would be willing to begin paying. But, by discussing the matter with the end-users who used the Help Desk, we discovered that they were willing to pay for the Help Desk if it meant that IT would be able to continue the Help Desk services the end-users had become accustomed to (we pointed out that otherwise they would lose many of the services).
Brainstorming and creative problem solving can often help prevent or reduce the amount of downsizing that seemed to be required.
The latest trend for some IT groups is the need to upsize. Yes, companies are beginning to grow again and the need to upsize an IT function is returning. Upsizing might seem like an easy task ("just go out and hire people"), but as you will see in my next column, there are a number of important do's and don't's that you should be mindful of when moving into an upsizing mode. So, think upsizing thoughts and stay tuned for my next column.
Remember that your input is welcomed. If you have projects addressing the information technology area, and you would like to share this with the readers of "Information Technology," please contact me.