In my telecom operations years in Saskatchewan, we ran a formal ticket queue. Every request for engineering time was supposed to go through it. It almost never did. If a regional manager wanted a report pulled or a config changed, he did not open a ticket. He walked over to the one network engineer he trusted, leaned on the desk, and said “quick favor.” The favor was never quick, and it was never on the board. By the time I inherited that team, roughly a third of its real workload existed nowhere in any system I could see.
Product managers live with the same problem under a different name. Your roadmap is the official queue. The shadow backlog is everything stakeholders route around you by messaging an engineer directly, dropping a request in a Slack thread you are not in, or catching a developer after standup with “hey, would this be hard?” None of it shows up in your planning. All of it shows up in your velocity.
The end-run is the default, not the exception
It helps to start from an uncomfortable premise: stakeholders going around you is normal behavior, not a breakdown. When someone has a problem and sees a faster path to a solution, they take it. The engineer is right there. You are in a meeting. The math is obvious to them.
The scale of the hidden load is easy to underestimate. When engineering operations get measured honestly, unplanned and reactive work routinely eats 20 to 30 percent of available capacity, and in reactive-heavy environments it runs far higher. One study of software development work found that 89 percent of work sessions were interrupted at least once. That is not a team with a discipline problem. That is the water most engineering teams swim in.
The reason it costs so much more than it looks is switching. Gloria Mark’s research at UC Irvine is the number every PM should have memorized: after an interruption, it takes an average of 23 minutes and 15 seconds to return to the original task, and people rarely go straight back; they detour through two other tasks first. Her later work found the average time on a single screen before switching had collapsed to about 47 seconds. Atlassian has put the global productivity cost of context switching at roughly $450 billion a year. A stakeholder’s “two-minute question” to your engineer is not a two-minute cost. It is a two-minute question plus a twenty-three-minute tax, paid out of the exact focus your sprint depends on.
What the shadow backlog actually breaks
The obvious damage is capacity: work happens that you never planned for, so committed work slips. But the quieter damage is worse.
You lose the ability to prioritize. Prioritization only works if the queue is complete. When a meaningful slice of engineering time is spent on requests you cannot see, your careful ranking of the visible work is a ranking of maybe two-thirds of reality. You optimize half the board and call it strategy.
You lose the estimate. When a developer quietly absorbs a side request, the feature they were supposed to finish takes longer, and nobody can say why. It looks like the estimate was bad. It looks like the engineer was slow. The real cause is invisible, so the wrong lesson gets learned.
And you lose trust in both directions without anyone intending to. The stakeholder thinks the thing is handled because an engineer said “sure.” You think the sprint is on track. Two weeks later the committed work is late and the side request was never finished either, because it was nobody’s real priority. Everyone feels let down by everyone. As one scrum practitioner put it, stakeholders bypassing the queue undermines the role and quietly decreases team efficiency, and it does it in a way that is hard to point at because no single request was unreasonable.
Why policing it makes it worse
The instinct is to lay down a rule: all requests come through me. I have watched that instinct fail more times than I can count, in operations and in product both.
The problem is that a rule does not change the incentive. The side door is still faster than the front door. When you announce that everything must route through you, you have not closed the side door; you have just made people feel slightly guilty about using it. They still use it, only now they do not tell you, because telling you means a lecture. You have converted a visible shadow backlog into an invisible one. That is a strictly worse position.
There is also a status problem. When you position yourself as the gatekeeper whose permission is required, you invite exactly the fight you cannot win: senior stakeholders do not enjoy asking a mid-level PM for permission, and they will route around your authority precisely because you made it about authority. The engineers get caught between the PM who says “send it to me” and the VP standing at their desk. They will pick the VP every time, and they are right to.
Gatekeeping treats the end-run as a discipline failure. It is not. It is a design failure. People are using the side door because you built a slow front door.
Make the front door faster than the side door
The only durable fix is to make the official path the path of least resistance. Stop competing on authority and start competing on speed. A few things that have actually worked, in ops and in product teams I have coached through this:
Build an intake that takes thirty seconds, not thirty minutes. If routing a request through you means a meeting, a template with nine required fields, and a two-week wait for the next planning cycle, of course people go around you. Give stakeholders a single, dead-simple channel: a form, a dedicated Slack channel, a “requests” tag on a board, whatever fits your tools. The bar is that submitting to you must feel faster than walking to an engineer’s desk. When I finally fixed my telecom queue, the change that mattered was not a stricter policy; it was a one-line intake that a manager could fill out from his phone in the hallway.
Protect the engineers by giving them one sentence. Your developers do not want to be enforcers, and they should not have to be. Hand them a response that is friendly and frictionless: “Happy to help, drop it in the requests channel and [PM] will get it slotted, usually same week for small stuff.” That sentence lets an engineer say yes to the person and no to the interrupt at the same time. It moves the request into your view without the engineer having to defend a boundary. Most people, redirected that gently, will comply, because they were never trying to break your process. They just wanted a fast answer.
Turn shadow work into visible work instead of forbidding it. You will never get to zero side requests, and you should not try. Some urgent things genuinely cannot wait for planning. So budget for them. Reserve a slice of every sprint, ten to twenty percent, for unplanned requests, and make that reservation explicit. Now when a request comes in, the answer is not “no, that is off-process.” It is “yes, that fits in this sprint’s flex capacity, or it competes with next sprint’s plan, your call.” You have made the tradeoff real and moved the decision back to where it belongs. Naming the interrupt budget also does something subtle: it tells stakeholders the interrupts are real work with a real cost, which most of them have never once considered.
Close the loop faster than they expect. The single biggest reason people go around a queue is that queues feel like black holes. Requests go in and nothing comes back. Beat that. When something lands in your intake, respond fast, even if the response is “got it, this is behind X and Y, realistically two weeks.” Speed of acknowledgment matters more than speed of delivery. A stakeholder who trusts that you will see their request and tell them the truth about timing has no reason to ambush an engineer. This is the same discipline behind a good stakeholder status update: visible beats fast, and predictable beats both.
The reframe that makes it stick
The shift that made the difference for me was giving up on the idea that the shadow backlog is a compliance problem to be stamped out. It is a signal. Every side request that reaches an engineer instead of you is telling you something: your intake is too slow, your priorities are not visible, or a real need is not being served by the roadmap. Read the pattern instead of punishing it.
If three different stakeholders are all going around you for the same kind of request, that is not three violations. That is a gap in your product or your process wearing a disguise. The end-run is expensive, and the switching tax is brutal, and none of that gets fixed by demanding people stop. It gets fixed by making the right path the obvious one, and by treating the people who route around you as customers who found a faster checkout line, not as rule-breakers who need to be corrected.
Your engineers already have a second boss. The question is whether you can see the orders being given, or whether you are the last to know.