Projects

Yesterday was the big deadline day for a huge project at work. The day when they were supposed to go live, doing stuff for our customers who in turn would have tens of thousands of people as customers. The people involved in this project have been working around the clock to get things working by the first of April.

"Fortunately, the customer is even later than we are," I just heard one of them say to another.

This reminded me of something that happened long ago, while I was working for a consultancy company as one of their Unix-experts for hire. Once a month, the Unix group would meet over lunch, so that our boss could let us know what was going on at the company (which we usually had no clue about, since we spent all our time at customer sites), new contracts and such. At one such meeting, one of the guys (we had no women at all in the group) was assigned to a new contract. The boss outlined the job, and it as a big one. He was to install a huge, complex application, all they way from getting the servers shipped up to having it running and the users trained. It included installation of half a dozen large Sun servers, storage systems for them, designing and setting up backup schedules, installing the application itself and the Oracle database it needed to run, writing user training documents, et.c. Roughly, a three man-month job.

"So they want it finished in three months or so?" the guy asked.
"No," our boss said. "They want it done by Friday."
"Is the hardware in place?" the guy asked. "And how many people can I get to help me?"
"The hardware will be delivered on Thursday. Maybe. And you can't have any help. They're only paying for one person."
"But this is a three-month job! And that's if everything goes well!"
"I know," the boss said. "They've been working on it for three months already, and it absolutely has to be done by this friday."
"That's impossible," the guy said. "There is no way."
"I know. The customer's IT people know it too. But if you're there, they won't have to take the blame when their board of directors come asking why it's not working yet."

That was the first time I encountered someone explicitly being hired as a scapegoat. It was something of a revelation to me. Until then, I had believed that being a technical specialist consultant was all about technical skill -- but it's not. It's at least as much about helping the customers smooth over their problems, no matter how stupid those may be. If the customer wants to pay for a Unix specialist in spite of not actually having any Unix machines, because it says in an old policy document of theirs that they're supposed to have one, then, well, I went there and spent the days drinking tea and working on some private project on my laptop. It may have felt totally useless to me, but I solved a problem for the customer. Not a technical problem, granted, but still a problem.

I talked to the guy who got the scapegoat job after it was all over. Once he'd understood what it was really all about, he'd rather enjoyed it, he said. There was absolutely no pressure to produce anything, nothing whatsoever was really his fault in spite of everything being blamed on him, the place had good coffee and several cute Irish women working as programmers.

I still occasionally wonder if a company specializing in taking the blame for failures would be viable business.