Small tasks, big burden: the death by a thousand paper cuts

Feeling exhausted, not from the last major system migration, not from an architectural rewrite. From everything else.

You keep working, you keep doing and delivering many things, but it feels like your task backlog does not reduce. If anything, it's increasing. Have you ever been there?

I had a recent conversation with someone feeling overwhelmed that way. "It's the small tasks accumulating mental burden over time," I shared with them. "It's the stuff that's on the back of your mind that only you know is there, and that is weighing you down."

I've been here before. We all have. The quick Slack question that takes 5 minutes. The "can you just check this?" that takes 10. The random production issue that needs eyes for 15.

None of them make it to Linear. None get discussed in retros. By Friday, you've lost a full day to things you can't even remember.

The invisible workload

Teams track sprints. Estimate story points. Measure velocity.

But they don't track:

• Context switching costs
• Mental residue from unfinished micro-tasks
• The cognitive load of keeping 20 small things in memory
• The energy drain of being perpetually reactive

It's very easy to get pulled into random requests constantly and become reactive by default. Not because you want to be, but because saying no to a 5-minute ask feels petty. That is, until those 5-minute asks compound into burnout.

Why small tasks hurt more than big ones

Big projects get respect. They have kickoffs, documentation, clear ownership.

Small tasks get none of that. They just... appear. In Slack. In passing comments. In "quick favors."

The major migration was stressful but bounded. It had a start, middle, end.

The accumulation of small tasks is unbounded. It never ends. It just grows.

The boundary problem

In those situations, I ask people to surface concerns about unplanned work. But here's what everyone replies at first: each individual task seems too small to complain about.

That's why the most expensive phrase in engineering is "it's just 5 minutes." Because it's never just 5 minutes. It's:

• 5 minutes to understand the context
• 5 minutes to do the thing
• 5 minutes to communicate back
• 15 minutes to regain focus on what you were doing

That's 30 minutes. For a "5-minute" task.

The solution isn't what you think

Most teams try to solve this with process and friction. Route through managers. Add approval gates. That slows down the whole team, and doesn't really change the system that created this in the first place. It also makes other teams slower, too, and slowly switches the expectations for everyone to move slower and accept process as-is.

The actual solution is to make the tasks visible, not just harder to request. Capture everything, add it to your Linear backlog. Then keep working on it as you were. No approval needed. No complex tracking. Just visibility.

After a couple of weeks, this will show you how many hours of "quick tasks" you have accumulated. Possibly, a big percentage of your capacity that was invisible until now.

The conversation that changes everything

Once you have that data, you can change things:

"We're spending 30% of our time on unplanned micro-work. What should we stop doing to continue this? Or should we stop this to focus on our roadmap?"

That's not being difficult. That's being strategic.

The small tasks won't go away. But they can become a conscious choice rather than death by a thousand paper cuts.

Your energy (and your team's energy) is finite. Protect it accordingly.

This piece originally appeared in my weekly newsletter. Subscribe for insights on thinking differently about work, technology, and what's actually possible.