The claim that 10% of software engineers (SWEs) in big tech are “ghost engineers” who pretend to work has sparked controversy and debate. A “ghost engineer” typically refers to an employee who appears to be working but contributes little or nothing meaningful. This accusation often fuels stereotypes of lazy tech workers and raises questions about the real productivity of engineers at major tech companies.
Critics argue that some SWEs do minimal work—sometimes limited to one-line code changes—and question whether such actions constitute real engineering effort. However, this view oversimplifies the role of software engineers. Engineering productivity cannot be measured solely by lines of code or visible code contributions. SWEs engage in many vital but less tangible tasks such as design, planning, debugging, code reviews, and collaboration, which are crucial to successful product development but don’t always reflect in straightforward metrics.
The research paper fueling this debate attempts to quantify software engineer productivity by analyzing code output, but it faces criticism for being overly simplistic and potentially anti-worker. It risks unfairly targeting engineers and ignoring the complexities of software work. Such studies can unintentionally promote distrust and erode morale in tech teams.
The underlying issue may also stem from broader workplace dynamics, including management practices and performance evaluation systems. For example, MBAs or management layers sometimes face blame for promoting inefficient structures that demotivate engineers, though stopping them outright isn’t a straightforward solution.
Ultimately, labeling engineers as lazy or “ghosts” undermines the nuanced reality of software development. Measuring engineer productivity requires a holistic approach beyond raw code metrics, recognizing the collaborative, creative, and problem-solving aspects of the role. Instead of focusing on blame, organizations should strive to better understand and support their engineering teams.
There’s something deeply human in our urge to measure things—to reduce complexity into neat categories or numbers we can point to and say, “See? This is what productivity looks like.” But software engineering, like so much of today’s knowledge work, resists that kind of simplification. The tension aRead more
There’s something deeply human in our urge to measure things—to reduce complexity into neat categories or numbers we can point to and say, “See? This is what productivity looks like.” But software engineering, like so much of today’s knowledge work, resists that kind of simplification. The tension at the heart of this “ghost engineer” debate seems to be less about whether someone pushes enough code and more about our discomfort with ambiguity in how value is created and recognized. When contributions are hard to see, especially in collaborative environments where impact is cumulative and often invisible, it becomes tempting to fall back on reductive judgments.
Part of what’s stirring beneath this controversy is a broader anxiety about fairness, especially in large organizations. People want to feel like their efforts are meaningful and that those who do less don’t end up with equal reward or recognition. But when the work itself defies easy tracking, we start projecting assumptions onto others—often shaped by incomplete visibility, distrust, or underlying economic pressures. It’s important, then, to step back and ask not just “Are some people doing less?” but “Why are we so eager to find fault?” Is it a failure of management systems that can’t identify meaningful impact? Or possibly a cultural failure to recognize how diverse and nonlinear real engineering effort often is?
Navigating this issue well means being willing to stay with the messiness. It asks organizations to develop more thoughtful ways of understanding value, grounded in context and human relationships, not just metrics. And it calls
See less