Work That Pours In Rather Than Gets Planned — How to Handle Adhoc Work

Opening: Drinking From a Firehose
1. First, Accept Reality
2. Triage — Not Every Fire Is the Same Fire
3. Funnel Your Intake
4. Batch Processing and Protected Focus Time
- 4.1 Batching — Collect Interrupts and Handle Them Together
- 4.2 Nail Focus Time to the Calendar
5. The Trap of Urgency
6. Manage Expectations
7. Automate or Document the Recurring Work
8. How to Prevent Burnout
9. Beyond Personal Technique — Negotiating at the Org Level
10. A Case: A Platform Team That Turned the Hose Into a System
11. A Practical Checklist
12. Consciously Switching Between Two Modes
Closing
References

Opening: Drinking From a Firehose

Monday morning, you make a fine plan. "Today I'll finish the payment-module refactor." You brew a coffee and sit down.

9:12, Slack. "@you something you deployed yesterday seems to be blocking notifications." 9:34, a DM from another team. "Urgent -- can you pull this data for me?" 10:00, a meeting that materialized out of nowhere. 11:00, emergency debugging from a customer ticket. You skip lunch handling it all, and suddenly it's 5pm. You haven't touched a single line of the refactor.

A day like this once is an accident; every day, and it is your job. Many engineers -- especially those who also do operations, or platform/SRE/support-flavored work -- live in an environment where work that pours in (adhoc work) outweighs planned work. It is like trying to drink from a firehose.

This article is not about plugging the hose. The hose does not get plugged. It is about building a system that keeps you from drowning in the torrent while still getting the truly important work done.

1. First, Accept Reality

The most common mistake is thinking "things are supposed to go as planned; today I was just unlucky." If it has been like this every day for a month, that is not an exception but a pattern. The interrupts are not a bug; they are the spec.

Why does this acceptance matter? Because denying reality leads to wrong plans. In an environment where interrupts eat two to three hours a day, planning "eight hours of focused work today" means failing every day and blaming yourself every day.

[wrong mental model]
8 hours/day = entirely available for planned work

[reality-based mental model]
8 hours/day = 3h interrupt buffer + 4h planned work + 1h misc
-> plan planned work against 4 hours from the start

Accepting reality enables two things. First, you make achievable plans. Second, you start to see the interrupts themselves as "work to be managed" and design a system for them.

2. Triage — Not Every Fire Is the Same Fire

In an emergency room, patients are treated not in the order they arrive but in order of severity. That is triage. Incoming work must be sorted the same way. Handling things in arrival order is the worst strategy.

Keep a simple classification in your head.

[four-tier instant sort]

P0 stop now and handle   : service outage, money/security at stake, data loss risk
P1 within today          : customer blocked, deadline imminent, blocking someone else
P2 within this week      : important but with time to spare
P3 someday / never       : nice to have, not urgent

Sort fast with three key questions.

Is this blocking someone right now? (blocking)
Does the cost grow if I don't do it now? (time sensitivity)
Am I the only one who can do this? (delegability)

If the answer to all three is "no," that task can almost always wait. Yet we keep treating something like a P0 for the sole reason that it "just came in." Beware recency bias.

3. Funnel Your Intake

When interrupts come from every direction through every channel, even triage becomes impossible. By DM, by mention, in the hallway, with an "oh and one more thing" at the end of a meeting. So the first system is funneling intake into a single channel.

[scattered intake]               [funneled intake]
Slack DM ───┐                    all requests
mention ────┤                    -> #team-requests channel
hallway ────┼──> chaos    vs     or a single request form/ticket
email ──────┤                    -> triage in one place
meeting end ┘                    -> trackable

The implementation varies by environment.

Create a dedicated request channel or form and direct people: "post urgent things here."
Politely steer DM requests to the public channel. "If you post it here, the team can see it together and prioritize."
For verbal requests, ask: "Could you drop a line in Slack? Otherwise I might forget."

This buys you three things. Requests become a record, you can compare and triage in one place, and above all the sheer volume of requests becomes visible. Once you have data like "23 requests came in this week," you have a basis to argue for headcount or process change.

4. Batch Processing and Protected Focus Time

The real cost of an interrupt is not the task itself but context switching. It takes 15-20 minutes to enter deep focus, and a single five-minute interrupt wipes out those 20 minutes wholesale.

There are two countermeasures.

4.1 Batching — Collect Interrupts and Handle Them Together

Don't handle small requests the instant they arrive; collect them and handle them in batches at set times.

[bad pattern]                       [batch pattern]
req1 -> handle now -> recover (20m)  req1 ─┐
req2 -> handle now -> recover (20m)  req2 ─┼-> collect
req3 -> handle now -> recover (20m)  req3 ─┘
= 60 min of focus lost              handle in two passes at 11:00 and 15:00
                                    = minimal focus loss

Question the assumption that "instant replies are kindness." Most requests are fine if answered within an hour or two.

4.2 Nail Focus Time to the Calendar

Empty time gets filled with interrupts. So focus time must be explicitly reserved.

[day design example]

09:00-09:30  intake triage (sort requests piled up overnight/morning)
09:30-12:00  focus block (mark "focus" on calendar, notifications off)
12:00-13:00  lunch
13:00-13:30  interrupt batch 1
13:30-16:00  focus block 2
16:00-16:30  interrupt batch 2 + prep for tomorrow

Of course, when a P0 erupts the focus block breaks. That is fine. What matters is making focus the "default" and interrupts the exception. It must not be the other way around.

5. The Trap of Urgency

The most dangerous thing in a torrent of work is the illusion that everything is urgent. Requesters almost always say "it's urgent," because saying so gets it done faster. When everyone says urgent, the truly urgent gets buried.

"Urgency is contagious. One person says it's urgent,
so the next person says it's urgent too. Eventually everyone is urgent,
and nothing is actually urgent."

The way out of the trap is to not accept urgency as fact but to verify it.

"By when do you need it?" — Ask a vague "ASAP" for a concrete deadline. "By 6pm today" and "within this month" are worlds apart.
"What happens if you don't get this?" — Confirm whether there is a real impact.
"Should I stop the X I'm doing now to do this first?" — Show the trade-off to the requester.

That last question is especially powerful. Most people have no idea what you are working on. Tell them "to do your request I'd have to stop fixing a payment bug," and a good share will switch to "oh, then take your time."

6. Manage Expectations

The crux of handling a torrent of work is not working faster but managing expectations honestly. People get upset not because work is late but because they wait without knowing when it will be done.

[expectation-management response templates]

acknowledge + classify + timing:
"Got it. I'm handling a P0 outage right now, so I'll look at this this afternoon
and get back to you by tomorrow morning. Let me know if it's more urgent."

decline (gently) + alternative:
"This week is tough because of the X deadline.
I could start next Monday, or Y might be able to help sooner."

Two important principles here:

Don't go silent. Without even a "working on it," the other person feels ignored. Even when you can't do it now, give the "received it, will look by [time]" signal immediately.
Don't over-promise. Saying "I'll have it right away" and missing it erodes trust. Better to promise with margin and finish early (under-promise, over-deliver).

7. Automate or Document the Recurring Work

Look closely at incoming requests and a large share are the same kind of repetition. "Pull this data," "give me this permission," "how do I do this again?" Handling the same request by hand every time keeps you forever buried under the hose.

Here is the leverage of impact: stepping up from handling interrupts to reducing them.

[recurring-request response ladder]

step 1: handle by hand every time      (least efficient)
step 2: point to a self-service doc     ("see the guide here")
step 3: make it a self-service tool/script  (requester handles it directly)
step 4: remove the root cause           (so the request never arises)

For example, if "give me permission" arrives five times a week, a single self-service permission form turns those five into zero. Documentation works the same way. If you're answering the same question a third time, turn the answer into a doc and just send the link from then on.

A crucial habit here: document while you solve the problem. If you intend to write it up separately later, it never happens. In the very moment you handle the interrupt, spend five more minutes leaving a record for the next person (or future you).

8. How to Prevent Burnout

A torrent of work is not just a problem of inefficiency; it is also a problem of depletion. The sense of always having to be on, always reacting to someone's urgency, wears a person down. The psychologist Christina Maslach named, alongside overload, loss of control as a core driver of burnout. Interrupt-driven work is dangerous precisely because it strips that sense of control.

The remedy is to reclaim control bit by bit.

Create on/off boundaries. You don't have to be always on. Turn off notifications during lunch, focus blocks, and after hours. Real P0s arrive by another path (phone, on-call).
Rotate on-call. If one person carries all interrupt response, that person burns out. Rotate a "duty person of the day" so the rest can focus and the load is shared.
Record small wins. A day spent only on interrupts feels like "I got nothing done." But in fact you resolved 23 requests. Logging what you handled gives you both self-efficacy and evidence for reviews.
Ask for help with data. Once intake data (requests per week, time spent) accumulates, you can state "this structure isn't sustainable" with numbers, not emotion.

9. Beyond Personal Technique — Negotiating at the Org Level

Most of the methods so far are things an individual can do alone. But if the root cause of the torrent lies in the structure, individual heroics eventually hit a wall. At some point you have to negotiate -- upward, and sideways.

Here the most powerful weapon is the intake data you gathered in section 3, because it lets you speak in numbers, not emotion.

[a plea without data]
"I'm so busy. There are too many interrupts, I can't get work done."
-> sounds like a subjective complaint. Everyone's busy.

[a negotiation with data]
"Over the last 4 weeks, an average of 71 adhoc requests came in per week,
costing 14 hours per person weekly to handle. As a result, planned roadmap work
progressed only half each week. I propose three options."
-> sounds like an actionable proposal.

Options you can bring to the negotiation:

Add headcount/on-call: show the request volume exceeds what one person can absorb.
Invest in self-service: formally reserve time to build tools that eliminate recurring requests. "Two weeks invested now saves ten hours every week after."
Formalize expectations: agree an SLA for requests at the team level, like "P2 requests answered within 3 days."
Adjust priorities: put it explicitly on the table -- "to keep absorbing these interrupts, we must push roadmap item X."

The key is to redefine interrupt load as a team resource-allocation problem, not a personal tolerance problem. Only then do sustainable solutions emerge. Drinking faster alone is not a solution; it merely delays burnout.

10. A Case: A Platform Team That Turned the Hose Into a System

A three-person platform team at a company was besieged by every kind of request from internal developers. Deploy permissions, environment setup, troubleshooting -- dozens a day by DM. The team was always exhausted, and platform improvements never advanced an inch.

Over four weeks they changed the system.

Funnel intake: all requests went to one dedicated channel. The first week's data was a shock: 87 per week, 60% of them just three kinds of recurring request.
Introduce triage: classified by P0-P3 instead of arrival order.
Remove repetition: turned the three most common kinds into self-service docs and scripts. By week four, weekly requests dropped from 87 to 31.
Protect focus time: thanks to fewer interrupts, they could devote every morning to platform work.

Three months later the same team did more work with the same people, and overtime fell. They didn't plug the hose; they put a faucet and a cup in front of it.

11. A Practical Checklist

When you feel swept away by incoming work:

12. Consciously Switching Between Two Modes

Watch someone who handles the torrent well up close, and they are not trapped in a single mode. They consciously move between two.

[reactive mode vs creative mode]

reactive mode  : responding to interrupts. Quick judgment, light context.
                 Slack on, handling short tasks.

creative mode  : deep focus. The big context loaded in your head, building the essential.
                 Notifications off, immersed in one thing.

The problem is that these two modes don't mix well. Just as you're about to enter creative mode, one interrupt drags you back to reactive mode, and re-entering costs dearly. Conversely, clutching deep work during time that should be reactive leaves blocked colleagues waiting and frustrated.

The key is to not mix the modes but split them into blocks. Morning for creative, part of the afternoon for reactive -- assign modes to time slots. And stay aware of which mode you're in. A short question -- "am I in reactive or creative mode right now? Am I doing the work that fits this time?" -- changes the grain of the day.

Without this awareness, we spend the whole day in a lukewarm gray zone: reacting to a notification while trying to focus, lingering on focus while trying to react, doing neither properly. The most common form of depletion in a torrent of work is exactly this gray zone. Simply drawing the modes sharply makes the same amount of work far less exhausting.

Closing

People who handle the torrent are often invisible heroes. Because they quietly put out fires, others get to work as planned. But heroically drinking more water is not the answer. That way you eventually drown or burn out.

The real answer is a system. Triage to sort priority, funnel intake to make it visible, batch to protect focus, automate to erase repetition, and set boundaries to protect yourself. Do this and the hose still pours, but you can swim in it -- and beyond that, gradually tame the stream.

Don't try to drink the water faster. Become the person who governs the channel.

References

Cal Newport, Deep Work (focus and the cost of context switching)
Christina Maslach & Michael Leiter, The Truth About Burnout (burnout and control)
Google SRE Book, sre.google — interrupt and on-call management, "Dealing with Interrupts"
Will Larson, lethain.com — operational load and a systemic approach
Atlassian — incident/request triage guides (atlassian.com)
Greg McKeown, Essentialism (choosing and declining)