Essentialism: The Disciplined Pursuit of Less
Essentialism: The Disciplined Pursuit of Less
The Core Idea
Essentialism is not about getting more done in less time. It’s about getting only the right things done. It’s a systematic discipline for discerning what is absolutely essential, then eliminating everything else so we can make the highest possible contribution toward the things that really matter.
The philosophy, articulated by Greg McKeown, is built on three core truths:
- “I choose to” (not “I have to”)
- “Only a few things really matter” (not “everything is important”)
- “I can do anything but not everything” (not “I can do both”)
For Principal Engineers navigating the relentless demands of technical leadership—architecture reviews, code contributions, mentoring, strategic planning, stakeholder management—essentialism offers a path through the chaos.
The Problem: The Paradox of Success
Success creates a paradox. As you become more senior:
- Your options increase exponentially
- You’re invited to more meetings, projects, and initiatives
- Your expertise is in higher demand
- You have more opportunities to say “yes”
But your time and energy remain constant. The very capabilities that elevated you now spread you thinner. You become a bottleneck. Your thinking becomes shallow. The deep technical work that made you excellent gets crowded out by shallow diversions.
The Essentialist Engineer recognizes this trap and makes different choices.
The Essentialist Way
1. Discern: The 90% Rule
When evaluating opportunities, use the 90% Rule: If it’s not a “hell yes!” it’s a “no.”
Rate opportunities from 0-100. Anything below 90 is automatic rejection. This eliminates “pretty good” options that dilute your focus from truly exceptional ones.
Application for Principal Engineers:
- Project Invitations: “This sounds interesting” (70) → Decline
- Speaking Opportunities: “I’m passionate about this topic and the audience is perfect” (95) → Accept
- Architecture Reviews: “This is core to our system and I’m uniquely positioned to contribute” (90) → Accept
- Side Meetings: “It might be useful to be in the room” (60) → Decline
The discipline isn’t evaluating whether something is good—it’s whether it’s good enough to displace something already on your plate.
2. Eliminate: The Power of “No”
Every “yes” to one thing is a “no” to something else. The question is: what are you saying no to?
When you say yes to:
- Another architecture review → You say no to: deep work on system design
- Another meeting → You say no to: mentoring your team
- Another initiative → You say no to: strategic thinking
Essentialist Engineers get comfortable with “no” because they know what they’re protecting:
Graceful No’s:
- “I’m honored you thought of me, but I’m overcommitted right now and wouldn’t give this the attention it deserves.”
- “This doesn’t align with my current priorities, but have you considered [colleague]?”
- “Let me check my commitments and get back to you” (then actually evaluate—default is no unless it’s a 90+)
The cost of saying “no” is temporary discomfort. The cost of saying “yes” is permanent dilution of your impact.
3. Execute: Make It Effortless
Once you’ve identified the essential, make it easy. Remove obstacles, create systems, build habits.
For Technical Work:
- Block calendar time for deep work before others claim it
- Create templates for architectural decision records, design reviews, postmortems
- Automate repetitive tasks (deploy pipelines, code reviews, testing)
- Batch similar activities (code reviews Tuesday/Thursday, 1:1s on Wednesdays)
Essentialists invest time upfront to make the essential activities nearly automatic, preserving cognitive resources for the work that truly requires human judgment.
The Three Essentialist Practices
Practice 1: Space to Escape
Build uninterrupted time into your schedule—not for doing, but for thinking.
- What: 2-hour blocks with zero interruptions
- When: Weekly minimum, daily ideal
- Where: Away from your desk, notifications off
- Why: Strategic thinking, learning, problem-solving require uninterrupted thought
Bill Gates famously took “Think Weeks”—a week alone in a cabin with nothing but books and time to think. You likely can’t take a full week, but you can claim two hours.
Use this time to:
- Read technical papers, books, architecture docs
- Think deeply about system design challenges
- Reflect on team dynamics and leadership
- Explore new technologies without pressure
Practice 2: Ruthless Prioritization
Most people’s to-do lists are wishful thinking. Essentialists distinguish between:
- Critical: Must happen, highest impact (5% of tasks)
- Important: Should happen, meaningful impact (15% of tasks)
- Nice to have: Could happen, minimal impact (80% of tasks)
Every morning, identify one critical task. Do it first, before meetings, before email, before Slack. Protect this ruthlessly.
Example Priority Hierarchy:
- Critical: Finalize database migration plan (blocking launch)
- Important: Architecture review for new service, mentor junior engineer on design patterns
- Nice to have: Refactor old codebase, explore new Go libraries, organize team wiki
If you complete the critical task, consider the day successful. Everything else is bonus.
Practice 3: Build Buffers
Essentialists plan for reality, not best-case scenarios. Add 50% buffer to time estimates.
- Think a task will take 2 hours? Block 3.
- Estimate a project needs 2 weeks? Plan for 3.
- Believe you can attend 4 meetings? Schedule 3.
Buffers are not waste—they’re insurance against reality. Code is always more complex, discussions always run long, incidents always happen.
Without buffers, you’re constantly behind, stressed, and unable to do your best work. With buffers, you have space to handle the unexpected without derailing your essential work.
Essentialism vs. Productivity Culture
Modern productivity culture worships “more”:
- More tasks completed
- More meetings attended
- More projects launched
- More hours worked
Essentialism worships “better”:
- Better architecture decisions
- Better mentorship for your team
- Better system designs
- Better strategic thinking
It’s the difference between a Principal Engineer who:
- Is on 15 projects (spread thin, low impact)
- Is on 3 projects (focused, transformative impact)
The first looks busy. The second is essential.
The Essentialist’s Paradox
By doing less, you enable more.
When you eliminate the non-essential:
- Your best work gets better (you have space for deep thought)
- Your team gets stronger (you have time to mentor)
- Your impact grows (you focus where you’re uniquely valuable)
- Your stress decreases (you’re not perpetually overwhelmed)
The essentialist path is counterintuitive in a culture that celebrates busyness. But ask yourself:
In five years, what will matter more:
That you attended 50 meetings per week?
That you designed the architecture that scaled your product 100x?
That you were on 20 projects?
That you mentored three engineers who became tech leads?
That you responded to every Slack message instantly?
That you wrote the technical strategy that guided your organization?
Reflection Questions
- What are you doing that could be done by someone else, or not done at all?
- What would you do if you had only 50% of your current time? (That’s your essential work)
- What are you saying yes to out of guilt, FOMO, or ego rather than genuine contribution?
- If you could only work on three things this year, what would create the most impact?
- What non-essential commitments are you ready to eliminate this week?
Practice: The Essentialist Audit
This week, track every commitment:
- Meetings attended
- Projects worked on
- Requests accepted
- Interruptions entertained
For each, score 0-100 on impact. Anything below 90 is a candidate for elimination.
Essentialism is not a one-time choice but a continuous discipline. The pull toward non-essential work is relentless. The question is whether you’ll have the courage to protect what matters.
“The word priority came into the English language in the 1400s. It was singular. It meant the very first or prior thing. It stayed singular for the next 500 years. Only in the 1900s did we pluralize it and start talking about priorities. Illogically, we now have a multitude of ‘first’ things.”
— Greg McKeown
Choose your singular priority. Then build your life—and your engineering career—around it.