The Hidden Costs of Shadow Work in Engineering Teams

Engineering Management

Explore how invisible production support, technical glue work, and shadow backlogs quietly drain engineering team capacity. Learn strategies to uncover and manage these hidden efforts, boosting productivity and team morale.

The Hidden Costs of Shadow Work in Engineering Teams

Anton Zaides | November 18, 2025

I once had a senior engineer aspiring for a staff promotion. He requested time to lead a cross-team technical initiative. Three months later, progress was minimal, and I grew frustrated; he barely had any tickets in the sprint and wasn't delivering.

I knew he was also supporting other projects, but I assumed he could manage both. When we delved into it together, we uncovered the reality:

  • He was the primary code reviewer for three different projects.
  • He mentored engineers new to those areas, joining every discussion.
  • As the most tenured engineer, he was constantly fixing issues that the support team directly escalated to him.

More than 40% of his time was dedicated to invisible work, a gap that exists in every team.

Today, I'll explore three types of 'shadow work' that silently consume your team's capacity:

  • Invisible Production Support
  • Technical Glue Work
  • Shadow Backlog

When I asked my engineers to keep our clunky issue reporting app updated, the typical response was a groan. They disliked using it, so they avoided it. Work migrated to Slack, ad-hoc conversations, and anywhere but the official tracker. Consequently, I was making decisions based on incomplete information.

For years, I believed this was simply the reality – constantly nagging engineers until they formed the habit. It turns out, that's not necessary. Teams that switch to Linear report twice as many issues – not because there are more problems, but because engineers genuinely enjoy using the tool. When tracking work feels fast and simple, the invisible becomes visible.

What I appreciate about Linear is its ability to run alongside your current tracker with two-way sync. This means you don't need extensive permissions or a major migration to get started. It offers happy engineers with zero headache.

Read about switching to Linear

Thanks, Linear, for supporting today’s article!

P.S. Long-time readers know I've wanted Linear as a sponsor for a while. Thanks for reading and making this possible!

Invisible Production Support

There are two categories of production support: the kind that appears in tickets and everything else. Official requests follow proper channels, are triaged by support, and move into your PM's backlog.

These often represent the minority of support efforts.

Much of the work required to support production stems from:

  • Investigating alerts and errors
  • Questions from engineers on other teams
  • Ad-hoc requests from support engineers

None of this typically gets tracked.

Here’s an example of this reality:

In my previous team, we had a 'team rep' rotation (also known as a hotfixer). Each day, a different engineer handled incoming tickets, answered support questions, and monitored alerts. Only about 20% of their work made it into formal tickets. Nobody bothered documenting the ad-hoc tasks – including me when it was my turn.

What this costs you:

  1. Running in Place When nothing is documented, you cannot discern patterns. Consider an annoying issue that takes 15 minutes to fix manually. The hotfixer simply wants to resolve it and move on, without investigating the root cause. The team becomes accustomed to it. Someone might even create a script for support to run: "Oh, that payment thing? Just run the fix." Over weeks and months, your team collectively burns over 10 hours on the same issue, whereas the actual root cause could have been fixed with 5-6 hours of dedicated effort.

  2. Sacrificing Stability In a normal ticket flow, someone takes time to consider edge cases – either the engineer or a QA person testing the change. Ad-hoc fixes bypass this crucial step. I've witnessed severe production incidents caused by engineers attempting to solve a problem quickly – tweaking production data directly or pushing an untested hotfix that inadvertently broke something else.

Glue Engineering Work

Glue work is a broad concept:

"The work that holds teams together - planning, coordinating, mentoring, reviewing, documenting - all the essential stuff that isn’t coding but makes coding possible."

In my experience, the most underappreciated glue work is high-quality code reviews, which have become even more critical given the prevalence of AI-generated code.

Code reviews are effective when executed well, but the burden disproportionately falls on your most senior engineers, and this effort is rarely acknowledged.

What this costs you:

  1. Frustrated and Burned-Out Engineers Glue work is critical but often unrewarding. I don't know any engineer who gets excited about reviewing code or writing documentation. The trap is that the more senior they become, the more time they spend on these activities, leaving progressively less time for enjoyable, impactful work. Furthermore, this invisible work rarely contributes to promotion opportunities. A senior engineer cannot reach staff level if they're spending all day on code reviews.

  2. Strategic Bottlenecks If your senior engineers are dedicating 40% of their time to code reviews, they lack the capacity for strategic initiatives. You might assume they are available to lead that crucial cross-team project, but they are not.

The Fix:

Your senior engineers can teach these vital skills! Host live code review sessions where they demonstrate how to gather context and dive into critical issues. Pair junior engineers with seniors to mentor them through the review process.

When you distribute glue work across the team instead of allowing it to accumulate on your most experienced individuals, everyone improves, and your senior engineers reclaim valuable time.

Shadow Backlog

You have your 'official' roadmap, which everyone in the organization is supposed to be aligned with. Beneath this, you have your shadow backlog.

This operates in two ways:

  • PMs requesting small fixes in areas not part of the roadmap – off-the-record requests that bypass the official process.
  • Engineers spending time to "do things right," opting for a more thorough route even though they know if they asked the PM, they'd be told to take a shortcut.

What this costs you:

  1. Broken Capacity Planning You believe your team has full capacity for the roadmap. In reality, they might only have about 60% because the remaining capacity is consumed by the shadow backlog.

  2. The 80/20 Game Eventually, Engineering Managers start instructing engineers to "spend 80% of your time on official work, save 20% for everything else." You've just institutionalized the shadow backlog. This ratio can continue to creep up over time.

  3. Trust Breakdown Maintain this practice long enough, and the alignment between business and engineering completely disintegrates. The business perceives engineering as slow, while engineering believes the business doesn't understand what truly needs to be done.

In my opinion, the shadow backlog isn't inherently the problem; that's probably the work that should have been done in the first place. The solution is to stop doing it covertly and ensure you allocate proper space for it. The more people disagree with your roadmap because it was imposed on them, the larger your shadow backlog will become.

A Note on Remote Teams

When you cannot physically observe someone working, shadow work becomes entirely invisible. In an office setting, you might see engineers quickly hopping on a call to assist someone or whiteboarding through a problem. Now, all of that occurs in Slack DMs and impromptu Zoom calls.

The larger issue is that it's not only invisible to you (the Engineering Manager) but also to your manager.

You might be aware that an engineer is doing excellent work: jumping on calls, responding to Slack messages, conducting thorough code reviews, and fixing ad-hoc issues. However, your manager sees none of it.

Then, when it's time to advocate for their raise or promotion, you have no tangible evidence to present. Your manager asks, "What did they actually deliver?" and you're left struggling to explain work that doesn't exist anywhere in writing.

Final Words

The solution isn't to meticulously document everything – that's exhausting and unlikely to happen anyway.

Still, the first step is making work tracking effortless. When your engineers don't despise the tool (refer to switching to Linear above), more work becomes visible by default.

However, merely identifying the problem doesn't solve it. If your senior engineer is overwhelmed with code reviews, teach someone else how to perform them. If support consistently pings the same person, rotate the responsibility. If your team has a shadow backlog, integrate it into your official planning.

Discover Weekly