HomeConsulting FrameworksEisenhower Matrix
Building

Eisenhower Matrix

Sort the backlog into Do, Schedule, Delegate, Delete and protect deep work.

Building1,638 words·By Sufi Khan Sulaiman

History & Origins

The Eisenhower Matrix is attributed to U.S. President Dwight D. Eisenhower, who famously said, 'What is important is seldom urgent and what is urgent is seldom important.' The quote was later popularised by Stephen Covey in 'The 7 Habits of Highly Effective People' (1989) as a time-management framework that sorts tasks by urgency and importance into four quadrants. The matrix became one of the most widely used prioritisation tools in knowledge work, adopted by engineering teams, product managers, and executives for backlog triage and personal productivity. Its simplicity is its strength: two axes, four quadrants, and a clear action for each, making it applicable from personal to-do lists to enterprise backlog management. Eisenhower developed the insight as a military leader, where the distinction between urgent (a fire to fight) and important (a strategy to plan) was a daily tension. Covey's contribution was formalising the insight into a matrix with four quadrants and a clear action for each: Do, Schedule, Delegate, Delete. The framework spread from personal productivity into team and enterprise use, where it is now applied to backlog triage, project prioritisation, and meeting agendas. The matrix is complementary to MoSCoW (which prioritises scope) and to the 12-Week Year (which compresses execution), and it is particularly valuable for roles where reactive work constantly threatens to crowd out the strategic work that compounds.

Core Concept

The Eisenhower Matrix sorts tasks by urgency and importance into four quadrants: Do (urgent and important), Schedule (important, not urgent), Delegate (urgent, not important), and Delete (neither urgent nor important). The framework protects important-but-not-urgent work (architecture, tech-debt paydown, inventory optimisation) from being endlessly pre-empted by urgent ticket churn. The key insight is that 'urgent' and 'important' are different axes: much urgent work is low-importance, and much important work is never urgent. The matrix makes this distinction visible, so deep work gets calendared, repetitive work gets delegated or automated, and low-value work gets cut, directly reducing opex and headcount pressure. The framework also argues that the Schedule quadrant (important, not urgent) is where most strategic value is created, and that the failure mode is letting the Do quadrant (urgent, important) consume all available time, leaving nothing for the Schedule quadrant. The matrix is a weekly practice: tasks are sorted into quadrants at the start of the week, and the actual-versus-planned time is audited at the end, so the ratio of deep work to reactive noise is measured and improved. The framework also distinguishes between urgency (time pressure) and importance (strategic value), which are often conflated: a production incident is both urgent and important, but a routine report is urgent (someone asked for it) without being important (it doesn't move a strategic metric).

B2B Application Guide

In B2B companies, the matrix sorts the delivery backlog into Do, Schedule, Delegate, and Delete. An urgent production incident goes in Do (fix now). A replatform refactor goes in Schedule (important, not urgent, so calendar it). Routine reports go in Delegate (urgent for someone, not important for you). Legacy cron jobs nobody owns go in Delete. The framework makes resourcing explicit: deep work gets calendared, repetitive work gets delegated or automated, and low-value work gets cut, directly reducing opex and headcount pressure. For technology selection, it prioritises the tooling that removes urgent-but-unimportant work (alerting, self-service, automation) over shiny platforms that don't reduce reactive load, keeping opex and tech debt lean. For supply chain, the matrix sorts the inventory backlog: a stockout is Do (fix now), a safety-stock optimisation is Schedule (important, not urgent), a routine reorder is Delegate, and a legacy SKU with no demand is Delete. For merchandising, the matrix sorts the assortment work: a pricing error is Do, a private-label launch is Schedule, a routine vendor update is Delegate, and a discontinued SKU cleanup is Delete. For hiring, the matrix sorts the hiring backlog: a critical-role vacancy is Do, a pipeline-building initiative is Schedule, a routine screening is Delegate, and a stale req is Delete. For vendor management, the matrix sorts the vendor backlog: a critical vendor issue is Do, a vendor consolidation is Schedule, a routine vendor review is Delegate, and a low-value vendor contract is Delete.

Eisenhower Matrix framework graphic — Sufi Khan Sulaiman
Eisenhower Matrix — Sufi Khan Sulaiman

Step-by-Step Implementation

Step 1: List all tasks. Write down everything on the backlog, from incidents to projects to routine work. Step 2: Sort by urgency. For each task, ask: is there a time pressure (a deadline, a customer impact, a regulatory date)? Step 3: Sort by importance. For each task, ask: does this move a strategic metric (revenue, margin, reliability, retention)? Step 4: Place in quadrants. Do (urgent and important), Schedule (important, not urgent), Delegate (urgent, not important), Delete (neither). Step 5: Calendar the Schedule quadrant. Block time for the important-but-not-urgent work before reactive work fills the week. Step 6: Delegate the Delegate quadrant. Assign urgent-but-not-important tasks to someone who can handle them, or automate them. Step 7: Delete the Delete quadrant. Remove tasks that are neither urgent nor important; don't let them consume time. Step 8: Execute the Do quadrant. Handle urgent-and-important tasks immediately, but time-box them so they don't consume the whole week. Step 9: Audit weekly. At week end, review the actual-versus-planned time in each quadrant, and adjust the sorting for next week.

Common Pitfalls & How to Avoid Them

Pitfall 1: Everything is 'Do'. The team classifies everything as urgent and important, and the Schedule quadrant is never calendared. Avoid by being honest about urgency and importance; most work is not both. Pitfall 2: Not calendaring the Schedule quadrant. Important-but-not-urgent work is identified but not blocked, so reactive work fills the week. Avoid by calendaring the Schedule quadrant at the start of the week. Pitfall 3: Not delegating. Urgent-but-not-important work is done by the senior team, consuming their capacity. Avoid by delegating to junior team members or automating. Pitfall 4: Not deleting. Low-value work is kept 'just in case,' consuming time and attention. Avoid by deleting tasks that are neither urgent nor important. Pitfall 5: Not auditing. The matrix is done once and never reviewed, so the ratio of deep work to reactive noise isn't measured. Avoid by a weekly actual-versus-planned audit. Pitfall 6: Confusing urgency with importance. A task is classified as important because someone asked for it urgently, not because it moves a strategic metric. Avoid by assessing importance against strategic metrics, not against who asked.

Extended Real-World Example

A delivery team used the matrix to protect a replatform refactor. The refactor was important (it would cut change-failure rate by 40%) but not urgent (no deadline), so it was Scheduled into a recurring Tuesday-Thursday block. Urgent ticket churn was Delegated to a junior engineer. A legacy cron job that nobody owned and produced no value was Deleted. The result: the refactor shipped on schedule, ticket response time stayed acceptable (delegated), and the team's capacity flowed to work that compounded rather than reactive noise. The weekly triage log tracked how much time actually reached Do and Schedule versus Delegate and Delete, so the ratio of deep work to reactive noise was measured and improved. Over 12 weeks, the matrix practice produced a measurable shift in the team's time allocation. Week 1 audit: Do 55%, Schedule 15%, Delegate 20%, Delete 10%. The Schedule quadrant was under-invested (15%), because the team was spending most of its time on urgent work. The replatform refactor was calendared into a Tuesday-Thursday 8:00-12:00 block, defended by a calendar rule (no meetings during the block without explicit approval). Week 4 audit: Do 40%, Schedule 30%, Delegate 20%, Delete 10%. The Schedule quadrant had doubled, as the refactor block was being defended. Week 8 audit: Do 35%, Schedule 35%, Delegate 20%, Delete 10%. The team was spending as much time on important-but-not-urgent work as on urgent work, and the refactor was 60% complete. Week 12 audit: Do 30%, Schedule 40%, Delegate 20%, Delete 10%. The refactor shipped, and the change-failure rate dropped 38% (close to the 40% target). The team then re-sorted the backlog: the next important-but-not-urgent initiative (a test-automation build-out) was Scheduled into the freed refactor block. The Delegate quadrant was also improved: the routine ticket churn was partially automated through a self-service portal, reducing the Delegate load from 20% to 12% and freeing more time for the Schedule quadrant. The Delete quadrant was maintained: a legacy cron job that had been running for 3 years (nobody knew why) was deleted, saving 4 hours/week of monitoring time. The weekly audit became a standing agenda item in the team's Friday retrospective, and the actual-versus-planned time was tracked in a simple spreadsheet. The matrix practice also changed the team's hiring: a junior engineer was hired specifically to handle the Delegate quadrant, freeing the senior team for the Schedule quadrant. The result: the team's capacity flowed to work that compounded (architecture, test automation, tech-debt paydown) rather than reactive noise, and the change-failure rate, release cadence, and MTTR all improved as the Schedule quadrant investment paid off.

Measuring Success

Eisenhower Matrix success is measured by the ratio of time in the Schedule quadrant (important, not urgent) to time in the Do quadrant (urgent, important). The key indicator is the Schedule quadrant percentage, which should be trending up as the team protects deep work. In practice, this is tracked by the weekly actual-versus-planned audit, which shows the time in each quadrant. The ultimate test is whether the Schedule quadrant work is producing compounding results: are the important-but-not-urgent initiatives (architecture, test automation, tech-debt paydown) shipping and producing measurable improvements (change-failure rate, release cadence, MTTR)? If the Schedule quadrant percentage is rising but the metrics aren't improving, the work may be mis-prioritised (important but not impactful). If the Do quadrant is consuming most of the week, the team is in reactive mode, and the Schedule quadrant needs to be defended more aggressively. A healthy matrix practice produces a Schedule quadrant percentage of 30-40%, with the Do quadrant at 30-35%, Delegate at 15-20%, and Delete at 5-10%, with the Schedule work producing measurable improvements in reliability, velocity, and cost.

Framework Visualizations

Data-driven graphics showing how Eisenhower Matrix is applied to real B2B data.

Do · Schedule · Delegate · Delete
Do
• ERP fix
Schedule
• Refactor
Delegate
• Tickets
Delete
• Legacy
Time allocation
Do35%
Schedule30%
Delegate25%
Delete10%
Task distribution
Urgent+Imp
Do
Imp only
Schedule
Urgent only
Delegate
Neither
Delete
Triage steps
1
List tasks
2
Plot urgent/imp
3
Act/Schedule/Delegate/Drop
4
Re-sort cadence
Deep work trend
W1W12
Task classes
Backlog
Do
Urgent+Imp
Schedule
Imp only
Delegate
Urgent only

Explore the Full Portfolio

This is the complete portfolio of Sufi Khan Sulaiman, a technology leader specialising in B2B commerce and digital automation. Start from the Home page for the overview, then move through two decades of career experience across FLIR Systems, Lorex Technology, and 1c Platform, and the full catalogue of project case studies spanning headless commerce migrations, AI recommendation engines, and multi-channel fulfilment systems.

The skills and certifications page maps the technical and leadership capabilities behind the work, while the articles and the knowledge base break down the thinking into actionable frameworks. For hands-on learning, the tutorials and applications sections cover practical builds from front-end fundamentals to full-stack web apps.

For consulting engagement, the expertise page outlines service offerings, the ecommerce hub covers platform architecture and automation strategy, and the ecommerce guide (PDF) is a downloadable 55-page field manual. When you are ready to talk, the contact page is the direct line.