100% agree with this - it's dangerous to look at code changes alone for productivity. That said, I have worked with multiple "ghost engineers" in the past (because I knew their non-code...
Some senior engineers “can very reasonably commit no code,” McKenzie said, for example because they are planning out software architecture or training new engineers. “That person isn’t a ghost, and that person isn’t coasting,” he added.
100% agree with this - it's dangerous to look at code changes alone for productivity. That said, I have worked with multiple "ghost engineers" in the past (because I knew their non-code contributions add up to zilch, too). I could have been frustrated that they weren't helping, but I ultimately decided that, since I wasn't a manager, it wasn't my problem.
Beyond just "not looking at code changes only", you have to consider what sort of work the developer is doing as well. Green field code will always have faster development than legacy code....
Beyond just "not looking at code changes only", you have to consider what sort of work the developer is doing as well. Green field code will always have faster development than legacy code. Working in critical parts of the code will go much, much more slowly than working further from the core functionality. Working in code that is poorly (or not at all) unit tested will take much longer than something that has automated tests.
Metrics like the one the company in this article is trying to push with (what seem like to me) ass pulled statistics are just going to incentivise developers to take the most-bang-for-the-buck work themselves and push off (or fight over who has to do) the vital, but difficult stuff. And WaPo seems to to swallow it almost wholesale, with only minor criticism at the very bottom of the article.
Heck, for larger companies you can spend weeks in meetings and more meetings over your code review and trying to satisfy multiple parties for some particular feature. You wish they would have...
Heck, for larger companies you can spend weeks in meetings and more meetings over your code review and trying to satisfy multiple parties for some particular feature. You wish they would have intervened earlier in the feature development, but part of code review is to properly bring out those stakeholders and make sure everyone's aligned.
It’s somewhat rarer than people make it out to be but it’s real. I find it’s most common on large teams with one line manager. Often the line manager is so overwhelmed (like, 40 hours of meetings...
It’s somewhat rarer than people make it out to be but it’s real. I find it’s most common on large teams with one line manager. Often the line manager is so overwhelmed (like, 40 hours of meetings a week + normal duties) that they have no idea what half of their team is actually doing.
Combine that with, say, infra work or something else that doesn’t move very fast, and it’s easy to make shit up at standup for a year.
I guess the solution is you should have more managers? I know the managerial class isn’t all that well liked, but for line managers I wouldn’t really consider it a good thing to not have enough as an IC. Middle management at the skip and above level is another story.
The "solution" I usually see is that they try to use "team leaders", which are senior engineers who are supposed to mentor and keep an eye on the rest of the team. The mentoring part is ok, but I...
The "solution" I usually see is that they try to use "team leaders", which are senior engineers who are supposed to mentor and keep an eye on the rest of the team. The mentoring part is ok, but I think most senior engineers are not in management for a reason, and don't want to be responsible for any "ghosts" so they just do the work themselves.
I ended up as a technical team leader. In theory I was supposed to be coding, but largely I just attended meetings that didn't need to happen so that the more junior members of the team didn't...
I ended up as a technical team leader. In theory I was supposed to be coding, but largely I just attended meetings that didn't need to happen so that the more junior members of the team didn't have to attend. Even of the important meetings, me or my team were only "needed" about half the time.
This was fine when they let us work from home and I could do other things (many of which were not work related), but as soon as we went back to the office, it was just mind numbingly awful.
I have since found a remote job where they have a much flatter structure, so there's no worry of accidentally becoming a manager, and I'm actually engaged with my work instead of just tuning out. While I suspect they refilled my position at my previous company, the truth is that my role was largely just knowing things, and about 1 hour per week (split into 5 minute increments) of telling other people what I knew.
different tracks, different pay grades. I personally never want to pursue a lead/management track. And even if I did, that's usually a higher paying position. I sure would not want an...
different tracks, different pay grades. I personally never want to pursue a lead/management track.
And even if I did, that's usually a higher paying position. I sure would not want an anti-promotion in this day and age if I can afford not to. It's just good work/life balance to put a foot down and say "no, I am not this team's lead, I'm busy enough as is with my existing work".
It goes the other way as well. Some aren’t managers because of their definitions or behaviors. I’ve worked under someone like that who straight up derailed me multiple times and then my ACTUAL...
It goes the other way as well. Some aren’t managers because of their definitions or behaviors. I’ve worked under someone like that who straight up derailed me multiple times and then my ACTUAL manager would get upset
Yeah I've seen quite a few of these ghosts. Actually, I've more commonly seen "vampire engineers". These are people who actually subtract productivity from the rest of the team. Either they need...
Yeah I've seen quite a few of these ghosts. Actually, I've more commonly seen "vampire engineers". These are people who actually subtract productivity from the rest of the team. Either they need too much guidance to get tasks done, or they create work that has to be rewritten by someone else. Sometimes these are identified by management but it is hard to fire people, even though we don't have unions in software development in the US. This is probably a main reason why my company usually uses contractor-to-hire - contractors can be fired without cause.
Anyway, yes this is a flaw in corporate culture. I've worked on teams that had great engineers and poor engineers. I don't think I've worked on one that had great managers. Seems like the purpose of managers would be to make sure that tasks are completed, and to know who actually contributed to this. For some reason this is usually very hard for them. They only seem to know the "superstar engineers" and the ones that are good at self promotion. The rest of the employees are often sort of invisible. If the managers would just do their jobs, they could identify productivity properly (and wouldn't have to rely on key-logging and internet monitoring and whatever other employee spying they do).
Years ago I was in a group that tried to fix this issue. They engaged with Gallop and got into First, Break All the Rules. We would take surveys which had intentionally weird questions that were designed to uncover ineffective managers. Well, the managers couldn't have this so they coached the employees on the survey which poisoned the result. And this farce was not detected by the upper management, or they didn't care.
Thanks, you've finally explained why so many of my colleagues are contractors but have been with the company for 5+ years. That always made me scratch my head (UK based company). I also have a...
This is probably a main reason why my company usually uses contractor-to-hire - contractors can be fired without cause.
Thanks, you've finally explained why so many of my colleagues are contractors but have been with the company for 5+ years. That always made me scratch my head (UK based company).
I also have a "vampire engineer" on my team who saves me about 5 hours a week in busy work (that I could honestly have automated if I had the time) but creates about 10 hours a week of work for me to fix his shit, re-explain something that he should know because I literally gave him the documentation three weeks ago, or asks so many questions that it's easier for me to just do it because it takes more time to explain than to just do it and he doesn't seem to learn anyway.
Management is well aware and have given him chance after chance but since he's not a contractor, very difficult to fire. I do try to have some empathy since he's young (Gen Z young), English isn't his first language, and I was once fired for asking too many questions at a job where I had zero knowledge of the products, but I at least made improvements and learned. Haven't seen much of either from him.
that's fortunately no longer legal in many key US states. Thanks Microsoft. Of course they just loophole around it with something like an 18 month contract + a break before making another 18 month...
you've finally explained why so many of my colleagues are contractors but have been with the company for 5+ years
that's fortunately no longer legal in many key US states. Thanks Microsoft.
Of course they just loophole around it with something like an 18 month contract + a break before making another 18 month contract. But the spirit of the law is still good.
Hard to fire people? It's a nuisance. You have to thoroughly document their failings, a plan to correct them, and how the person failed to live up to the plan. Happens plenty often—often enough...
Hard to fire people? It's a nuisance. You have to thoroughly document their failings, a plan to correct them, and how the person failed to live up to the plan.
Happens plenty often—often enough that I quit Big Tech and management. There are misanthropes, sure, who are gaming the system. But there are also at least as many or more people who are trying their level best and were either a poor hire (interview processes are generally garbage), weren't able to/supported adequately as the needs of the job changed around them, or were simply obviated by the business no longer needing them in that role.
Businesses most often choose expediency. Most see it as easier to fire a person and hire a person who is a better fit. Performance Improvement Plans rarely end in continued employment (though I worked hard to set up mine for success and saw about a 50% pass rate).
Sure, I had at least one engineer who was almost certainly working a side gig. They attended just enough meetings, and were impactful enough in those meetings, that adjacent teams were pleased. However, I and my own team members could see how the person was otherwise absent for their own team, leaving coworkers in the lurch when it was their job to support them as a Staff (a senior) engineer.
You have to either be a cold-hearted bastard or have amazingly high emotional intelligence and mental health to survive in management. The logistical and process work is fine: that's about making things better at scale. Coaching people with compassion in their growth and seeing them win is great. Coaching on failures, when the person is unable or unwilling, is hell.
EDIT: Toeing the line, when your management expects you to behave in ways that are unethical: that's when I give them the finger and quit. I suppose many other managers just cave and do the unethical thing.
It's a hard mix. Because the great managers have a background with people, business, and the technical work all at once. These days many companies simply skimp on the 3rd, costing product quality...
I don't think I've worked on one that had great managers. Seems like the purpose of managers would be to make sure that tasks are completed, and to know who actually contributed to this.
It's a hard mix. Because the great managers have a background with people, business, and the technical work all at once. These days many companies simply skimp on the 3rd, costing product quality and/or future pipeline issues. Those that can only see the loud and obvious contributors are definitely those who skimp on the 3rd, since they cannot properly understand and recognize how a typical engineer works day-to-day.
And this farce was not detected by the upper management, or they didn't care.
Probably didn't care, sadly. Like anyone else, there is a bit of efficiency sacrificed for self-preservation. People are rarely paid to be "great X". People are even more rarely paid enough to be that anyway.
About “9.5% of software engineers do virtually nothing,” Denisov-Blanch wrote on X, contributing so little code he suspects they are either slacking off or secretly cashing two tech paychecks. He termed such freeloaders “ghost engineers.”
After Denisov-Blanch’s post was viewed nearly 4 million times, some self-professed ghost engineers contacted him. In messages that ranged from defensive to profane and enraged, emails viewed by The Washington Post showed, they confessed to taking advantage of what they view as broken corporate cultures — often claiming it wasn’t their fault.
Denisov-Blanch shared his findings, from ongoing research not yet published in peer-reviewed form, after a Silicon Valley investor reignited a long-running debate over the existence of ghost engineers.
“Everyone thinks this is an exaggeration but there are so many software engineers … who I know personally who literally make ~2 code changes a month, few emails, few meetings, remote work, < 5 hours/ week, for ~$200-300k,” Deedy Das said in an X post one morning last month.
Das, who didn’t respond to an interview request, listed 13 companies where he said such behavior is common, from networking pioneer Cisco to cloud giant Salesforce. He detailed a few tips and tricks on how ghost engineers get things not done. They include heavy use of the “in a meeting” status in workplace chat apps and using low-cost gadgets called mouse jigglers to simulate constant activity.
…
Denisov-Blanch, who taught himself to code as a teen, said in a phone interview that he didn’t set out to hunt techie ghosts.
But the phenomenon became obvious, he said, after creating a machine-learning algorithm that digests a company’s collection of code to analyze programmer productivity, conceived in collaboration with Stanford associate professor of organizational psychology Michal Kosinski and entrepreneur Simon Obstbaum, former chief technology officer of anime streaming service Crunchyroll.
100% agree with this - it's dangerous to look at code changes alone for productivity. That said, I have worked with multiple "ghost engineers" in the past (because I knew their non-code contributions add up to zilch, too). I could have been frustrated that they weren't helping, but I ultimately decided that, since I wasn't a manager, it wasn't my problem.
Beyond just "not looking at code changes only", you have to consider what sort of work the developer is doing as well. Green field code will always have faster development than legacy code. Working in critical parts of the code will go much, much more slowly than working further from the core functionality. Working in code that is poorly (or not at all) unit tested will take much longer than something that has automated tests.
Metrics like the one the company in this article is trying to push with (what seem like to me) ass pulled statistics are just going to incentivise developers to take the most-bang-for-the-buck work themselves and push off (or fight over who has to do) the vital, but difficult stuff. And WaPo seems to to swallow it almost wholesale, with only minor criticism at the very bottom of the article.
Mildly related, but I'm reminded of this story of a naive attempt to measure productivity by code changes: -2000 Lines Of Code
Heck, for larger companies you can spend weeks in meetings and more meetings over your code review and trying to satisfy multiple parties for some particular feature. You wish they would have intervened earlier in the feature development, but part of code review is to properly bring out those stakeholders and make sure everyone's aligned.
It’s somewhat rarer than people make it out to be but it’s real. I find it’s most common on large teams with one line manager. Often the line manager is so overwhelmed (like, 40 hours of meetings a week + normal duties) that they have no idea what half of their team is actually doing.
Combine that with, say, infra work or something else that doesn’t move very fast, and it’s easy to make shit up at standup for a year.
I guess the solution is you should have more managers? I know the managerial class isn’t all that well liked, but for line managers I wouldn’t really consider it a good thing to not have enough as an IC. Middle management at the skip and above level is another story.
The "solution" I usually see is that they try to use "team leaders", which are senior engineers who are supposed to mentor and keep an eye on the rest of the team. The mentoring part is ok, but I think most senior engineers are not in management for a reason, and don't want to be responsible for any "ghosts" so they just do the work themselves.
I ended up as a technical team leader. In theory I was supposed to be coding, but largely I just attended meetings that didn't need to happen so that the more junior members of the team didn't have to attend. Even of the important meetings, me or my team were only "needed" about half the time.
This was fine when they let us work from home and I could do other things (many of which were not work related), but as soon as we went back to the office, it was just mind numbingly awful.
I have since found a remote job where they have a much flatter structure, so there's no worry of accidentally becoming a manager, and I'm actually engaged with my work instead of just tuning out. While I suspect they refilled my position at my previous company, the truth is that my role was largely just knowing things, and about 1 hour per week (split into 5 minute increments) of telling other people what I knew.
different tracks, different pay grades. I personally never want to pursue a lead/management track.
And even if I did, that's usually a higher paying position. I sure would not want an anti-promotion in this day and age if I can afford not to. It's just good work/life balance to put a foot down and say "no, I am not this team's lead, I'm busy enough as is with my existing work".
It goes the other way as well. Some aren’t managers because of their definitions or behaviors. I’ve worked under someone like that who straight up derailed me multiple times and then my ACTUAL manager would get upset
Yeah I've seen quite a few of these ghosts. Actually, I've more commonly seen "vampire engineers". These are people who actually subtract productivity from the rest of the team. Either they need too much guidance to get tasks done, or they create work that has to be rewritten by someone else. Sometimes these are identified by management but it is hard to fire people, even though we don't have unions in software development in the US. This is probably a main reason why my company usually uses contractor-to-hire - contractors can be fired without cause.
Anyway, yes this is a flaw in corporate culture. I've worked on teams that had great engineers and poor engineers. I don't think I've worked on one that had great managers. Seems like the purpose of managers would be to make sure that tasks are completed, and to know who actually contributed to this. For some reason this is usually very hard for them. They only seem to know the "superstar engineers" and the ones that are good at self promotion. The rest of the employees are often sort of invisible. If the managers would just do their jobs, they could identify productivity properly (and wouldn't have to rely on key-logging and internet monitoring and whatever other employee spying they do).
Years ago I was in a group that tried to fix this issue. They engaged with Gallop and got into First, Break All the Rules. We would take surveys which had intentionally weird questions that were designed to uncover ineffective managers. Well, the managers couldn't have this so they coached the employees on the survey which poisoned the result. And this farce was not detected by the upper management, or they didn't care.
Thanks, you've finally explained why so many of my colleagues are contractors but have been with the company for 5+ years. That always made me scratch my head (UK based company).
I also have a "vampire engineer" on my team who saves me about 5 hours a week in busy work (that I could honestly have automated if I had the time) but creates about 10 hours a week of work for me to fix his shit, re-explain something that he should know because I literally gave him the documentation three weeks ago, or asks so many questions that it's easier for me to just do it because it takes more time to explain than to just do it and he doesn't seem to learn anyway.
Management is well aware and have given him chance after chance but since he's not a contractor, very difficult to fire. I do try to have some empathy since he's young (Gen Z young), English isn't his first language, and I was once fired for asking too many questions at a job where I had zero knowledge of the products, but I at least made improvements and learned. Haven't seen much of either from him.
that's fortunately no longer legal in many key US states. Thanks Microsoft.
Of course they just loophole around it with something like an 18 month contract + a break before making another 18 month contract. But the spirit of the law is still good.
Hard to fire people? It's a nuisance. You have to thoroughly document their failings, a plan to correct them, and how the person failed to live up to the plan.
Happens plenty often—often enough that I quit Big Tech and management. There are misanthropes, sure, who are gaming the system. But there are also at least as many or more people who are trying their level best and were either a poor hire (interview processes are generally garbage), weren't able to/supported adequately as the needs of the job changed around them, or were simply obviated by the business no longer needing them in that role.
Businesses most often choose expediency. Most see it as easier to fire a person and hire a person who is a better fit. Performance Improvement Plans rarely end in continued employment (though I worked hard to set up mine for success and saw about a 50% pass rate).
Sure, I had at least one engineer who was almost certainly working a side gig. They attended just enough meetings, and were impactful enough in those meetings, that adjacent teams were pleased. However, I and my own team members could see how the person was otherwise absent for their own team, leaving coworkers in the lurch when it was their job to support them as a Staff (a senior) engineer.
You have to either be a cold-hearted bastard or have amazingly high emotional intelligence and mental health to survive in management. The logistical and process work is fine: that's about making things better at scale. Coaching people with compassion in their growth and seeing them win is great. Coaching on failures, when the person is unable or unwilling, is hell.
EDIT: Toeing the line, when your management expects you to behave in ways that are unethical: that's when I give them the finger and quit. I suppose many other managers just cave and do the unethical thing.
It's a hard mix. Because the great managers have a background with people, business, and the technical work all at once. These days many companies simply skimp on the 3rd, costing product quality and/or future pipeline issues. Those that can only see the loud and obvious contributors are definitely those who skimp on the 3rd, since they cannot properly understand and recognize how a typical engineer works day-to-day.
Probably didn't care, sadly. Like anyone else, there is a bit of efficiency sacrificed for self-preservation. People are rarely paid to be "great X". People are even more rarely paid enough to be that anyway.
From the article:
…
Mirror: https://archive.is/ktmWZ