I mean obviously there are internal problems if that many people are disengaged to the point of needing to be let go, but after reading the letter, if the company follows through on helping everyone find a new job, it could have been worse?
Exactly. If 150 employees are not productive I hesitate to conclude that that's entirely the fault of the employees. Maybe it's not that those people are wholly unproductive, rather that they're culling the worst ones as a weird way of boosting productivity (also scares the others into working harder, I guess)
Want to bet that there was a round of human review applied after the algorithm ran where, at a minimum, employees judged to be high-performing (or otherwise favored) were saved even though they were initially flagged by the AI/data analysis?
I believe the implication there was that low-performers favored by upper management (for reasons like nepotism) were kept as opposed to productive employees whose performance is not reflected in "tick the box" KPIs.
I'd bet your right. This is close to a termination for cause. If someone fired my reports for cause (rather than a we need to lower burn layoff) without my signoff, I'd be right out the door with them.
I am often surprised how often email and slack chat volume corresponds to how productive an employee is. I’ve often had employees I’ve had to fire or resigned that after the fact I check their activity and they basically aren’t doing anything.
But using this data without the context is pretty foolish.
And I’ve seen employees that would stun you with how productive they seem based on how much they post in the corporate chat and email, but on actual review did absolutely nothing besides add to the noise?
A lot of corporate chat/email traffic is the very specific technical questions. For those, you can tell if the person is giving good technical advice or generating noise by reading just a dozen messages.
They probably let go some valuable employees, given that things like this lack nuance entirely. All of the services listed could be considered distractions from work in several
situations depending on the engineer.
Maybe, but as another comment[1] notes, there was probably a human in the loop at some point who was able to "save" people they thought should be kept, regardless of what the data said. Either that, or the process was seeded with an "ignore list" of exceptions.
"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.
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.
> 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.
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.
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.
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.
Some consulting firm came in to the company and decided, based on number of commits (or some such metric), that one particular engineer was the lowest performing engineer on the team. So, management fired them.
Turns out that engineer was the one who everyone side-channeled with to get help when blocked. They were the one who knew the system best and were enabling everyone's productivity, it just didn't show up in the metrics.
Flip side: engineers who curry favor without delivering value can't hide it quite as easily. Those who do their jobs without sucking up have a chance for recognition.
It's pretty cynical to view the person who is helping others get unstuck as "currying favor".
In every place I've worked, the person who has helped me get unstuck has always been one of the most productive and talented members of the team. If they weren't, why would I need their help?
A guy at my job is a gamer and describes it as "buffing the group." Just as in a game, the healer could be the team MVP, but if you measure DPS you are never going to realize it.
Not what I'm saying. I'm saying there are plenty of terrible engineers coasting and this will catch them.
Edit: I've been top of regular productivity charts AND the unanimous answer to "who do you go to to get unstuck?" at at least one company you've heard of. Management regularly promoted the suck ups. Read something like Blind and you'll know how prevalent this is.
Well I take your point and trust that you are productive and well respected by your peers. I guess you mentioning that the flip side of the false negatives is the true negatives (people with low performance metrics who haven't been fired yet due to kissing up) is a correct response. Sorry for the misunderstanding.
I thought your flip side was an alternative perspective on those who help others get unstuck, not on those caught by the HR performance metrics filter.
I'm happy to get people unstuck. It's the best for everyone and the company. I hate when a "growth hacker" moves a meaningless metric an insignificant amount and gets a bonus so some middle manager can get up and claim a "win" that makes more work for me and my team but costs the company money.
I work at a company where code activity is reviewed from time to time by individuals who are at least somewhat familiar with the breadth of activity an Engineer does.
Curiously, it's desirable to both have many PRs and few revisions - but also large ambiguous and difficult PRs. Obviously this can thus be gamed.
Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume.
So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in.
Inheritance? Polymorphism? Interfaces? Not in the generated code for sure. Duplicated code all over. Other engineers were furious but management kept defending him "he's just a junior and his metrics are off the charts, you guys just can't keep up with him".
Three promotions in 18 months and jumped to a FAANG not long after.
I think they were just reorganized when it happened? Or the company had been acquired. Anyways, it became the new way to evaluate devs not long after he joined.
>Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume.
Sorry to hijack your comment, but I would like to say:
There are many, many good reasons why someone would want to quit a job after only a short period of time at a company (harassment being an obvious one). It took me a long time to realize this fact, and stop viewing a quick departure as a potential red flag and also stop asking questions like "Why are you looking for a new role?"
Someone leaving a toxic environment really doesn't want to spend any part of the interview talking about the past; they want to show you they will be a valuable member of your team, while also learning if your company is one they want to work for. We should all consider that the next time we are reviewing resumes and interviewing candidates.
It's still a red flag that needs to be explained. Unfortunately most employees will assume they did not leave voluntarily. The OP's reticence to jump is understandable
That's the way it ought to be, but unfortunately that's not the way it is considered by many in reality, so it's rational for a candidate to want to avoid that situation.
> So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in.
I do this unironically. Mostly for producing unit tests from more sophisticated testing tools. I'm not silly enough to tell my coworkers that's what I'm doing, though.
I’ve worked with a guy who made lots of small commits with the same commit text. You’d look at a pull request with 30 very minor changes possibly in many places with the same message.
Or rather, create team policy to require squashing. I greatly favor this over a million "fix" commits that may or may not compile when you're bisecting.
An old boss of mine used to acknowledge people that had contributed excessively high LoCs at the weekly standup. Typically it used to be an indicator that somebody had completed a large portion of work. Then a new guy started topping the LoC charts every week, and it was discovered that he was reformatting every file he touched to use his preferred indentation scheme.
It was a pretty lighthearted thing to begin with, but they stopped mentioning it entirely after that.
In 1982 Apple was having programmers report lines of code. Bill Atkinson refactored Quickdraw and put down a negative number, -2000 lines of code. Then they stopped asking him to fill out the form. https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Simpson’s Paradox takes many forms. If your sampling or measurement criteria are wrong, even subtlety, then the results are nonsense without anyone knowing. Practicing statistics in an area for which you are not an expert is almost always a bad idea.
LOL, reminded me of my own case. I had the fewest issues closed and longest time to close owned issues. But my boss knew the reasons and was very understanding that I was acting as escalation point for the team. It was the upper management, who was lead by a bean counter CEO, couldn't understand why I was still around with such low productivity. Saving grace was my boss and sales people who kept hearing good things about me from customers.
At a company I used to work the manager of our next money cow project promoted the 2-4 people who committed features the fastest. They were "10 times as fast" as the others and therefore it made sense for him to give them the title of "architects" and give them veto power.
Turns out they spewed out the most ugly, over-engineered and unmaintainable code that all the others had to fix/maintain/understand their mess.
Reminds me of a classic story about Bill Atkinson back in the 80's: TLDR; Management was counting lines of code as their metric of productivity. Which was great until someone actually cleaned up the code base and added -2000 lines of code.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
I was the go-to on almost every team at my last job when there was a hotfix, major risk change, security fix, etc. I knew the whole system pretty well and knew how to find and match up our awful logging to actual code and find the flaw far faster than anybody. I'd develop and test a fix and quietly discuss with that team's tech lead about risk vs reward concerns to see if they agree or want to discuss changes, then I'd get a pull request out there.
The management / executive team would always hear about major crisis hotfixes, then immediately see my name on the high visibility pull request. Thus, they think I personally must have been the cause of the problem. Somehow I was on every team and responsible for every feature, every hotfix, and the poor work every team developed that irritated clients. (Funny how I was never responsible for the positive things, though.)
Then there'd be companywide meeting / email to cover what happened with a screenshot with my name by a hotfix with comments like "Let's not have to do things like this going forward." "Some of us have to actually work for a living, and heh I don't know about you guys but _I_ don't appreciate having to panic review things like THIS!"
Sometimes I have seen the opposite problem, where people look like they do not have enough engagement in customer cases, because most of the bugs are ironed out before the new release is announced.
Similar to an experience I had in my first job - repairing electronics (pcb’s, components, tuning radios and lasers) for supply chain environments and we were (loosely) reported on via how many jobs were completed per day and the average for a technician was somewhere around 5, so 25 per week.
The experienced technicians would leave the base stations though as they took a long time to troubleshoot and repair, so customers would get upset that the turnaround was slow. But these repairs were also profitable because extra labour and parts margin. So I would take them on - win/win I thought - happy customers and billing the expensive jobs, heck someone has to do these jobs. The problem was that you couldn’t complete more than about 1.5 of these jobs per day on average.
Anyway, new lab manager comes in, crunches numbers and they decide my work rate is too low and I’m no longer required…
I still wonder to this day if it had an impact on turnaround of those devices.. I would like to think they realised what they did. I also learnt not to get too far from the herd even if you have the best of intentions.
The only thing surprising about this is it happened in a tight labor market. Perhaps it isn’t tight for this industry/market?
I was in the room one time when HR decided to let go of 250 people based on the sq footage rate of the office they worked in. It’s not at all odd that in the post office world they are looking at other dumb metrics for these decisions.
I don’t think labor market is as tight in the rest of the world rn as it is in the us. The immigration halt over last two years as well as insane equity growth really put upward pressure on comp and so some folks are in a bit of denial here. Not so much in eastern europe
The labor market isn’t tight when it comes to software. The overseas talent is incredible abroad and easy to work with once you have the experience.
As someone who works with multiple teams overseas (Belarus and Ukraine), I have certainly not experienced any issue replacing key team members here in the USA with members abroad. Yeah, sometimes I have to wake up at weird hours, but we get things done.
This approach has been so successful, that lately we only hire architect level engineers in the USA. For all other roles we prefer to hire abroad through specific consulting firms.
Is that new? I’ve been involved with teams like that going back 20 years but when it gets hard to hire USA based devs it trickles down to those contractors too.
I’m not in a position to hire Eastern European contractors currently but do see how tight the market is otherwise and my experience would suggest increased contractor billing rates and/or more constraints on when you can dip into the contractor pool?
Depending on the nature of the employee’s role, looking at hard metrics gathered from the systems the employee works in seems like something every line manager already does. One could argue that a system capable of essentially automating part of the manager’s job is a net positive and could increase productivity and possibly even fairness in evaluating some aspects of performance.
But at most, this should be supplemental information considered in a proper evaluation process, not the sole source.
Things quickly go south when they start to involve “softer” signals like email activity.
And further still that the direct outcome was immediate termination and not some kind of performance improvement period.
Perhaps this last part is not present in the Russian workplace, I’m not familiar.
I can’t help but feel like this is a real life slippery slope that came fully to fruition.
It sounds great, honestly. Sounds like his employees are working more for less pay. I know he's insulting his employees but still pretty awesome if he actually found a better position for his people.
Who doesn't want to make more and work less? I wish I could make money while doing nothing.
> It sounds great, honestly. Sounds like his employees are working more for less pay. I know he's insulting his employees but still pretty awesome if he actually found a better position for his people.
Given the tone of the rest of the letter I don't think that statement can be taken at face value, it comes across much more like a backhanded jibe adding insult to injury
Exactly what I was thinking. Pure speculation, but they needed to do a big layoff so they come up with a "process" instead of making the news "we're not doing well so we had to lay off 150 people".
This reminds me of Ted Talks about the original thinkers by Adam Grant: https://www.youtube.com/watch?v=fxbCHn6gE3U
Just because these people are not behaving or contributing the same way like others, it doesn't mean they are worthless.
If company design the work "game" like such, people will try to cheat the game like automatically producing whole bunch of crap on daily basis - is that productive? Then, they will have to figure out an anti-cheat, on and on. Play stupid game, get stupid prizes.
For people who might want to work for them, this really a turn off. What kind of potential metrics they could be looking for next? If a person made a 2000 line code that impacted the whole company, but that's all the code that person produced, should he/she get fired for being unproductive? What a rabbit hole!
The letter is so unprofessional it makes me question the validity of the decision making more than I otherwise would. An email dripping with sarcasm has no purpose here except to make the CEO feel tickled inside, it's masturbatory.
Also - what’s the deal with exactly 150 employees being laid off - clearly not trying to identify problematic employees, but instead finding an excuse/methodology to lay off a specific quantity of workforce.
Wow that's crazy. 150 at the same time? I'm not sure how long did it took him to review all of those before taking that kind of decision.
But again not sure if that's the whole reason behind the action, maybe the company is not doing so well at the same time? That's why they needed to change.
Regardless of the reason, I'm sure firing 150 people at the same time will give you some backslash in any way. Good luck to all those 150 employee for their future
In my first job, I took standup to be a pace keeping device, so for a while I would hack together something to have it ready, or if I did two things in a day, I would withhold one to have something to report the next day.
I did not continue to do that as when a task carried over into the next day I wasn’t hassled about it, but whenever things like this occur I have to wonder if there are places where this strategy would be required.
Busyness is not productivity. But organizations have a history of using metrics that measure 'busyness' when they say they are measuring productivity. Things like how often you are seen at the water cooler or chatting with a co-worker, how quickly you respond to communications, how quickly can you be reached, any time, anywhere, whenever someone wants to reach you.
I know employers can see your internal "private" communications, but it is also illegal, at least in most Western countries, to actively watch and spy on your employees. Would they have some recourse if it was say the US?
I think that's an excellent practice - not as a way of gaming the system, but for maintaining useful documentation about what happened and why.
A bug fix without an associated ticket is missing context: who spotted the bug? When? What were the steps to reproduce?
Even a ticket with no content is valuable - it gives me somewhere I can post additional comments and screenshots later, or link to other related tickets.
I do that (1 commit = 1 bug). Mostly to have a nice nested structure of bugs at the end of the quarter to help write my performance reviews. The bugs are linked in a parent-child relationship going from high-level 'user journey' bugs, to mid-level feature planning bugs, to individual commit bugs.
Uh yeah… that’s how it’s supposed to happen. Every code change should have a ticket/issue, a bit branch, and a pull request attached - no matter how small.
What’s not supposed to happen is have those analysed to be used as some dumb proxy for productivity/output.
This looks like the inverse of "everyone needs to come back to the office so that we know you are working".
I doubt this will go well since if it keeps happening unproductive people will become the best at gaming the system.
But at the same time, there has to be a better way than being observed by a boss in a physical office. I don't want to commute just because people on my team who were unproductive in the office are now just as unproductive at home and not seeing their face daily makes it hard to tell if they took another job and just haven't told anyone.
I'm Russian, I'm aware about context. "Work less and earn more" is sort of idiom. Not exactly, but close to that. Yes, that was a sarcasm, and yes it's pretty harsh.
Funny, I can draw a pretty substantial parallel between “getting stuff done” and “hours of time to work on a problem uninterrupted by pointless chat and E-mail”.
We’re still incredibly limited in what behaviors do and don’t increase a teams productivity. I’ve worked in groups where some of the least productive people were also maybe the most valuable. Very strong in keeping cohesion and moral up inside the team. Whether it was the way they smiled or greeted people when they saw them or the way they just knew how to spot someone who was tangling with a problem and instinctively knew how to nudge that person away from the edge. I still cant even slightly pin down precisely what people like this bring, but I know I know this …thing… exists and it’s something important.
And when given the choice I’ve seen teams almost battle to get these “low producers” into the group even though their output wasn’t top-tier.
I don’t know how we measure for these slippery traits without falling into woo traps but until we figure out what to look for, great team building will remain an art.
We’re nowhere near a point where we can accurately measure the weird and chaotic quirks that make up a top-tier team. Building a team is still far more of an art more than a science.
I get letting a person or two go who have clearly demonstrated they’re not a good fit, but I can’t help but wonder how much of the kool-aid this company has drank to think firing this many people based on weird data measurements was at all a good idea.
153 comments
[ 3.8 ms ] story [ 132 ms ] threadI mean obviously there are internal problems if that many people are disengaged to the point of needing to be let go, but after reading the letter, if the company follows through on helping everyone find a new job, it could have been worse?
Exactly. If 150 employees are not productive I hesitate to conclude that that's entirely the fault of the employees. Maybe it's not that those people are wholly unproductive, rather that they're culling the worst ones as a weird way of boosting productivity (also scares the others into working harder, I guess)
But using this data without the context is pretty foolish.
1 https://news.ycombinator.com/item?id=28069040
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.
Obligatory Dilbert https://dilbert.com/strip/1995-11-13
—- Snowcrash
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."
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.
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.”
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.
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.
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.
The top users of these pieces of software have all been canned, since they obviously were doing no real work.
Some consulting firm came in to the company and decided, based on number of commits (or some such metric), that one particular engineer was the lowest performing engineer on the team. So, management fired them.
Turns out that engineer was the one who everyone side-channeled with to get help when blocked. They were the one who knew the system best and were enabling everyone's productivity, it just didn't show up in the metrics.
I wonder how many false positives they got here.
In every place I've worked, the person who has helped me get unstuck has always been one of the most productive and talented members of the team. If they weren't, why would I need their help?
Source: was a priest in WoW back in the day. Because nobody else wanted to, not because my warlock sucked.
Edit: I've been top of regular productivity charts AND the unanimous answer to "who do you go to to get unstuck?" at at least one company you've heard of. Management regularly promoted the suck ups. Read something like Blind and you'll know how prevalent this is.
I thought your flip side was an alternative perspective on those who help others get unstuck, not on those caught by the HR performance metrics filter.
Curiously, it's desirable to both have many PRs and few revisions - but also large ambiguous and difficult PRs. Obviously this can thus be gamed.
Long ago, he joined a company fresh out of college that pretty much measured dev productivity with number of lines written. He quickly realized that it was a red-flag, but jumping ship so soon was going to be hard to explain on a resume.
So he basically started writing code in two stages using a codegen tool: something high level not under source control that would generate extremely verbose code that would be checked-in.
Inheritance? Polymorphism? Interfaces? Not in the generated code for sure. Duplicated code all over. Other engineers were furious but management kept defending him "he's just a junior and his metrics are off the charts, you guys just can't keep up with him".
Three promotions in 18 months and jumped to a FAANG not long after.
Sorry to hijack your comment, but I would like to say:
There are many, many good reasons why someone would want to quit a job after only a short period of time at a company (harassment being an obvious one). It took me a long time to realize this fact, and stop viewing a quick departure as a potential red flag and also stop asking questions like "Why are you looking for a new role?"
Someone leaving a toxic environment really doesn't want to spend any part of the interview talking about the past; they want to show you they will be a valuable member of your team, while also learning if your company is one they want to work for. We should all consider that the next time we are reviewing resumes and interviewing candidates.
Nobody expects someone to get married after a couple dates.
I do this unironically. Mostly for producing unit tests from more sophisticated testing tools. I'm not silly enough to tell my coworkers that's what I'm doing, though.
[0] https://github.com/artiebits/fake-git-history
It was a pretty lighthearted thing to begin with, but they stopped mentioning it entirely after that.
1 - https://news.ycombinator.com/item?id=10734815
Metrics are frequently inaccurate and easy to game.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Career red flag right here.
Turns out they spewed out the most ugly, over-engineered and unmaintainable code that all the others had to fix/maintain/understand their mess.
https://www.youtube.com/watch?v=kHI7RTKhlz0
The management / executive team would always hear about major crisis hotfixes, then immediately see my name on the high visibility pull request. Thus, they think I personally must have been the cause of the problem. Somehow I was on every team and responsible for every feature, every hotfix, and the poor work every team developed that irritated clients. (Funny how I was never responsible for the positive things, though.)
Then there'd be companywide meeting / email to cover what happened with a screenshot with my name by a hotfix with comments like "Let's not have to do things like this going forward." "Some of us have to actually work for a living, and heh I don't know about you guys but _I_ don't appreciate having to panic review things like THIS!"
This reminds me of one of Udacity's first classes: do firefighters cause fires? https://www.youtube.com/watch?v=Ku9E9uKyr4E
The experienced technicians would leave the base stations though as they took a long time to troubleshoot and repair, so customers would get upset that the turnaround was slow. But these repairs were also profitable because extra labour and parts margin. So I would take them on - win/win I thought - happy customers and billing the expensive jobs, heck someone has to do these jobs. The problem was that you couldn’t complete more than about 1.5 of these jobs per day on average.
Anyway, new lab manager comes in, crunches numbers and they decide my work rate is too low and I’m no longer required…
I still wonder to this day if it had an impact on turnaround of those devices.. I would like to think they realised what they did. I also learnt not to get too far from the herd even if you have the best of intentions.
I was in the room one time when HR decided to let go of 250 people based on the sq footage rate of the office they worked in. It’s not at all odd that in the post office world they are looking at other dumb metrics for these decisions.
As someone who works with multiple teams overseas (Belarus and Ukraine), I have certainly not experienced any issue replacing key team members here in the USA with members abroad. Yeah, sometimes I have to wake up at weird hours, but we get things done.
This approach has been so successful, that lately we only hire architect level engineers in the USA. For all other roles we prefer to hire abroad through specific consulting firms.
I’m not in a position to hire Eastern European contractors currently but do see how tight the market is otherwise and my experience would suggest increased contractor billing rates and/or more constraints on when you can dip into the contractor pool?
But at most, this should be supplemental information considered in a proper evaluation process, not the sole source.
Things quickly go south when they start to involve “softer” signals like email activity.
And further still that the direct outcome was immediate termination and not some kind of performance improvement period.
Perhaps this last part is not present in the Russian workplace, I’m not familiar.
I can’t help but feel like this is a real life slippery slope that came fully to fruition.
But not a system that could automate a regular workers' job so they don't have to be constantly checking Jira, Confluence, Slack, mail, etc, etc?
Wow you're really selling it for us. PR nightmare.
Who doesn't want to make more and work less? I wish I could make money while doing nothing.
You believe the CEO's claims?
I bet he has a bridge he'll see you too...
> If you want to stay in contact with me, please write me a long letter about all your observations, injustice, and gratitude.
Still nothing on your sarcasm detector?
If company design the work "game" like such, people will try to cheat the game like automatically producing whole bunch of crap on daily basis - is that productive? Then, they will have to figure out an anti-cheat, on and on. Play stupid game, get stupid prizes.
For people who might want to work for them, this really a turn off. What kind of potential metrics they could be looking for next? If a person made a 2000 line code that impacted the whole company, but that's all the code that person produced, should he/she get fired for being unproductive? What a rabbit hole!
But again not sure if that's the whole reason behind the action, maybe the company is not doing so well at the same time? That's why they needed to change.
Regardless of the reason, I'm sure firing 150 people at the same time will give you some backslash in any way. Good luck to all those 150 employee for their future
I did not continue to do that as when a task carried over into the next day I wasn’t hassled about it, but whenever things like this occur I have to wonder if there are places where this strategy would be required.
https://maxfrenzel.medium.com/in-praise-of-deep-work-full-di...
It sort of makes sense when you realize that "busy", in that context, just refers to the kind of busywork that can be interrupted without loss.
https://mmos.com/news/chronicles-of-elyria-class-action-laws...
A bug fix without an associated ticket is missing context: who spotted the bug? When? What were the steps to reproduce?
Even a ticket with no content is valuable - it gives me somewhere I can post additional comments and screenshots later, or link to other related tickets.
What’s not supposed to happen is have those analysed to be used as some dumb proxy for productivity/output.
I doubt this will go well since if it keeps happening unproductive people will become the best at gaming the system.
But at the same time, there has to be a better way than being observed by a boss in a physical office. I don't want to commute just because people on my team who were unproductive in the office are now just as unproductive at home and not seeing their face daily makes it hard to tell if they took another job and just haven't told anyone.
Earn more and work less?
That's weird.
Those poor folks who still work for him will be working more and earning less than those he fired.
And when given the choice I’ve seen teams almost battle to get these “low producers” into the group even though their output wasn’t top-tier.
I don’t know how we measure for these slippery traits without falling into woo traps but until we figure out what to look for, great team building will remain an art.
We’re nowhere near a point where we can accurately measure the weird and chaotic quirks that make up a top-tier team. Building a team is still far more of an art more than a science.
I get letting a person or two go who have clearly demonstrated they’re not a good fit, but I can’t help but wonder how much of the kool-aid this company has drank to think firing this many people based on weird data measurements was at all a good idea.