Deep Work by Cal Newport 📖

I’ve found I need uninterrupted time to focus for software projects at work, and actually leave work unsatisfied if I’m unable to find this time. While investigating what this is all about, I came across Newport’s Deep Work.

The first half of the book makes a case for investing in focus time, especially for folks performing “knowledge work”, which can require workers to hold many details in mind to produce significant output. The second half of the book provides practical recommendations for how to set aside uninterrupted time.

Focus time

Like Paul Graham’s Maker’s Schedule, Manager’s Schedule, the first recommendation is to explicitly identify and reserve time for focused work, which I found validating.

In practice, I find a couple common sources of distractions:

  • random requests and discussions via email, chat, etc
  • random requests and discussions around my desk area

The book recommends avoiding interruptive electronic communications, especially social media, when trying to focus, and makes a case that most interruptions can wait.

Regarding in-person interruptions, the author mentions sequestering himself in a library. I might try something similar.

One challenge I see: focus requirements might be dependent on when as well as what. For example, the early days of a project might be meeting-heavy as requirements are clarified, and then focus-heavy as pieces are built.

My current experiment is to reserve 8-10 and 2-5 for focus work. During these times, I’ll sit away from my desk and ignore chat and email. This leaves a couple hours before and after lunch to catch up on electronic communication, have spontaneous discussions and provide a reasonable window for scheduling meetings.

The book cites research indicating our ability to work deeply maxes out around four hours, which also aligns with my experience. I previously experimented with reserving 1-5, but found it was too restrictive for natural interactions with colleagues, and I didn’t need the entire time anyway.

In an effort to provide “ownership” for my project, I took pains to be aware of all changes and support requests. This obviously doesn’t scale, but I appreciated reading a supportive quote from Tim Ferris:

Develop the habit of letting small bad things happen. If you don’t, you’ll never find time for the life-changing things.

Productivity

An interesting aspect of this book is it’s not simply presenting thoughts on the topic of deep work; it was motivated by the author’s need to optimize productivity. In this context, the book introduced me to 4DX, which is like agile boiled down to four points. As with agile, I find myself referencing it often.

In particular, I appreciate the emphasis on prioritization; during focused effort, we say “no” to many things so we can say “yes” to the most important things.

The book also mentions the idea of “results-driven reporting”, which defers meetings until there’s something new to report, as an alternative to status updates. This aligns with recommendations to prioritize requirements and blockers over status updates in cadence meetings from a recent talk on politically-charged projects.

4DX

The book Deep Work, by Cal Newport, introduced me to The Four Disciplines of Execution (4DX):

  1. Focus on the Wildly Important, aka Prioritize
  2. Act on the Lead Measures
  3. Keep a Compelling Scoreboard, aka Measure progress
  4. Create a Cadence of Accountability, aka Have cadence meetings

I’ve found each of these practices helpful, but hadn’t seen them listed succinctly.

I think the second point (“Act on Lead Measures”) provides interesting context for OKRs, which several teams I’ve been on have used. 4DX describes lead vs lag metrics. For example, we have to wait thirty days to know if we’ve increased thirty-day active users, so there’s a thirty day lag in the metric. As opposed to other metrics, e.g., signups per day, features built, etc., that can be measured on a smaller scale and correlate with increasing thirty-day actives. Objectives seem like lag metrics, and KRs like lead metrics.

Batch interviewing

Problem

Interviewing can be expensive for a number of reasons.

For interviewees:

  • Traditional hiring pipelines are at risk of institutional bias, which decreases efficiency when sourcing candidates from diverse backgrounds.
  • Accumulating experience interviewing, a key factor for success, is hard when each company has a different process.

For interviewers:

For recruiters:

  • Scheduling several people at arbitrary times is also costly (unless interviews have top priority, in which case this cost is pushed onto the interviewer).
  • Motivating everyone on an interview panel to submit feedback quickly is hard, which delays hiring decisions.

(Thx, Megha, for feedback regarding problem/solution presentation!)

Solution

Schedule interviews in blocks, eg 5 back-to-back interviews in a day.

Perform a quick evaluation after each interview, eg 45 minutes of interview, 10 minutes of eval, 5 minutes to transition.

Huddle at the end of the day, ask each interviewer to vote, stack rank candidates, and make hiring decisions.

Benefits

Enable interviewees to efficiently gain experience, and administrators and recruiters to efficiently schedule, by adding interview blocks to a standard process.

Eliminate a source of institutional bias in the hiring pipeline by moving interviews to the candidate.

Amortize warm-up cost and increase evaluation accuracy by asking the same question repeatedly.

Discussion

Batch interviewing, aka on-campus interviewing, is common at some schools, notably Waterloo, which in my experience consistently produces high-performing candidates. (Students also gain an uncommon amount of practical experience through their co-op program.)

Uber runs a day of batch interviews at CSUMB in the spring for summer internships.

My experience with batch interviewing came from a two-day interview batch in Japan.

All these examples involve travel, which may have an impact on the value, ie would batch interviews provide the same cost/benefit when used at a business’ location?

One of the primary concerns I’ve heard expressed is the cost of finding a time that works for candidates, ie traditional scheduling seems optimized for meeting candidates when they’re ready. I’m curious to experiment with publishing a interview block, eg we hire on Fridays, to test this.

Ashwin Raghav shared his experience (thx!):

  • I have participated (as an interviewer and as an interviewee) in batch interviews in India. Very common practice in engineering schools.
  • I did not go to an elite school, which meant that everyone wanted to participate in any company’s recruitment drive.
  • This was often tiring for the interviewers because of the sheer number of interviews and for the interviewees because giving them accurate time slots to take interviews was not easy – meaning they waited for their turn.
  • A lot of the candidates are friends among themselves. They share their interview experience once they exit the interview. This forced us to keep changing questions as interviewers to keep up the difficulty level.
  • I always remember these being very intense emotional experiences compared to industry hire interviews because of the scale of participation. It helped if interviewers were “nice” / “not assholes”
  • Always helps to have a college alumni in the team. I would have never known about sharing interview questions if I did not go back to interview as an alumni.