The Backpressure Problem
You have four things in flight. Someone asks if you can pick up a fifth, and you look at it and think it's small. Two days, maybe three. You say yes.
Nothing goes wrong that week. Nothing goes wrong the next week either. Three weeks later, a date slips, and the first time your manager hears you were overloaded is the same conversation where they hear the work is late.
I have watched this play out on enough teams to know the shape of it. The engineer knew. The manager didn't. And the gap between those two facts is where the damage happened, well before anything was actually late.
You Set the Pace
Backpressure is how one part of a system tells another to slow down.
You rely on it constantly without thinking about it. When you download a large file, the machine receiving it is continuously telling the sender how much more it can take, and the sender adjusts to match. That’s built into TCP. It’s the reason a fast server doesn’t flatten a slow laptop.
Two details in that arrangement matter.
- The receiving side speaks first. Nothing polls it, and nothing asks how it’s holding up. The part that knows its own capacity is the part responsible for saying so.
- Remaining bandwidth is always included. Something closer to “I can take four more” than “I’m overwhelmed.”
Systems built without this don’t degrade gracefully. They accept whatever arrives, the backlog grows quietly, and they look healthy right up until they fall over. Nothing in the design makes a full queue announce itself.
Every yes was reasonable on its own
Nobody decides to become overloaded. The queue fills one defensible request at a time, and each one really is small when you look at it alone.
Saying you're at capacity also feels like a confession. It sounds like admitting you're slower than the person who would have said yes. That pressure lands hardest on people who built their reputation on being the one who absorbs things, which is exactly the wrong population for a silent failure mode.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
The cost is not linear
Queue time doesn't climb in a straight line as you fill up. It bends. Queueing theory puts rough numbers on how sharply:
| How busy you are |
How long work waits |
| 50% |
|
1x |
| 80% |
|
4x |
| 90% |
|
9x |
| 95% |
|
19x |
Going from 80% loaded to 95% is fifteen points of capacity and nearly five times the wait. This is why the extra task never costs what it looked like it would cost. You didn't add 20% more work. You crossed into the part of the curve where everything sits longer.
Your week isn't a server, and I'd hold the exact numbers loosely. The shape is the part you've already felt. It's also before you account for the restart cost of moving between things, which these numbers don't capture at all.
So count what's genuinely open on your plate right now. That number predicts how late the next thing will be better than how hard you plan to work on it.
Signal without data is noise
Here is the difference between complaining and applying backpressure.
Complaining: “I’m slammed right now.”
Backpressure: “I’m holding the billing migration, the two auth bugs, and the reporting spike. I can take this, and if I do, the migration moves out about a week. Which of those do you want to slip?”
The second version is the signal. It states capacity, prices the addition, and hands the prioritization decision to the person whose job is prioritization. Declining is one possible outcome of that conversation, and in my experience it’s rarely the one that happens. Usually something gets resequenced, or someone else picks up a piece, or the new work turns out to be less urgent than it sounded.
Gallup’s burnout research, which surveyed roughly 7,500 full-time employees, put unmanageable workload among the five factors most strongly correlated with burnout. Their own framing of what people need is worth sitting with: when workload is out of control, employees look to their managers to advocate for what they can and can’t accomplish and to find others to help. The resolution lives upstream. It only gets there if someone sends it there.
The same research found that burned-out employees are half as likely to discuss how to approach performance goals with their manager. Overload and silence travel together. The person who most needs to propagate a signal is the least likely to be talking to the one who could act on it.
Signals need proper timing
Backpressure applied after the date slips is a status update. It might be an honest one, and communicating a delay well still matters, but by then the only decisions left are damage control.
The window that counts is the moment you take the work, or the first week you notice the queue getting deeper. That’s when your manager can still move a date, pull someone in, or decide the thing genuinely isn’t worth doing. Every week you hold the information, you remove options from the person who has them.
Most of what I’ve written before about taking control of your workload was about making tradeoffs visible once you’re already in the middle of them. This is the upstream version. Same tradeoffs, sent earlier, to the person who can act on them.
Your manager is planning with a model of your capacity. That model updates only when you send it something. Silence doesn’t read as strain, and it doesn’t read as competence either. It reads as room.