I
In my long history as first employee then consultant, one of my biggest pet peeves has always been the tap-on-the-shoulder, “hey got a quick question?” concentration destroying interaction. I started as a network administrator, which meant addressing fires was item #1 in my job, so it wasn’t so bad then. Once I moved into software development, however, I quickly came to resent how much those interruptions screwed with my work flow.
Once I transitioned out of the office into two days a week remote work, the interruptions became less frequent. It got even better when I went 100% remote, and for a time all was development bliss. Alas, I then saw company culture embrace instant messages instead, and Skype became the bane of my existence. I’ve been able to push back and moderate some interruptions; however, I’ve long sought to have the perfect link to give to skeptical management. A buddy at the coworking facility I work out of recently pointed me to Paul Graham’s “Maker’s Schedule, Manager’s Schedule” and it said everything that I lacked the articulation to say myself.
The day planner: a maker’s devil and a manager’s delight
If you haven’t read it, you should. It’s technically an oldie with hoary frost dating back to 2009, but it’s just as relevant today as then. I’ll give you a quick TLDR so I can move on, but you’d only be depriving yourself if you skip it. Its hypothesis is that the business world hinges on two different approaches to scheduling and workflow:
- The Manager: their workflow revolves around communicating and meeting with people (whether their staff, their own bosses, or customers), and they divvy their days up into short chunks. 9:30 AM: Agile sprint for Chris’s team. 10:00 AM: Report to Kathy. 10:30 AM: and so on. While they will have occasional chunks of time where they spend a few hours writing a proposal, reviewing a report, etc., they generally work shallow with ready availability for interruptions.
- The Maker: these are your software developers, your writers, and others who need focus to produce quality work. They want to go deep. If you leave them to their own devices, they’ll budget two, three or four hours to knock out a piece of code or a chapter in a book. For them, being pulled into the manager’s schedule is a huge flow state breaker, murdering their productivity.
I fully agree with this breakdown. Furthermore, Graham emphasizes a point that I’ve struggled to get across to clients when they want to schedule a chat: if you ask me to attend a meeting at 11:00 AM, you’re effectively killing my morning’s work. Ditto for 2:30 PM and the afternoon. They will often think I’m being petty, after all, can’t I just code for two hours in the morning, attend their meeting, then put in another hour in before lunch?
Graham states—and I 100% have observed the same—that just knowing that meeting is coming puts you into a shallow state of focus. Let’s say I’ve got that 11:00 AM meeting, and I just finish a function in a new class at 10:32 AM. I may make motions towards starting the next task, but let me tell you, that is going to be some superficial work. When I’ve had days where I’ve had both mid-morning and mid-afternoon work meetings, I’ve noticed the huge drop in productivity. That then leads me to having to work double-time the next day to finish my deadlines. Stressful! And, frankly, unnecessary.
Alright then, enough of this long rambling introduction. You’re with me on the gist of the manager and maker (and have hopefully read the original)? Cool, let’s get on to the point of this post: I’m going to investigate the scientific record on productivity and see if it agrees with Paul Graham’s hypothesis. I continue this in part 2 where I analyze a study that parallels it nicely.
