The Dead Mother Counter

This is a story of how a series of completely rational decisions can lead to a completely irrational result. It was told to me nearly 20 years ago, as then-recent history; I have retold it many times since. While it's possible that the original teller embellished the story somewhat, or that I've embellished it since, I believe that the events actually occured, in generally the order given here.

The story takes place in the internal IT group of a company that manufactures aircraft engines. If you haven't worked for such a company, or haven't been otherwised involved in aviation, you may not realize just how much paperwork accompanies the building of a jet engine. Each part, from the time it's a billet of metal to the time that it's fastened into an assembly, has a paper “routing sheet” that lists every step of that part's manufacture. When the engine goes out the door, all of these routing sheets are sealed in an argon filled container, as a permanent record of the engine's history. The only time these containers get opened is when an aircraft goes down.

As a practical matter, however, paper routing sheets aren't very useful. They can't be analyzed for cost and quality-management purposes. Most important, in the case where a [art fails and causes an engine to self-destruct, it's not easy to find all the other [arts — and their engines — made from the same batch of metal.

This is where the IT group enters the story, with a hardened shop floor terminal connected to a central computer. At each step of the process, the shop worker scans his badge (and in the 1980s, “his” was appropriate), works on the part, scans his badge again, and inserts the routing sheet for the official printed record. On the other end, the computer generates voluminous reports on green-bar paper, describing in great detail the operations of the shop.

And this is where Human Resources enters the story. According to the story, one day an HR person saw a worker scanning his badge, and realized that their manual timecard system was obsolete. So they requested the IT group to add timecard functionality into the system.

I had to “punch a clock” for a job I had in High School. It seemed pretty simple: when arriving in the morning I'd put the card into the machine and it would print the current time on the card. I'd do the same thing when I'd leave. We received a paid half hour lunch break (primarily because we worked off-site), but the same process applies if you have to punch out for lunch. In a large organization, I would expect timecards to be machine readable, to minimize processing costs.

And it seems like a pretty simple process to automate. Given the limited tools of the time, perhaps a month or two to implement, test, and deploy. This particular project took far longer …

The reason was the foreman's terminal. Flex-time is unknown in a large industrial shop. If you're late, or miss a day's work, you need to have your foreman write up an explanation. It's unclear to me whether HR actually asked to have this automated, but automated it was. The foreman would scan his badge, then your badge, then choose from a list of reasons for missing work. One of these was “death in the family.”

And then someone asked the fateful question: “how can we track whether a person repeatedly claims a death in his family?” And the dead mother counter was born. It was a field in the database that would be incremented each time a person used that excuse. And there were volumninous reports on green-bar paper that listed the people who used and abused the excuse.

This was the point at which HR stopped funding the project. And when I joined the IT group a couple of years later, there were still timecard machines in the entrance to each shop building.