Shadow work in engineering teams
And the price your team pays for it
I had a senior engineer who wanted to get promoted to staff, so he asked for some time to lead a cross-team technical initiative. Three months later, it was barely moving, and I was getting frustrated - he barely had any tickets in the sprint, and he still wasn’t delivering.
I knew he was supporting some other projects, but I thought he could handle both. Then we dug into it together:
He was the main code reviewer for three different projects.
He mentored the engineers new to those areas, joining every discussion.
And as he was the most tenured engineer, he was constantly fixing issues the support team asked him about directly.
More than 40%(!) of his time was invisible work, and that gap exists on every team:
Today I’m going to cover three types of shadow work stealing your team’s capacity:
Invisible production support
Technical glue work
Shadow backlog
When I asked my engineers to keep our janky issue reporting app updated, the usual reaction was a groan. They hated using it, so they avoided it. Work happened in Slack, in ad-hoc conversations, anywhere but the tracker.
I was making decisions based on incomplete information.
For years, I thought this was just reality - keep nagging engineers until they build the habit. Turns out you don’t have to. Teams that switch to Linear see 2x more reported issues - not because there are more problems, but because engineers actually want to use the tool. When tracking work feels fast and simple, the invisible becomes visible.
And here’s what I like - you can actually run Linear alongside your current tracker with 2-way sync. It means you don’t need permission or a big migration to start. Happy engineers with zero headache:
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 types of production support: the kind that shows up in tickets, and everything else. Official requests go through proper channels, get triaged by support, and move to your PM’s backlog.
Those are often the minority.
Lots of the work to support production comes from:
Investigating alerts and errors
Questions from engineers from other teams
Ad-hoc requests from support engineers
None of it gets tracked.
Here’s an example of this reality:
In my previous team, we had a ‘team rep’ rotation (also called a hotfixer). Every day, a different engineer handled incoming tickets, answered support questions, and monitored alerts. Only about 20% of their work made it into tickets. Nobody bothered documenting the ad-hoc stuff - including me when it was my shift.
What this costs you:
1. Running in place
When nothing is documented, you can’t see patterns.
Let’s say there’s an annoying issue that takes 15 minutes to fix manually. The hotfixer just wants to solve it and move on - they don’t investigate the root cause.
The team gets used 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 burns 10+ hours on the same issue, while the real root cause could have been fixed with 5-6 hours of dedicated work.
2. Sacrificing stability
In the normal ticket flow, someone takes time to think through edge cases - either the engineer or a QA person testing the change.
Ad-hoc fixes skip this step. I’ve seen severe production incidents caused by engineers trying to solve a problem quickly - tweaking production data directly or pushing an untested hotfix that broke something else.
Glue engineering work
Glue work is a broad term:
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 become even more critical with all the AI slop around us. Code reviews are effective when done well, but the burden mostly falls on your most senior engineers, and it’s barely taken into account.
What this costs you:
1. Frustrated and burned-out engineers
Glue work is critical, but it’s not very rewarding. I don’t know a single 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 less and less time for enjoyable work.
And this invisible work is rarely promotion material. A senior engineer can’t get to staff level if they’re doing code reviews all day.
2. Strategic bottlenecks
If your senior engineers are spending 40% of their time reviewing code, they don’t have capacity for strategic initiatives. You think they’re available to lead that cross-team project. They’re not.
The fix:
Your senior engineers can teach these skills! Live code review sessions where they show how to gather context and dive into important issues. Pairing with junior engineers to mentor them through the review process.
When you distribute glue work across the team instead of letting it pile on your most experienced people, everyone gets better, and your seniors get their time back.
Shadow Backlog
You have your ‘official’ roadmap that everyone in the org is supposed to be aligned on. Underneath, you have your shadow backlog.
It goes both 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, going the longer route even though they know if they asked the PM, they’d be told to take the shortcut.
What this costs you:
1. Broken capacity planning
You think your team has full capacity for the roadmap. In reality they have maybe 60% because the rest is eaten by the shadow backlog.
2. The 80/20 game
Eventually, EMs start telling engineers “spend 80% of your time on official work, save 20% for everything else.” You’ve just institutionalized the shadow backlog. That ratio can keep creeping up over time.
3. Trust breakdown
Do this long enough, and the alignment between business and engineering completely breaks. The business thinks engineering is slow. Engineering thinks the business doesn’t understand what actually needs to be done.
The shadow backlog isn’t the problem - in my opinion, that’s probably the work that should have been done in the first place.
The solution is to stop doing it under the table and make sure you have space for it. The more people don’t agree with your roadmap because it was decided for them, the more shadow backlog you’ll have.
A note on remote teams
When you can’t physically see someone working, shadow work becomes completely invisible. In the office, you’d see engineers jumping on a quick call to help someone, or whiteboarding through a problem. Now all of that happens in Slack DMs and random Zoom calls.
The bigger problem is that it’s not just invisible to you (the EM) - it’s invisible to your manager too.
You might know an engineer is doing great work. They jump on calls, answer Slack messages, do thorough code reviews, fix ad-hoc issues. But your manager doesn’t see any of it.
Then, when it’s time to push for their raise or promotion, you have nothing to point to. Your manager asks “What did they actually deliver?” and you’re stuck trying to explain work that doesn’t exist anywhere in writing.
Final words
The solution isn’t to document everything - that’s exhausting and won’t happen anyway.
Still, the first step is making it painless to track work. When your engineers don’t hate the tool (see switching to Linear above), more work becomes visible by default.
But just seeing the problem doesn’t fix it. If your senior engineer is buried in code reviews, teach someone else how to do them. If support always pings the same person, rotate the responsibility. If your team has a shadow backlog, build it into your planning.
Discover weekly
Collaboration sucks by Charles Cook. On why engineers should work alone (very refreshing).
Understanding Enabling Constraints Using Shape Up by John Cutler.
The Root Cause Fallacy: Hidden Causes by Michał Poczwardowski. Closely related to the shadow work topic :)
Very much recognizable. But tbh, I don’t think Linear will help directly. It will help to visualize better and with less effort, but it only shows the issues that you described well. It’s the process that needs to change. IMO nobody should go directly to a single developer (though I’m that one most of the time…) It’s very easy to please, which will make it more easy for them next time, and less easy to say “not now” for you yourself. A well known pitfall….
Great insights on shadow work in engineering. The idea that much of this work happens behind the scenes and isn’t surfaced in tickets resonates with my experience. It would be helpful to see a short case study or metric example showing how lightweight tracking shifted priorities and freed up capacity. Do you have any practical tips for starting small without adding heavy processes?