How to Take Control of Your Workload
Most engineers I know aren’t struggling because they work slowly or lack focus.
They’re struggling because they’ve quietly accepted a premise that isn’t quite true: that the queue is the queue, and your job is to drain it.
Sprint starts Monday. By Wednesday, two new “urgent” requests have arrived. You absorb them. You work late on Thursday. By Friday, you’ve shipped something, but not the things you planned to ship.
The original priorities slip to next week. Next week looks the same.
This isn’t a discipline problem. It’s a decision problem. And more of it is yours to make than you’re probably acting on.
Why the Queue Never Empties
There’s a well-documented reason urgent tasks crowd out important ones.
Researchers Zhu, Yang, and Hsee call it the mere urgency effect: when tasks carry a time pressure, people systematically choose them over tasks with objectively better payoffs, even when the urgent task is trivial. The feeling of urgency is compelling, independent of the value of the work.
On a software team, this gets compounded because urgency is often externally applied:
- A stakeholder flags something as critical.
- A Slack message implies a customer is waiting.
- A manager asks for an update on something you haven’t started yet.
None of these signals is wrong on its own. But together, they create an environment where everything feels like it belongs at the top of the list.
DORA’s 2024 Accelerate State of DevOps Report found that unstable priorities cause meaningful decreases in productivity and significant increases in burnout, even in organizations with strong leadership, good documentation, and a user-centric culture.
You cannot fully compensate for a broken priority environment through personal effort. At some point, the system has to be negotiated, not absorbed.
The ratio matters more than the effort.
High-performing teams spend close to 50% of their time on planned new work and around 20% on unplanned work and rework. Low-performing teams nearly flip that. If your week looks more like the latter, working harder doesn’t fix it. The mix does.
The Eisenhower Matrix Is a Starting Point, Not a System
The most common framework for this problem is the Eisenhower matrix: a two-by-two grid that sorts tasks by urgency and importance.
It’s a useful diagnostic. The quadrant labeled “urgent but not important” is where most of the queue lives, and naming that is genuinely helpful. I’ve even referenced it before in previous newsletters.
The problem is that the matrix was designed for someone with the authority to delegate. Its core move — handing off urgent but not important work — isn’t available to most ICs.
- You can’t delegate a Slack escalation to a junior developer.
- You can’t push the production bug to someone else because it scored low on importance.
- You can’t act on the category once you’ve identified it.
It also assumes you already know what counts as important. Without an explicit, externally validated definition — a team objective or a product priority your manager has actually named — “important” becomes whatever you personally believe matters most.
That’s fine when your instincts are well-calibrated. It’s unreliable when priorities are shifting.
Use the matrix to spot the pattern. Don’t rely on it as an operating system.
|
|
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.
|
|
Four Questions To Help Prioritize
When the queue fills up, the goal isn’t to rank everything. It’s to identify what genuinely has to happen and make the tradeoff visible on everything else.
These four questions help:
1. If this doesn’t get done this week, what actually breaks?
Not “what would be inconvenient” or “who would be annoyed.” What downstream process fails, what customer commitment is missed, what team is actually blocked? If the honest answer is “nothing significant,” that’s useful information.
2. Who is blocked by this, and how badly?
A teammate waiting on a code review to merge a feature is blocked in a real, measurable way. A stakeholder who asked for a status update by the end of the day is uncomfortable, not blocked. Both feel urgent, but only one actually is.
3. Is this urgent because of a real deadline, or because someone is anxious?
Anxiety moves fast on a software team. An escalation often signals someone’s concern more than an actual constraint. This question isn’t a reason to dismiss the request. It’s a reason to ask one more question before reprioritizing your day around it.
4. What would I have to stop doing to take this on?
This is the most important one. Every new item displaces something.
Picking up a coding task after an interruption typically takes 15 to 30 minutes to reconstruct context, and interrupted work carries a higher error rate than uninterrupted work. Our January issue on context switching explains how badly this compounds throughout the day.
Making the displacement explicit, even just to yourself, makes the decision real.
Deprioritizing Is a Communication Skill
The mistake most engineers make is treating prioritization as a solo act.
They quietly decide to push something back without telling anyone. Or they quietly absorb the new request without telling anyone what slips. Both create problems.
The more useful move is to make the tradeoff visible. When something new comes in that would genuinely disrupt your current work, the response isn’t “yes” or “no.” It’s:
“I can take this on, but it means X shifts to next week. Is that the right call?”
That invites a real decision from the person asking and protects you if the tradeoff turns out to be the wrong one.
This is where lightweight frameworks like MoSCoW, which sorts work into Must, Should, Could, and Won’t, have their actual value. Not as a scoring system, but as an artifact.
Writing down what you are not doing, and why, creates something that can be reviewed and debated. A line in your weekly update that says “I’m holding X for the next sprint because it depends on Y being resolved first” is more useful than a grid. It makes the tradeoff legible.
Most of what makes this hard isn’t knowing how to prioritize. It’s understanding how work actually gets decided, escalated, and constrained inside your organization — and recognizing where your judgment fits into that.
That’s the part most engineers underestimate, and it’s what separates consistent delivery from a full queue that never moves. If that layer feels opaque, understanding all the systems you work with is worth your time.
What does your planned-to-unplanned ratio actually look like right now? Reply and let me know. I read each email.