The shift to remote work

Over the last decade, remote workers in the US tech sector have increased dramatically.  The COVID-19 pandemic caused a massive shift to remote work, with both the number and percentage of remote workers more than tripling. And while the percentage has plateaued and even slightly decreased in some sectors, it remains significantly higher than pre-pandemic levels. 

A 2024 study by the U.S. Bureau of Labor Statistics found that industries with a higher increase in remote work also experienced substantial increases in output, suggesting a positive correlation between remote work and productivity. 

But for all its advantages, some employees have taken this as an opportunity to play the system. Take, for example, “over-employment,” the practice wherein employees secretly take on two or more remote jobs simultaneously. In most cases, double-dipping developers struggle to dedicate sufficient time and effort to either role, which often shows up in the form of unavailability, inconsistency, and notable underperformance. 

Companies that thrive in this era are learning to address these hidden underperformance challenges, creating systems that balance autonomy with collaboration, ensuring every voice remains active and engaged.

Ambiguous expectations 

Many organizations recognize the importance of structured career progression frameworks for software engineers. Also known as career ladders, these frameworks describe clear advancement paths through multiple levels of seniority. However, they rarely include quantifiable contribution metrics that can be used to benchmark employees. Why is that? 

In the development world, there’s a pervasive belief that counting one’s contributions is taboo. The working assumption is that software engineers are incredibly smart and talented, will naturally know what’s expected of them, and will deliver great work. The uproar following McKinsey’s article on measuring software engineering productivity highlighted just how deeply this resistance runs. 

However, for some employees, the lack of clear expectations creates an environment where ambiguity can be exploited, making it easier to coast by with hidden underperformance or contribute only the bare minimum.

Organizational sluggishness 

As organizations grow in size and complexity, their processes must evolve to support new and maturing objectives. To combat the infamous sluggishness of large companies, more people are hired to coordinate, manage dependencies, and monitor progress of key initiatives. In fact, Faros AI’s data shows that up to 25% of software engineering employees are “bureaucrats”—roles that focus on process, not coding.

While having the right systems in place is critical, overcomplicating procedures can backfire. The abundance of meetings, new reporting requirements, and multi-step approval processes negatively impact overall productivity. When excessive bureaucracy stifles creativity and agility, morale also suffers. 

At this tipping point, some engineers may decide it's not worth their while to invest effort in areas they see as beyond their control. Instead, they disengage and become ghost engineers, choosing to stay in the background and contribute just enough to avoid drawing attention.

Step 1: Set clear expectations

With employee engagement sinking to a 10-year low, the importance of clear expectations cannot be overstated. When developers lack clarity around their roles, responsibilities, and project goals, confusion and frustration take root, creating the perfect storm for disengagement and burnout. Clear expectations and well-defined contribution baselines can eliminate ambiguity and give developers the direction to focus and thrive. 

Managers should clearly define expectations and role-specific productivity baselines, set SMART goals, and align individual contributions with team objectives to lay a foundation for developers to perform at their best. If you are concerned with hidden underperformance, this would be a good time to revisit your career ladders to ensure they accurately reflect your expectations. Then, make sure to communicate them clearly to your teams.

Setting clear expectations is just the start. To meet them, developers need the right tools, manageable workloads, and a culture that values their growth and contributions. When employees feel supported and recognized, they’re motivated to go beyond the minimum. 

Combine transparency with a clear connection to the company’s broader mission, and you create an environment where developers are engaged and empowered to deliver exceptional results, lowering the likelihood of hidden underperformance.

Step 2: Identify patterns of underperformance in data

To uncover patterns of underperformance, analyze an engineer’s visible activity across systems like GitHub, Jira, and their calendar over time. For instance, an engineer may have minimal code contributions or reviews in GitHub, while also showing low activity in task management systems like Jira or Asana—fewer tasks created, completed, or moved through workflows. Additionally, if calendar data shows they aren’t typically engaged in interviews, meetings, or collaborative sessions, this could signal potential hidden underperformance. 

Next, compare this data against team norms and peers in similar roles with similar expectations. Are others at the same seniority level or with similar workloads delivering more consistent results? Is this individual’s contributions near the average or far below? 

If workflows or dependencies are slowing multiple team members, the issue is likely not individual. However, repeated and sustained gaps across tasks, contributions, and collaboration—especially when team processes seem otherwise functional—are strong indicators of a deeper issue.

It’s critical to remember that different roles within a software engineering team will naturally have varied expectations and responsibilities, affecting how their data appears across tools and systems. That’s why clearly defining those expectations is so critical. 

For example, senior engineers or team leads may have less hands-on coding time, but should be contributing more through mentoring, design reviews, or cross-team collaboration, which would be evident in higher levels of code review activity or meeting facilitation. Junior developers, on the other hand, may be expected to focus more on individual coding tasks and have more direct output in GitHub or task management tools like Jira. 

For roles that span multiple responsibilities, such as full-stack developers or those involved in both coding and DevOps, you’ll want to evaluate a combination of activity across tasks, code contributions, and even collaboration efforts to get a clearer picture.

Step 3: Contextualize with qualitative insights

Holding regular 1:1s with individual team members, in conjunction with reviewing survey responses, is invaluable for uncovering additional context behind the numbers. These conversations and responses can reveal whether a lack of productivity stems from unclear expectations, personal challenges, or team-wide blockers. They also provide an opportunity for employees to share their perspectives on their workload, contributions, and any support they may need to improve their productivity.

Furthermore, team retrospectives complement these insights by surfacing feedback from colleagues who may have more direct visibility into an individual’s work. This is especially important for recognizing contributions that aren’t easily quantifiable, such as mentoring, resolving team-wide technical issues, or supporting cross-functional collaboration. 

By triangulating patterns from quantitative data with qualitative input from multiple angles, managers can assess performance holistically and identify the root causes of challenges.