What Is Deep Work?

Deep work is when you spend long, uninterrupted stretches of time focusing on hard problems that require your full attention. Writing code, planning a complex architecture, strategic planning. Not emails, not Slack, not the quick tasks you cross off your list for a momentary sense of accomplishment. Definitely not the paper airplane you built out of tissue paper.

Cal Newport introduced this term, and his book on the subject is worth reading. I’ve read it at least 3 times over the years!

These are the sessions where you grab a cup of coffee and get lost in your work, forget about time. Some call this flow, and for knowledge workers it’s often what makes or breaks a career.

The problem is that your job, coworkers, and life aren’t arranged around deep work. Things beg for your attention from every direction, everything feels like a minor emergency, and in the short term all of it seems more important than that deep work you keep putting off.

These are the most important things I’ve been experimenting with lately that are working well so far.

1: Arrange Deep Work in Sprints

When I’m working on a hard problem, I want to keep going until I’ve captured value. Making that breakthrough often takes more than a few hours, sometimes days to do it well. I find it best to plan for that. I call these sprints, loosely borrowed from the agile model.

I typically do an approximate estimate (“this will take me 2 days”) and sometimes I finish early, sometimes it takes a bit longer. Nobody is going to be able to work 100% on their sprint commitment. Maybe you can spend 2 hours, 4 hours, or 6 hours if you’re lucky. The idea is to commit to some non-negotiable amount you will do each day during that sprint.

At the end of a sprint, I want to feel like I did something important. I moved the work forward and took it to a new level. Now it’s time to stop and look around for what’s next.

2: Include a Random Day Between Sprints

Things will come up every day that you’re not expecting: follow-up emails, research projects, miscellaneous requests. If you can hit your deep work targets and still handle those things that day, great, do it. But that won’t always be the case. When it’s not, I defer them until the sprint is over. Then I take a “random day” to knock them all out.

A random day is when I go through the list of smaller things I deferred. They’re their own mini projects. Sometimes I can do 5 in a day, sometimes 20 depending on the size.

By the time I finish a sprint and have that tremendous sense of accomplishment, those “death by a thousand cuts” tasks suddenly don’t seem so bad. They become a welcome break from the intensity. I take the random day to clear the backlog, then roll into my next deep work sprint.

3: Stop Torturing Yourself with Recurring Tasks

Recurring tasks accumulate and will kill your deep work. Twenty minutes reviewing my calendar, an hour on pull requests, thirty minutes on metrics. Suddenly half your day is gone before you’ve touched your real work. If you want to spend 5 hours coding but have 2 hours of daily obligations, there’s no room left for unexpected emergencies. Something has to give: either you burn out trying to cram in your deep work, or you keep cutting it back until it barely exists.

You don’t need to repeat everything every day. I review pull requests only on Mondays, Wednesdays, and Fridays instead of daily. App metrics I check on Tuesdays and Thursdays.

I’ve surprised myself with how much more efficient I am when I create scarcity of time. And sometimes, problems resolve themselves when I’m not immediately jumping on them.

---

If you find yourself constantly shifting between small tasks while your most important work never gets done, it might be time to get serious about protecting your deep work. Sustained focus on hard problems over time is what separates good work from great work.