A possibly perplexing study coming out of Stanford University conducted by software engineering productivity specialist Yegor Denisov-Blanch claims that developer teams are rife with so-called ghost engineers who do virtually no work. Ranked for performance at less than one-tenth the productivity of a median software engineer, a definition of ghost engineering is emerging that details an employee who may have multiple jobs, and a finger in several presumably less-than-productive pies.

Denisov-Blanch’s claims echo commentary in this arena made by Marsofile X-man Elon Musk, a man well known for calling out what he perceives to be shirkers or deadweight employees.

“We have data on the performance of >50k engineers from 100s of companies,” posted Denisov-Blanch, following up with a comment that claimed, “~9.5% of software engineers do virtually nothing [and are] ghost engineers.” 

Basing his statements on what he says is an analysis of technology companies who have allowed him access to their internal code repositories, the team has been running an algorithm against individual developers’ code activity to glean their results. This is done not by counting the actual number of commits, the analysis looks at the content of each commit and quantifies it based on its impact on the codebase.

The assertion here is that almost 10% of software application developers (whether working remotely on in-cubicle on company premises) do effectively nothing all day, or indeed all week. For wider clarification, the remote worker segment has more outlier positive performers, but in-office workers exhibit a higher average performance overall.

The Laws Of Economics

The claims here may not be so outrageous if we look at the laws of economics. The time-honored Pareto distribution states that 80% of outcomes come about as a result of 20% of causes. Equally, Price’s Law states that the square root of the total members accounts for half the output, so that in a group of 100 developers (in this story), as few as 10% of the coders would contribute 50% of the work.

There are bias factors to be aware of too, of course, i.e. this study was conducted on code repositories (such as GitHub) belonging to companies who had opened up to the Stanford team’s offer of analysis – perhaps suggesting that these teams had concerns about unidentified productivity gaps. Equally, the algorithm may have missed non-code project contributions (such as localization materials, documentation or other artifacts) that are less digitally trackable, although Denisov-Blanch has said that this element has been balanced in the algorithm’s weight and function.

The team also confirmed with many research participants that the workers identified as ghosts in their organizations are indeed ghosts. They did this by confirming with teams from the participating organizations that each person should have been contributing code, and wasn’t doing other activities (mentoring, sales, etc.) that would prevent that person from coding.

Why do Ghosts Exist?

So why does Denisov-Blanch think this ghostly reality has come about? Is it a result of automation and the looming specter of AI taking over more coder functions in any way? Is it a result of open source “systems of meritocracy” that champion all comers and encourage contributions at all levels so that even seemingly insignificant contributions to a project are well-recognized?

“If someone uses AI effectively and can now do in two hours what takes someone else eight hours, then that’s fantastic and I think they should continue doing that, assuming there’s no other issues that are surfacing from the increase in speed. Our model doesn’t track how long a developer spends on a commit but rather quantifies the code inside the commit. A balance of both speed and quality is encouraged. If a programmer goes too fast, quality drops… so naturally, they have to go back and fix things, which slows processes down,” said Denisov-Blanch, speaking to Techstrong Group directly this December.

He reminds us that throughout this century, software engineers have been in extremely high demand and have enjoyed high employment optionality. He hypothesizes that, in the past, organizations were afraid of losing their engineers to competitors if they introduced transparency and accountability. Because of this, they might have assumed that a certain percentage of engineers at any given time might have suddenly silently quit or were low performers… and that this was a normal cost of doing business. In basic terms, everyone knew this, but nobody could quantify it, or do much about it.

Are Project Managers to Blame?

“Blaming project leaders oversimplifies this complex problem. The challenges stem from interactions at multiple levels within an organization,” asserted Denisov-Blanch. “Many ghost engineers I’ve talked to share a common story, i.e. they become disengaged due to frustration or loss of motivation in their roles. Over time, they may test the limits of how much effort they can reduce without consequence. This gradual disengagement often results in them turning into ghosts; originally not out of malice, but as a by-product of their work environment.”

He says that managers want to build high-performing teams but face conflicting incentives. A poorly performing team reflects badly on its leadership, leading some to downplay problems rather than address them head-on. Additionally, organizational politics may discourage reducing team sizes, even when smaller, more focused teams could be more effective. Further here, time constraints and competing priorities often leave managers with little capacity to actively support and guide their teams.

“There’s also the fact that senior leaders are often further removed from day-to-day operations. Their decisions are based on trust in middle management or flawed metrics, such as lines of code or commit counts. They, too, are sometimes not incentivized to reduce team sizes or deeply investigate performance issues, as their focus tends to be on higher-level strategic outcomes,” said Denisov-Blanch. “The interplay of these factors creates a system where disengagement among engineers can thrive, not as an intentional choice but as a consequence of deeper issues within the organization.”

He and his team members remain convinced that with greater transparency and data-driven decision-making, we can create a better experience for developers, reducing frustration, while equipping managers with the right tools to support their teams effectively. At the same time, senior leaders can gain the clarity they need to set strategies that drive meaningful outcomes.

“With our research, we’re hoping to create a solution that can be used to measure the output of software engineering teams, taking a step towards data-driven decision-making and transparency in software engineering organizations. This solution should not be used without context, works best when combined with other metrics, and is most useful when measuring teams rather than individuals,” concluded Denisov-Blanch.

The Analyst/Industry Take

“It’s a curious study. Of course, ‘swinging the lead’ is as old as the history of work… and there may be examples of developers who are sleeping on the job. Equally, lines of code or pull requests are very poor metrics of developer productivity. So much of development has nothing to do with touching the code – and in fact, a well-defined solution created collaboratively with the business users may be much more focused, simpler and smaller than a generalized answer to a broad potential need. Back when I was doing UML consultancy, a frequent challenge was dealing with requirements sprawl  – ‘solve all the things’ – and it may be that smart developers are spending time working out what doesn’t need to be done… coding-wise, I mean,” advised Jon Collins, VP of research at GigaOm, a software-specialist analyst house with extensive experience in enterprise technologies.

Collins reminds us that software engineering analytics tools such as LinearB are smarter. They look at basic metrics, DORA, etc, but equally, when changes are made and how much value they add.

“Speaking of value, value stream management (VSM) practices focus on delivering the right things, as well as delivering things right,” said Collins. “Ultimately there’s always mileage in motivating teams to deliver well, which doesn’t necessarily mean more of the old ‘forget the quality, feel the width’ routine. Factors like ownership, end-user engagement, team building, etc. go a long way to helping teams work better. So for sure, if developers are underperforming, this needs to be addressed but not just by cracking the whip harder.”

VP of engineering at internet performance monitoring company Catchpoint Sergey Katsev says he agrees with the findings here. Primarily because software engineering is very tightly coupled with motivation and without motivation, any team is bound to lose accountability and ownership.

“Naturally, as teams get larger, some people can ‘fall through the cracks’ as far as performance is concerned,” said Ketsev. “We really are at an inflection point for software engineering. It used to be a safe bet that anyone with an interest in development could get a job.  Now, with the advancements of AI and an overall economic climate of doing more with less, a developer has to be good to succeed. But overall, it’s really hard to measure developer productivity. Lines of code are merely a signal and so are DORA metrics. One framework that’s been helpful for us is the SPACE framework – which defines all of these metrics as indicators and signals rather than a full explanation of productivity.”

In the end, says Katsev, a developer’s or a team’s performance hinges on them being engaged, which comes from mission and culture (assuming fair compensation).

“Making sure that they’re engaged can only come from periodic conversations within the team – and everyone keeping each other accountable. The indicators from SPACE or other frameworks serve as a place to look for trends or a direction to take 1-1 conversations, but managers need to ensure that these conversations are happening.  As this study here suggests, middle managers or executives no longer know the performance of an individual contributor – they need to know the productivity of the team or project as a whole and establish a culture where the team keeps each other engaged,” he added.

Productivity Reality Distortion?

The upshot of this whole discussion may be that software engineering needs more data-driven decision-making and transparency, i.e. the problem is that existing metrics used to measure software engineering “productivity”’ may distort reality. Those existing metrics might include:

• Lines of code and counting commits aren’t good metrics because they don’t look at the size of the payload.
  
• Story points are subjective and not comparable across teams.
  
• Self-assessment surveys are great to measure developer experience, but not great to measure developer productivity.
  
• DORA is a measure of DevOps performance and shouldn’t be used to measure productivity because deployment sizes aren’t constant within & across teams. In addition, the flow metrics are easily gamified.
  

All of this leaves engineering leaders with a choice of two options: Make decisions with data that distorts reality, or make decisions without data, relying on intuition. Both options could well lead to poor decision quality. If the rise of ghost software engineers is true and the potential for systems of disengagement real, then, really, who you gonna call?