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.