Hacker News Reader

Comment by lpd1 | Hacker News Reader

"You received this email because my big data team analyzed your activities in Jira, Confluence, Gmail, chats, documents, dashboards and tagged you as unengaged and unproductive employees. In other words, you were not always present at the workplace when you worked remotely."

Sweet.

Maybe we are hitting the day when all of your code commits, all communication, location in the building, telecommute meetings, etc. etc. could be run through the Big Machine and give you a grade. All automated.

A parrot could be trained to fire people in a special HR chamber.

View on HN

> Everything about their employees is monitored and tracked, down to individual finger and eye movements, to prevent waste and track performance. All emails that are sent out include an estimate of how long they should take to read. Go to fast, you get scolded for not paying attention. Go too slow, you get scolded for inefficiency. Get it just right? You get scolded for being a smartass.

—- Snowcrash

Communist logic:

Three prisoners in communist East Germany were talking about their crimes.

1: "I always got to work five minutes early. They convicted me of spying."

2: "I always got to work five minutes late. They convicted me of sabotage."

3: "I always got to work exactly on time. They convicted me of owning a Western watch."

In USSR it was a planned economy as everybody knows. Producing less than planned amount was bad - from possibility of it being treated as sabotage in Stalin times to not getting bonus and being openly shamed in later times. Producing more than planned amount was good - bonus and "honour roll". Produce much more than planned amount, especially several times in a row - your planned amount will be adjusted upward, and not only yours, the colleagues in similar jobs/situations would get their plans adjusted up too. So the art was to produce just a bit more, enough to get bonus and honours, yet not trigger the adjustment up.

I suspect this will be an unpopular opinion here, but I think that if you set the thresholds conservatively enough, a tool like this could be useful in identifying people who are not contributing. Where I work there are searchable tool invocation logs and there have been cases where someone is only compiling code one or twice a month, who not too long after I discovered this made an exit.

If you're enough sigmas below the median, it might be worth a closer look at least. Human review would be necessary of course. There are a plethora of ways to contribute. But it doesn't seem controversial that there must be some signal to be extracted from logs like those described in TFA.

The problem with any metric is that old quote about “when a metric becomes a measurement it’s useless.” How do you recognize someone who commits the same “amount” of code but which is consistently shitty and has to be reworked later from someone who commits a lesser “amount” but guides the project overall to a better place? Or someone who is spinning gears all the time: compiling code, spinning up VMs, in meetings all the time, and yet whose absence would be unnoticed?

Even a system of assigning a certain number of tasks. Sounds reasonable enough, right? But in my experience if you need X tasks per Y, the tasks will soon begin to conform to the metric. “Oh I need 8 gold doubloons this week, let me assign all of those to fixing the white space in this file.”

Perhaps. It depends on how easy it is to adapt to the metric, how risky, and how much upside there is. It's kinda like antibiotics. Use them too often and the pathogen adapts. It would be an approach that would have to be balanced with others.

For what it's worth I do think it is very silly to announce you are using metrics like this. Ideally you'd not want people to know what tipped you off that they were just cashing checks. You would fire them gradually over several weeks or months, and explain it some way that doesn't easily point back to the filter metrics. This approach of announcing it is like exposing pathogens to a sub-curative dose of medicine.

Anyway, I don't get the sense from the other commenters that the main concern is for the wellbeing of the company -- that they might be at risk of being gamed. I don't think an employee should have an expectation of privacy in at least several of the spaces used in the article as a signal, if any.

I think the problem is this can only work once before you set off a ton of system gaming.

Funny, where I work, someone saying "I haven't 'prod accessed' in 3 weeks" is a humble-brag about being so important that they are only writing design docs and doing high level reviews.

Tell me you work at Google without telling me you work at Google.meme?

Job Title: Inefficient protobuf copier

Can't wait for that day, so that I can write some scripts to check JIRA every minute, scroll through my Gmail inbox at random interval and add likes to my boss's messages on Teams. I'll have the top score in no time.

Obligatory Dilbert https://dilbert.com/strip/1995-11-13

I got someone to cover for me. https://youtu.be/R_rF4kcqLkI?t=174

My employer went this route. Gamified all the developers' output. I quit on the spot and I was not alone.

We will see how it turns out but I still believe that gamifying everything is a bad idea. There's no way to align the incentives with company profits using stupid metrics.

The problem with "gamifying" work is well-known to anyone who actually studies human motivation. Any exercise of control, and especially anything that makes people focus on their performance rather than the actual task they are doing, is bound to decrease motivation and quality. When kids worry about the test and their grade, they learn less. When professional athletes start worrying about the score instead of trusting their bodies, they do worse. This is a pretty basic feature of human psychology, but for some silly reason we think we can outwit it if we make our methods of control "fun" enough.

IMHO, yes and no - I think it’s important to look at both; collective outcomes (net output), and cultural response to threats. I’m Australian and a 100% believer this concept of creating metrics for developers is complete trash and is more a reflection on an inability of leadership to manage and scale a quality engineering culture.

That said, I have worked across APAC and I can see that this metric-driven, fear-based approach can work very effectively to achieve short term gains when applied in some cultures - particularly those where the gap between the haves and the have nots is relatively large.

It is extremely unfortunate that is the case. That said, whilst it is, it perpetuates (not blaming anyone, just is a factual observation) the confidence for sub-par leadership to impose/experiment with such methods.

Couldn't agree more. In the short term it can be very effective. It's much like taking steroids, it will work temporarily but can easily spiral and impose a long-term cost.

> Jira, Confluence, Gmail, chats, documents, dashboards

The top users of these pieces of software have all been canned, since they obviously were doing no real work.

Every single day the world gets closer to the cyberpunk dystopias of science fiction. It's eerie to watch this sort of thing happening in real life.

We are already at that day: https://www.zdnet.com/article/i-looked-at-all-the-ways-micro... discussed on HN here https://news.ycombinator.com/item?id=25816297 and the linked https://www.zdnet.com/article/microsoft-365s-productivity-sc...

Reply on news.ycombinator.com