"A Stanford researcher says data on programmer productivity suggests 14 percent of remote software engineers get barely anything done."
Having managed a team of in office devs, I can say that easily 14% or more get barely anything done from the office. Low performers are going to cash paychecks and underwork where ever they are. Bringing low performers back to the office won't help anything.
PIPing people is harder than most people realize and is also very work intensive. Sometimes is easier to let underperformers coast than the red tape and work that goes into PIPing someone out. I’ve very rarely ever seen anyone fired from underperformance that hadn’t been on at least a 3 month PIP.
Yeah, the issue is pretty specific to big corps. I'm not gonna take on a huge workload and drama to get someone fired.
To be more specific, lay off difficulties are at the complex of a ton of corporate management failures. These include poor oversight and supervision, legal paranoia, and low skin in the game.
I've been at startups where someone who isn't cutting it will be laid off in a week.
Not in large corporations. Typically, this is what happens for full time employees:
1. The manager decides the employee should go.
2. The manager reaches out to the Human Resources department. They explain what the manager has to do to ensure that the employee can be fired without causing the company to get sued.
3. The manager meets with the employee and puts them on a performance improvement plan. Typically, the employee is given goals they must meet to keep their job. The manager documents the employee's performance. The documentation's goal is to ensure that the company can avoid a lawsuit if the employee is fired.
4. PIPs last about 3 months.
5. If the employee meets the goals, the employee is taken off of the PIP and stays on the team.
6. If the employee did not meet the goals, the employee is fired.
Note it is a lot of work and this has been going on for decades. There are a few problems with this process:
A. Teams are stuck with poor performers because managers cannot quickly get rid of them.
B. A lot of time, the employee on the PIP has no chance. The manager wants him gone and unless the employee does an amazing job, that employee will be fired no matter what.
OK, this is bullshit. I have worked for a lot of managers and frankly, almost all of them worked hard and tried to do the right thing. Managers are people too and we need them because they ensure that the right work is done, and that the team is solving problems customers, and the organization care about.
You have explained that managers are in fact people and what value you think engineering managers provide to an organization.
You have not addressed the commenter’s assertion that >= 14% of managers do nothing. You may have even bolstered their point by saying “almost all of [the managers you have worked with] work hard.” I think it’s fair to consider 84% to be reasonably in the bounds of “almost all.”
Firing people is hard and fraught with peril legally for a large company in the US. It was simply easier to marginalize them and get things done in spite of them. That was my strategy anyhow. My management discouraged me from making a further issue of it lest someone outside the org start asking questions about how we had people on the payroll doing exactly nothing for so long. Keep in mind that this was a team I was put in charge of, not a team I built from the ground up and groomed as my own. I inherited organizational mistakes/neglect and the organization was happy to not have them see the light of day that correcting the situation would bring.
I think I can explain why it appears that there are ghost engineers. My favorite metaphor is a one-lane road vs a two lane road.
On a one lane road, you can only travel as fast as the slowest car on the road. A two-lane road is far more efficient than two one-lane roads are.
But think of how programming teams are organized. Typically, there's only one programmer who is expert enough for a certainly functionality to fix bugs (faster than they introduce new ones, anyways.)
That means the bug takes a one-lane road to and from the programmer who is going to fix it. The programmer can only fix bugs as fast as it takes him to fix the hardest, and slowest bug.
So, say you have a service-level agreement with your customers--if they file a bug, you'll fix it in 5 days. So a bug comes in--what if the only programmer who can fix it is already in the middle of fixing a 5-day bug?
So obviously, more programmers need to be hired. If you have two programmers who are in charge of each functionality, it's like having a 2-lane road instead of a 1 -lane road. You have VASTLY shorter turn-around times on average. While one programmer is fixing a 5-day bug, another one can be working on five 1-day bugs.
But....now what? You hire double the number of programmers? So every programmer, old and new, is idle around 50% of the time? That is where the so-called "Ghost Programmers" come from.
So, the obvious thing to do is fire half the programmers. Great. Say you do that. Say you have 1 programmer on your team, who writes tight, efficient, virtually bug-free code which is so generic that it can handle not only the current requirements but also handles a lot of the future requirements. So this programmer is still not as busy as that guy who introduces a new bug every time he fixes an old one. THAT guy's mouse is moving a lot, THAT guy is busy staying after 5:00pm every day....
...and THAT guy gets to keep his job when management wants to fire all of the ghost programmers.
I think one reason this is so contentious is that it really depends on where you work.
I have worked at a bank and this is definitely true. I have also worked at Amazon and Meta, and it was significantly less true there. I don't think I knew a single ghost at Amazon.
But it was a common joke at the bank that 'that's Bob. No one knows what Bob's job is'. Straight out of the movie office space.
Anyone who has worked in an office for any length of time can tell you that that number is significantly higher than 14%. And even more so for managers.
I don't think this article, or the underlying claims, are (yet) credible. I'm disappointed that the Washington Post wrote about this at all, and that people I respect a lot have amplified it on Twitter.
The claims come from an MBA student graduating from Stanford this year, who plans on starting a developer tooling company. [1] The faculty member (a professor of psychology) who supported this work doesn't comment at all on the claims made by the student; their single quote in the article instead emphasizes how difficult it is to measure productivity.
The claims are based on, from their own description, unpublished ongoing research. There's no description of what data they gathered, what their methods were, or how they assessed accuracy anywhere. (For starters: how did they identify who a software engineer was in each of the companies in their dataset? How did they exclude data scientists, or technical writers, or other engineering-adjacent folks who in some companies need to commit infrequently? How did they identify remote workers, and handle workers transitioning between roles or working arrangements?)
Without this extremely basic information, I think it makes sense to just ignore it. It's possible that it'll eventually pan out as real! But definitely not yet. Wild that people are taking it seriously.
Hello! I have done this sort of research internally at companies and have coordinated with the world’s leading researchers in developer productivity for a long time.
Myself and every other leading researcher in the field that I have spoken to have serious concerns about this supposed “research.” For example, you can see a post here from Margaret Anne-Storey, who is arguably the world’s leading researcher in developer productivity:
I share her concerns. I have asked Yegor multiple times when he plans to publish his research methodology for review by others and he has not even answered my question. That is, he hasn’t even said “it’s under review and we will publish it by _____.” He’s certainly argued with me about the validity of his results, but suspiciously has not actually published any research methodology as far as I have been able to find.
This is very concerning, because I have worked with this type of data set extensively. I am possibly one of the world’s leading experts in using and analyzing this type of data, and I can tell you that it is fraught with data anomalies of the sort that would easily cause an incorrect result here. For example, you might believe all developers are working in GitHub, but then it turns out the company has 10% of developers contributing to some other source control system. Or one of your GitHub orgs isn’t instrumented correctly. Or some of those people aren’t actually software engineers even though they have a title that _looks_ like that. The list goes on and on, and these are _real_ problems that happen in the data at _every_ company.
Im frankly shocked that the Washington Post or any other credible media organization is publishing this without any verification or background on the validity of the research.
I am fully willing to believe that some engineers don’t do work, or do very little. I’ve seen it. But if you’re going to claim that you did research for a University, with the University’s name on it, I expect things like a published paper, understanding the margin of error on your published numbers, etc. especially in a field that is so prone to errors in the data.
30 comments
[ 4.0 ms ] story [ 83.6 ms ] threadI thought it was clear that management was a large part of the problem.
Having managed a team of in office devs, I can say that easily 14% or more get barely anything done from the office. Low performers are going to cash paychecks and underwork where ever they are. Bringing low performers back to the office won't help anything.
To be more specific, lay off difficulties are at the complex of a ton of corporate management failures. These include poor oversight and supervision, legal paranoia, and low skin in the game.
I've been at startups where someone who isn't cutting it will be laid off in a week.
2 week notice, both ways, seems to be the norm nowadays.
1. The manager decides the employee should go.
2. The manager reaches out to the Human Resources department. They explain what the manager has to do to ensure that the employee can be fired without causing the company to get sued.
3. The manager meets with the employee and puts them on a performance improvement plan. Typically, the employee is given goals they must meet to keep their job. The manager documents the employee's performance. The documentation's goal is to ensure that the company can avoid a lawsuit if the employee is fired.
4. PIPs last about 3 months.
5. If the employee meets the goals, the employee is taken off of the PIP and stays on the team.
6. If the employee did not meet the goals, the employee is fired.
Note it is a lot of work and this has been going on for decades. There are a few problems with this process:
A. Teams are stuck with poor performers because managers cannot quickly get rid of them.
B. A lot of time, the employee on the PIP has no chance. The manager wants him gone and unless the employee does an amazing job, that employee will be fired no matter what.
You have not addressed the commenter’s assertion that >= 14% of managers do nothing. You may have even bolstered their point by saying “almost all of [the managers you have worked with] work hard.” I think it’s fair to consider 84% to be reasonably in the bounds of “almost all.”
So is it bullshit?
The latter especially so, in office environments, where getting in everyone's business is used to feign productivity.
I see this so often, everywhere. The useless people make the most noise, the productive ones are too busy.
https://news.ycombinator.com/item?id=42257693
Its a bit suspicious. Is he selling something?
Doesn't it devalue the research they do to have non peer reviewed work by an MBA student, using questionable means, being reported this widely.
https://poetsandquants.com/2023/02/21/from-middle-school-dro...
On a one lane road, you can only travel as fast as the slowest car on the road. A two-lane road is far more efficient than two one-lane roads are.
But think of how programming teams are organized. Typically, there's only one programmer who is expert enough for a certainly functionality to fix bugs (faster than they introduce new ones, anyways.)
That means the bug takes a one-lane road to and from the programmer who is going to fix it. The programmer can only fix bugs as fast as it takes him to fix the hardest, and slowest bug.
So, say you have a service-level agreement with your customers--if they file a bug, you'll fix it in 5 days. So a bug comes in--what if the only programmer who can fix it is already in the middle of fixing a 5-day bug?
So obviously, more programmers need to be hired. If you have two programmers who are in charge of each functionality, it's like having a 2-lane road instead of a 1 -lane road. You have VASTLY shorter turn-around times on average. While one programmer is fixing a 5-day bug, another one can be working on five 1-day bugs.
But....now what? You hire double the number of programmers? So every programmer, old and new, is idle around 50% of the time? That is where the so-called "Ghost Programmers" come from.
So, the obvious thing to do is fire half the programmers. Great. Say you do that. Say you have 1 programmer on your team, who writes tight, efficient, virtually bug-free code which is so generic that it can handle not only the current requirements but also handles a lot of the future requirements. So this programmer is still not as busy as that guy who introduces a new bug every time he fixes an old one. THAT guy's mouse is moving a lot, THAT guy is busy staying after 5:00pm every day....
...and THAT guy gets to keep his job when management wants to fire all of the ghost programmers.
I have worked at a bank and this is definitely true. I have also worked at Amazon and Meta, and it was significantly less true there. I don't think I knew a single ghost at Amazon.
But it was a common joke at the bank that 'that's Bob. No one knows what Bob's job is'. Straight out of the movie office space.
The claims come from an MBA student graduating from Stanford this year, who plans on starting a developer tooling company. [1] The faculty member (a professor of psychology) who supported this work doesn't comment at all on the claims made by the student; their single quote in the article instead emphasizes how difficult it is to measure productivity.
The claims are based on, from their own description, unpublished ongoing research. There's no description of what data they gathered, what their methods were, or how they assessed accuracy anywhere. (For starters: how did they identify who a software engineer was in each of the companies in their dataset? How did they exclude data scientists, or technical writers, or other engineering-adjacent folks who in some companies need to commit infrequently? How did they identify remote workers, and handle workers transitioning between roles or working arrangements?)
Without this extremely basic information, I think it makes sense to just ignore it. It's possible that it'll eventually pan out as real! But definitely not yet. Wild that people are taking it seriously.
[1] https://poetsandquants.com/2023/02/21/from-middle-school-dro...
Myself and every other leading researcher in the field that I have spoken to have serious concerns about this supposed “research.” For example, you can see a post here from Margaret Anne-Storey, who is arguably the world’s leading researcher in developer productivity:
https://www.linkedin.com/posts/margaret-anne-storey-8419462_...
I share her concerns. I have asked Yegor multiple times when he plans to publish his research methodology for review by others and he has not even answered my question. That is, he hasn’t even said “it’s under review and we will publish it by _____.” He’s certainly argued with me about the validity of his results, but suspiciously has not actually published any research methodology as far as I have been able to find.
This is very concerning, because I have worked with this type of data set extensively. I am possibly one of the world’s leading experts in using and analyzing this type of data, and I can tell you that it is fraught with data anomalies of the sort that would easily cause an incorrect result here. For example, you might believe all developers are working in GitHub, but then it turns out the company has 10% of developers contributing to some other source control system. Or one of your GitHub orgs isn’t instrumented correctly. Or some of those people aren’t actually software engineers even though they have a title that _looks_ like that. The list goes on and on, and these are _real_ problems that happen in the data at _every_ company.
Im frankly shocked that the Washington Post or any other credible media organization is publishing this without any verification or background on the validity of the research.
I am fully willing to believe that some engineers don’t do work, or do very little. I’ve seen it. But if you’re going to claim that you did research for a University, with the University’s name on it, I expect things like a published paper, understanding the margin of error on your published numbers, etc. especially in a field that is so prone to errors in the data.