November - 1999 - issue > Cover

I didn’t expect to be facing this problem until sometime in January, but I’ve now heard four or five separate reports of companies wrapping up their Y2K remediation and testing efforts, and promptly laying off the technical staff that devoted the past two or three years of their lives to the effort. In one case, it’s a large systems integrator that has laid off nearly 10,000 software professionals; in another case, it’s a Big-5 accounting firm that provided technical staff to its clients for Y2K projects. To the extent that both of these firms rented out their staff to clients as “hired guns” for the Y2K effort, perhaps it’s not surprising that they would meet such a fate when the projects come to an end.
But what about the companies that used their own employees for Y2K projects? A couple of weeks ago, one of the airlines announced that it was laying off some 200 software professionals, partly due to streamlining costs (whatever that means) and partly because those working on Y2K projects were now redundant. The airline noted that most of the laid-off staff had been hired by other firms in the same geographical area, implying first that there was no need for them to feel guilty about their actions, and also that there was no need for any of us to feel sorry for the fate of the former Y2K programmers.

To Regret or Not to Regret

It seems to me that there’s a practical issue and an ethical issue involved here; let’s begin with the pragmatics. In just a few more weeks we’re likely to find out, once and for all, whether or not all of those date-related software fixes really work. If an organization is really convinced, at this point in time, that it has really finished all its remediation and testing, then it’s obviously difficult to justify letting those software professionals sit around for three months, twiddling their thumbs and waiting to see if anything blows up. If you assume that the fully loaded cost of an average software professional is $10,000 per month, it would cost $3 million in salaries and overhead to have a team of 100 people sitting around, effectively doing nothing, for the last three months of this year. If these workers are well-paid contractors hired from a high-priced software consulting firm, it will be almost impossible to resist the urge to terminate their contracts. Even if the Y2K team consists of loyal, full-time employees, there will be pressure to save money by disbanding the team.

The risk is obvious: if it turns out that there are serious problems in January, there may be nobody around to fix them. If the problems are simple and straightforward, then a skeleton crew might be sufficient. But if one or more mission-critical system shuts down for a week, senior management will probably panic and issue an “all-hands-on-deck” order. What concerns me about all of this is the likelihood that the most subtle and difficult problems will be in the interfaces between an organization’s application software and the rest of the world — for example, the hardware, operating systems, DBMS packages, networks and external supply-chain systems. This is, of course, a familiar argument: even if your own applications are perfectly Y2K-compliant, they may experience difficulties due to interfacing with non-compliant systems. Fixing those problems may require the expertise of the very application programmers who were laid off earlier.

The issue of ethics is one that senior management may or may not be concerned about — especially those who consider themselves “lean and mean,” and “bottom-line-oriented.” They may argue that layoffs at the end of the Y2K initiative are no different than layoffs at the end of any other corporate initiative — you know the drill: it’s not personal, it’s just business. And, like the airline company mentioned earlier, management probably assumes that most programmers can get a new job without much trouble, because of the much-ballyhooed shortage of software professionals throughout the industry.

Y2K: The Real End-Game

To some extent, these hard-nosed senior executives are correct. After all, those of us who have been in the computer industry for 10, 20, or 30 years know that there is little or no job security. Our skills may be in great demand throughout the industry, but all through the 1990s, we have seen companies go through sharp increases and decreases in the size of their IT staff as they’ve gone through mergers, acquisitions, upsizing, downsizing, rightsizing, reengineering, outsourcing and radical changes in technology. Any technical person who found himself working on a Y2K project in 1997 or 1998 had to know that it wouldn’t go on forever; unlike mainframe-based projects in the 1970s, or client-server projects in the 1980s, or Internet projects in the 1990s, everyone knew that Y2K projects had a definite end date.

But that doesn’t necessarily make it any easier to cope with the sudden realization that it’s all over. The worst-case situation is the one in which technical personnel, or Y2K project managers, have worked heavy overtime (without being paid for it) for the past two to three years and assumed that when Y2K came to an end, they would be transferred to some other position within the company, along with a promotion, a bonus, and a heartfelt letter of appreciation from the CEO. Instead, in today’s lean-and-mean world, it’s not uncommon for these employees to be informed, with little or no warning, that the company has decided that their technical skills have become obsolete and their services are no longer required. Instead of a bonus and a promotion, they’re given two weeks’ severance pay and instructions to clean out their desk by the end of the day. In some companies, there will be an air of deja vu about this; the last time it happened was when the mainframe programmers were told their skills were obsolete and that they would be replaced by a younger generation of client-server programmers whose salaries were 50 percent lower.

Policies for the Brave New World

Every company will have to decide for itself what kind of ethical position it wants to take when Y2K winds down. It seems to me that the best of all worlds would be a transition plan that would allow the hard-working Y2K programmers to stay with the company and perhaps move into the brave new world of e-business or other new technologies. But maybe this isn’t possible; maybe the reality is that there really is no place for some of these folks who have been patching our COBOL programs for the past few years. But there are humane, civilized ways of letting employees or contractors go, and I hope that senior managers realize that there may be some practical consequences of terminating people abruptly and without compassion. At the very least, terminated employees are going to be extremely unsympathetic if your remediated legacy systems experience crashes and problems in January 2000; indeed, they will probably be chortling with glee. In the worst case, they might even cause some of these crashes during their last few days on the job; a disgruntled programmer is a dangerous beast to behold.

A company with a well-organized Y2K project will have considered all of these issues in advance, and will have developed whatever policy makes sense for them. But perhaps your organization created its policies back in 1997, when the Y2K problem looked very different than it does now. It seems to me that a company would want to ensure that its Y2K technical staff is aware of the policy for layoffs, transfers or other personnel actions when the Y2K project winds down — for both ethical reasons and practical reasons. The ethical reasons are obvious: rather than surprising staff with a pink slip on December 31, it would be nice to give them enough advance warning so that they can begin looking for another job while wrapping up their Y2K work. The practical reason is one you may not have thought of: a company that refuses to divulge its plans and policies runs the risk of being the victim of wild rumors — and those rumors could be sufficient to cause some of your critical Y2K programmers to quit now, while they can still find another job easily, rather than being laid off sometime in December, when the job market will be much more uncertain.

The first few of these Y2K-related programmer layoffs have not created much of a stir in the trade journals and the general media. But if it accelerates — as I think it will — then the topic will be on the mind of every Y2K programmer in the land. At that point, organizations had better be sure that it has a reasonable balance of pragmatics and ethics with regard to its own Y2K staff.