Manager.dev

Engineering teams lose significant capacity to undocumented work that never appears in sprint planning. Three major categories drain productivity: invisible production support (ad-hoc fixes, alert investigations, support questions), technical glue work (code reviews, mentoring, documentation), and shadow backlogs (off-roadmap requests and technical debt work). This hidden work causes burnout in senior engineers, breaks capacity planning, creates strategic bottlenecks, and erodes trust between business and engineering. Solutions include making work tracking painless, distributing glue work across the team through mentorship, and formally incorporating shadow backlog items into planning rather than treating them as unofficial work.

Shadow work in engineering teams

We’re trying to fix this.
Devs, at least we should document everything we do in case a project manager or higher-up asks “Why are your tickets not all completed this sprint? What were you doing all this time?”
At one point I started forwarding all the emails and internal chat messages to my supervisors. That’s how they were finally convinced things had to change and how much I was doing to the company.

Waiting for tests to pass multiple times a day can be huge time-waster.
You cannot simply move to work on a another branch/thing for 10-30 minutes while tests are going-on. That is a huge context-switch for such a short time and if tests fail then more work needs to be done on current branch.

This is a great topic that most of the time is not talked enough in companies. Great article!!!

I understand that this article is mostly written from a project management perspective, but I’m not so sure some of this reasoning makes sense to be honest. As a developer, if I’m spending 10+ hours a week (even split among a team is 2ish hours a day) to say that I wouldn’t be able to be like “damn, I can’t believe I’m spending 2 hours every week on my rotation dealing with this issue, maybe we should just fix it” because it’s not tracked in a ticket seems silly. I think it’s less about the work/planning/documentation, and more about the communication within a team that matters. With a good communicative team, it’ll become pretty clear pretty quickly when something needs to transition away from shadow work into tracked work.
Also I think that to a certain extent it’s about communicating processes to the client. If you’re stuck needing a full dev every day devoting their day to a whole days worth of ad-hoc hot fixes then you should be telling the client that they should be submitting tickets reporting bugs through a channel that will result in these issues being tracked so that you can monitor them to see what’s creating the problematic code, because if I were a betting man it’s probably these ad-hoc hot fixes that are creating more issues, pushing “fixes” live that break other areas without proper testing to satisfy the clients immediate needs. Be firm with the client, and communicate with them that processes exist for a reason so that you can stop the cycle.