When working for a big company, reports are often extremely important to make sure that everything is done correctly.

What would you do if your company made lots of decisions based only on reports that didn’t give accurate data about the work being done?

That is what happened to the IT guy in this story, so he learned about the report and learned how to play the game.

Keep reading for all the details.

When the metric becomes the target (a cautionary tale on being careful what you measure)

This happened about eight years ago, when I was still working for a North American class 1 railroad.

I worked in IT, specifically in a department whose primary role was to generate metrics and regulatory reporting (for the Surface Transportation Board and their ilk).

Most of our measures were inward-facing, though, covering such things as volume, dwell, revenue, and productivity.

This story involves a problematic dashboard in the last category – specifically, a measure of the productivity of our unionized office workers.

I can see why management would want this report.

The managers loved it because it gave them a weekly graph of who needed corrective punishment for under-performing.

Our toxic CEO of the day was all about punishment. They even had quotas to meet.

It was in regards to this last one that (I’ll call him B) made the short walk across to our building so that he could ask me about the metric.

I’m sure he doesn’t like this look.

He’d just come from an uncomfortable meeting with his direct manager who showed him how he was the lowest-performing employee on their graph. By a wide margin.

His manager told him to pick up the pace, or he’d face potential repercussions, possibly even a one-week suspension.

Knowing what is being measured is important when working on your performance.

B came to me because he knew I had access to the back-end of the metrics, and he wanted to know what they were measuring him on because he was never not busy.

Some important background on B is that he was a very senior, conscientious employee.

He had as much experience as the rest of his group combined, and he came to me because we went back about 20 years from my time in the union before I moved to IT.

This is a common job type for tech workers.

The job of their group was to “work the queue” – that is, go into the failure queue of events that had cacked for one reason or another, resolve the issue, and allow the automated functions to flow properly.

A couple of trivial examples would be a train lift failing because the cars had not been properly reported into the customer’s track or, conversely, they’d been reported in, but the customer had not electronically released them out yet.

Difficult problems take longer to fix.

Because he had so much experience, B took it upon himself to hand-pick the really messy, time-consuming ones from the queue; ones where somebody had back-dated events, and it took some messing about to figure out what was wrong, and what needed to be fixed.

Or where a conductor took all the paperwork home and forgot to update this tablet with the switching that he’d done.

Basically, if it was something that might require phone calls and deep research, he would deal with it rather than let inexperienced folks struggle with it.

Knowing how these types of reports work is half the battle.

I pulled up a pre-production version of the dashboard and scrolled through the source code to find the important bits.

We discovered that it was looking for clusters of specific event types reported under an employee’s User ID with at least a two-minute gap between the clusters.

He was puzzled over the last requirement, but I explained that it was so that a single train being processed would only count as one event.

It might take a few minutes to fix the train, but the reporting was at the car level, and as long as no more than two minutes elapsed between the report on one car and the next, it would all count as a single incident to the dashboard.

Apparently this is a dumb way to measure things.

“So, it doesn’t look at how many records you handle, only that they happen more than two minutes apart?”

He paused for a moment before adding, “That’s really dumb. They don’t care about complexity? They’re seriously just counting how many times a person clicks OKAY? Somebody could game that pretty easily if they wanted. Hm.”

Oh, he is going to fix his productivity fast.

He walked away without saying anything else, but I could see the mental gears turning.

He came back to me a couple of weeks later to give me the good news. He’d gone from being the most under-performing person in his group to being their top employee by just as big a margin.

He’s doing a lot less work, but looking better on the reports, so that is all that matters.

“It’s great,” he told me. “Forget all the complicated stuff. I’m just grabbing the biggest trains from the queue. I work one screen of cars, then sit back and drink my coffee for exactly three minutes before I process the next.

I finally have time to complete the crossword puzzle in my paper.

Sadly, the company attributed his miraculous turn-around to their draconian discipline practices, and never clued in that while their numbers went up, their actual productivity had tanked a bit.

The only real consequence to him was that his job became a lot easier, and he got to slide into retirement on a high note.

All too often it is more about knowing HOW to play the game than it is just doing a good job, unfortunately.

Read on to read what some of the people in the comments on Reddit have to say about it.

Yup, it happens in almost every field.

This commenter is spot on.

Sadly, this is very true.

It doesn’t make sense, but it happens all the time.

This is actually pretty common in big businesses.

Be careful what you measure because that’s all employees will focus on.

If you liked this post, check out this story about an employee who got revenge on a co-worker who kept grading their work suspiciously low.