Eisenhower matrix
Have you heard of the matrix named after U.S. President Dwight D. Eisenhower? The method it represents is based on a quote often attributed to him:
"I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent."
While Eisenhower himself credited a former college president with the insight, the prioritization framework built around this idea is now widely known as the Eisenhower Matrix.

What Is the Eisenhower Matrix?
The Eisenhower Matrix is a simple 2x2 grid that helps you categorize tasks based on two dimensions:
Is it important?
Is it urgent?
This gives us four categories:
Important and Urgent
Important but Not Urgent
Not Important but Urgent
Not Important and Not Urgent
Let’s explore how to handle each category — specifically in the context of software development.
Important and Urgent: Do It Now
These are critical tasks with immediate consequences. You can’t delay them.
Example:
A production bug that crashes your mobile app or exposes user data. These demand immediate attention and often become fire-fighting situations. As a developer, you drop everything and fix the issue.
Important but Not Urgent: Schedule It
These tasks contribute significantly to your long-term goals, but don’t need to be done right away. Ironically, these are the most valuable tasks, yet the easiest to neglect — until they become urgent.
Examples:
Refactoring legacy code that slows you down
Writing tests for a critical but fragile module
Designing a reusable architecture for a feature
Documenting onboarding guides for new team members
Tip: Block time in your calendar. If you don’t proactively schedule these, they’ll become urgent at the worst possible time.
Not Important but Urgent: Delegate It
These tasks create pressure but have little strategic value. They often stem from someone else’s priorities. If possible, delegate them — or at least batch and automate them.
Examples:
Responding to certain status update requests
Filling in timesheets or basic reports
Approving non-critical pull requests that someone else could handle
Answering internal questions that could be answered from the wiki
Tip: If you're a senior developer or team lead, use your position to empower others to handle these — without micromanaging.
Not Important and Not Urgent: Eliminate It
These are time-wasters. They don't move you or your team forward and often persist out of habit or organizational inertia.
Examples:
Over-engineering a prototype you’ll throw away
Bikeshedding over naming conventions or font choices
Attending meetings with no clear agenda or value
Maintaining outdated internal tools that nobody uses
Tip: Just stop doing them. If someone insists they're necessary, ask whether they are either urgent or important. If not, it’s probably safe to let them go.
When the Matrix Isn’t Enough
The Eisenhower Matrix is a great addition to your toolbox, but it’s not a silver bullet. Like any tool, it has its limitations.
Of course, not. There is no silver bullet, this is just a tool in your toolbox. Yet, it gives a quite good rough estimation on whether you should deal with something or not.
Though there are other methodologies and some things two consider.
Dependency Delays
Sometimes a task is both urgent and important—but blocked by another person or system. In such cases, escalate or communicate, then track the task separately until unblocked.
Example:
You can’t implement a change in your system, because you must wait for an API update from another team. Urgent for you, but not actionable right now.
The “Small Stuff” Dilemma
Some low-priority tasks take less time to finish than to delegate or schedule.
Example:
Fixing a minor typo in documentation or re-running a failed CI job. Don’t overthink it—just do it if it takes less than 2 minutes.
Context Switching and Focus
The matrix doesn't account for the mental cost of task switching. Jumping between quadrants—especially urgent tasks—can break flow and reduce effectiveness. Group similar tasks where possible.
Final Thoughts
The Eisenhower Matrix won’t make your decisions, but it helps you think more clearly. As a software developer, your time and attention are limited. Prioritization isn’t just about productivity, it’s also about protecting your ability to do meaningful work.
Use this matrix as a compass, not a cage. Balance it with your experience, team dynamics, and long-term goals.