What engineering tasks belong in the Do (urgent + important) quadrant?

Production bugs actively breaking user flows, security vulnerabilities being exploited, deploy blockers preventing a release, and P0 on-call alerts. These demand your immediate attention because real users are affected right now. The test: is there a user blocked or a system down because of this? If yes, it's Do.

Why does tech debt belong in the Plan quadrant, not Do?

Tech debt is important, it slows velocity, creates bugs, and makes the codebase harder to change, but it rarely has an immediate deadline with user consequences. That makes it Plan (important, not urgent). The danger is letting Plan work slide until it becomes a Do crisis: tech debt ignored long enough turns into a production outage. The Eisenhower Matrix forces you to schedule it deliberately before that happens.

What should software engineers stop doing entirely (Drop quadrant)?

Premature optimisation on code that hasn't been profiled, building features without evidence of user demand, attending recurring meetings where your presence changes nothing, fixing cosmetic issues in internal tools used by three people, and gold-plating abstractions for hypothetical future requirements. The Drop quadrant isn't about being lazy, it's about protecting your Do and Plan time from work that creates noise without value.

For Software Engineers7 min readProductivity

Stop Firefighting.
Start Shipping
What Matters.

Q: How do software engineers use the Eisenhower Matrix?

Software engineers use the Eisenhower Matrix by categorising work into four quadrants. Production bugs causing user-facing errors, security vulnerabilities, and deploy blockers go in Do (urgent + important). Refactoring tech debt, architecture documentation, performance baselines, and skill-building go in Plan (important, not urgent). Status meetings that don't require your judgment, wiki updates, and low-priority bug triage go in Delegate. Premature optimisation, features with no validated user demand, and scope creep go in Drop.

Q: How do you handle constant interruptions as a software engineer?

Most interruptions are Delegate tasks wearing an urgent costume: Slack pings asking for status, requests to update the wiki, invitations to meetings where you have no decision power. Before interrupting your deep work, ask: does this require my specific judgment right now? If not, it's Delegate: batch it, redirect it, or handle it in a scheduled interruption window rather than context-switching mid-task.

April 7, 2026

Engineers default to urgency. The production alert, the Slack ping, the GitHub notification, the job trains you to treat everything as a P0. The result is a calendar full of reactive work and no time left for the architectural thinking, the refactoring, the deep learning that actually compounds your career.

The Eisenhower Matrix doesn't eliminate urgency, it helps you distinguish real urgency from manufactured urgency. Most of what feels urgent in engineering isn't. Here's what an honest matrix looks like for a software engineer's sprint backlog.

Do: the real P0s

A production bug actively blocking users from completing core flows belongs in Do. A security vulnerability being exploited belongs in Do. A deploy blocker preventing your team from shipping belongs in Do. These have a user impact happening right now, and your unique engineering judgment is what's needed to resolve them.

The test is not “does this feel urgent”, it's “is a user blocked or a system down right now because of this?” On-call alerts that pass this test are Do. The Slack message asking for a status update on a non-critical feature is not.

Plan: where your career actually grows

Refactoring that unmaintainable module, writing architecture documentation for the new service, building a proper test suite for untested code, learning the framework your team is migrating to, all of these are important. None of them have a deadline this sprint. Which is exactly why they never get done.

High-performing engineers protect Plan time the same way they protect incident response: deliberately, with blocks on the calendar that don't move. If your Plan quadrant is empty, you're trading future velocity for present firefighting. Tech debt left in Plan too long becomes a Do crisis.

The engineer's 10-second sort

→User blocked or system down right now? Do it immediately.

→Important for architecture, quality, or your growth, but no hard deadline? Schedule it in Plan this sprint.

→Urgent but doesn't need your specific engineering judgment? Delegate or batch to an interruption window.

→No user impact, no deadline, no architectural relevance? Drop it, protect your Do and Plan time.

Delegate: not every ping needs you

Status update meetings where you have no decision power, wiki edits anyone on the team can make, non-critical bug triage that doesn't require your specific context, these are Delegate tasks. They have an urgency signal (someone sent a message, a notification appeared) but they don't require your engineering judgment.

The practical pattern: designate two daily windows for Slack, email, and non-critical pings. Outside those windows, your attention stays on Do and Plan work. This isn't about being unresponsive, it's about protecting the deep-work blocks where real engineering happens.

Drop: the hardest call in engineering

Premature optimisation on code that hasn't been profiled. Features on the backlog with no evidence of user demand. Cosmetic improvements to internal tools used by three people. Gold-plating abstractions for hypothetical future requirements. These feel like engineering, they satisfy the craftsman instinct, but they create no value. Delete them from your list.

The Drop quadrant is where senior engineers earn their seniority: knowing what not to build is harder, and more valuable, than knowing how to build anything.

Frequently asked questions

How do software engineers use the Eisenhower Matrix?

By sorting engineering tasks into four quadrants: Do (prod bugs, security vulns, deploy blockers), Plan (refactoring, architecture docs, skill-building), Delegate (status meetings, wiki edits, non-critical triage), Drop (premature optimisation, unvalidated features, scope creep). The side panel on this page is designed to stay visible as a quick reference while you work through your task list.

What engineering tasks belong in the Do quadrant?

Production bugs actively breaking user flows, security vulnerabilities being exploited, and deploy blockers preventing your team from shipping. The test: is a user blocked or a system down right now because of this? If yes, it's Do. Everything else that feels urgent probably isn't.

Why does tech debt belong in Plan, not Do?

Tech debt is important, it slows velocity and creates bugs, but it rarely has an immediate user consequence today. That makes it Plan: important, not urgent. The danger is letting it stay in Plan until it becomes a Do crisis. The Eisenhower Matrix forces you to schedule it deliberately each sprint before that happens.

How do you handle constant interruptions as a software engineer?

Most interruptions are Delegate tasks in urgent costume. Before switching context, ask: does this require my specific engineering judgment right now? If not, batch it to a designated interruption window instead of context-switching mid-task.

What should software engineers stop doing entirely?

Premature optimisation on unprofiled code, features with no validated user demand, cosmetic polish on internal tools, gold-plating abstractions for hypothetical requirements, and attending recurring meetings where your presence changes nothing.

Sort your sprint backlog right now

Open Focus Quadrant, add your current tasks, and drag each one into a quadrant. The physical act of placing tasks forces the question, most engineers find they can drop or delegate 40% of what felt urgent.

Open Focus Quadrant, Free