Maker's Schedule, Manager's Schedule (2009)
paulgraham.com
paulgraham.com
> I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there's sometimes a cascading effect. If I know the afternoon is going to be broken up, I'm slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you're a maker, think of your own case.
Over the years as I've gone back and forth between IC and management, adjusted my working schedule after having kids, and generally improved my self-control habits, I no longer identify with this part of the essay.
In retrospect, this essay told me what I wanted to hear at the time: That I was a maker and that my managers just didn't understand that my lack of productivity was actually their fault for scheduling a single 1-hour meeting in the middle of the day. I thought meetings should be someone else's job, not mine, and I ate up every excuse to despise them. This essay included.
The reality was that my company at the time didn't have an excessive number of meetings, nor were they poorly run. Some companies really do have a ridiculous number of poorly-run meetings, but it's not the norm at well-run engineering companies in my experience. (If your company is all meetings and no work, it's time to change jobs).
Eventually I started making an effort to get back into the groove quickly after interruptions. When I get back to my desk, I pause for a moment and make a deliberate effort to recall where I left off. I decide what I'm going to work on before I unlock the screen. I resist the urge to pull up my e-mail or HN or Twitter or Instagram for "just a few minutes" before getting back to work. And to my surprise, it worked! If I put some minimal effort into it, I can get right back into the task I was working on, even complex ones like debugging complicated programs.
PG talking about "spirits" dictating our productivity now reminds me of a famous quote that has been attributed to various authors at different times:
> I write when I’m inspired, and I see to it that I’m inspired at nine o’clock every morning.
I agree with you that a 1 hour meeting probably shouldn't ruin your whole day, but I also feel like it can take a fair bit of time to essentially reload the problem I've been working on back into my brain if it happens to be a fairly complex one. This is compounded if it's an actual meaty technical meeting because not only do I lose my train of thought but I have to start a while bunch of other ones and also attempt to jot them down before returning to where I was.
Sounds like you've been at this significantly longer than me, maybe context switching is a skill I just haven't acquired yet...
When stepping away from a technical task, I often jot down a bunch of notes that really only I could ever comprehend - words, doodles, whatever scrawl. Usually its related to the problem I'm trying to solve, but I often suspect it doesn't even matter what I wrote down. Because of the fact that I wrote it down while my brain was steeped in the technical task, reviewing the notes helps me get back into that headspace.
You learn to do what you need to, in time.
So I largely agree with the OP here: you can either use this as an excuse - "I'm just not that good at context switching, so it's out of my control, if only my manger understood!" - or you can take it as a growth opportunity and decide to try to get better at it. For me, that's looked like a lot more note-taking (I can use this to "reload" my previous context later) and a lot of practice at discipline at just getting back to work even if it means I have to duplicate some steps from before.
The note-taking, it's turned out, has also helped massively, since it makes it easier to bring other people up to speed on what I learned and all the nuances of it.
But obviously this is a work in progress, since I'm here on HN instead of immediately jumping back in to the previous context I had before getting lunch. ;)
It's of a piece with the impulse I see so often to also downplay and denigrate the difficulty of doing engineering work.
You can however practice a specific thing so it no longer feels like a big deal. If you have gone to a thousand meetings then having another one wont be distracting. But most software engineers don't do enough management work to get over that hurdle.
No one who knows what they're talking about would debate that engineers need large blocks of uninterrupted time to get anything done.
But at the same time, not all software projects can be divided up in such a way that individual engineers can just do their thing without frequent communication. This is the whole art of large scale software development, and it is incredibly difficult to get right. Minimizing overall meeting time so ICs can focus is just one consideration, you also need to make sure the right people have a seat at the table for certain decisions or you run the risk of building entirely the wrong thing.
As an engineer you have to fight for your own time, but also trade off against the greater good. If you put your work on a pedestal above everyone else around you (designers and product managers are also ICs that need focus time) then you'll hit a ceiling in terms of the impact you can drive (unless you are a researcher or deep specialist, but those roles are comparatively rare).
1. This problem of constant interruptions through email, slack, etc affects everyone. It's extremely arrogant to pretend that it's primarily a problem for the special engineers. (I'm an engineer).
2. The idea that you can't be effective if you don't have half a day free everyday is frankly bullshit, and it gives people a victims mentality if they accept it. Yes, people need uninterrupted time. I assure you that I can code effectively in blocks of 2 hours. It may be slightly less efficient if the only thing that matters is coding, but a lot more matters that pure coding.
Sure you'll pay the cost of context switching, but that's 15 minutes at the max.
Not working because you've got a meeting in the near future is just not working. You don't have to do everything all at once. You don't have to have 100% efficiency or 0%
Although I agree that just because there's a meeting in the afternoon, it's not like you can't start something big (could also start something small, or chunk up the big task), however, I think the article still has something useful to remind managers, even today.
I wouldn't say that "meetings" are by any means the only or most helpful kind of variety, but if you need to do them anyway, a few per week is not the worst thing in the world.
(And by a few I do mean a few... less than 10 definitely, and ideally well under)
Where did the time go?
I think how you approach this maker vs manager time / schedule interruptions may also be heavily influenced by whether you see meetings as productive (chance to align, ensure your work is in right direction, get and provide answers and tips, etc); or obstructive (changing what you're doing, wasting your time, interrupting your flow, etc).
Not only will you view the interruption differently, I think it will also genuinely alter how quickly and efficiently you actually return to productive state of mind. If you resent a meeting, the emotional state of your brain will actively (even if subconsciously) work to prevent you efficiently returning to your problem.
I've started actively trying to not resent even meetings that I personally find unproductive; looking for charitable angles such as "This may feel like waste of 30min to me, but it'll save many hours to many other attendees so it's a good thing overall" or "it'll accomplish these goals of client/business/management, and they're the ones writing the cheques, we are here in their service"; and I've found with some planning focus and discipline, I don't lose as much time as I did before.
I feel like this undersells the problem, in part because writing does not perfectly match onto software engineering.
I've been working on my productivity for years and I've found how much I'm impacted by interruptions is directly proportional to how hard I need to concentrate to get the work done.
Occasionally my work really pushes up against the limit of how much cognitive load I can handle at which point if the problem required me to track a single more moving piece it would fall apart and I'd fail to solve the problem. At the level of concentration required for that kind of cognitive load I find that on most days I have 2-4 hours of work in me and it must be in a single continuous stream. If I'm interrupted after the first half hour I can still work but I can't get back to that level no matter how hard I try.
Most work doesn't push me that hard. If I'm writing a simple database query or a form in React interruptions are still bad but not so much they ruin my productivity.
I've found this pattern holds true for a goodly number of other engineers as well and think managers should be cognizant of how hard their engineers find their work and plan accordingly. The impact will be different on different teams e.g. my experience would suggest minor interruptions are far less ruinous for web dev teams than those working hard systems work.
Engineer: I would be more productive if we changed X.
Manager: You are lying, I am not hurt by X, you shouldn't be either!!! Just try harder and you will be just as productive!
Nobody argued you can't "go right back into it" (e.g. instead of going to check your email or Facebook, or whatever). The problem is not being able to "go back into it", but to "go back into it without having blown mental state".
"Going back right into it" is easy for simple tasks, which don't require building and following an elaborate mental model. It's bad for implementing subtle or complex behavior, debugging, (re-)architecting a system, and so on.
That it's a problem it has been known for half a century, and it's not just about meetings, all kinds of "context switching" hurt developers.
And perhaps it's not that the essay told you "what you wanted to hear at the time", but that it tells you what you don't want to hear at this time :-)
If you do go into management, learn to protect enough time for deep work, you need it too.
Edit: "They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started."
This right here is frankly bullshit, and it's wrong on two levels. 1. You absolutely can get into coding or writing in chunks of less than half a day. Second, thinking strategically as a leader is just as hard to get into as coding and/or writing. Leaders/managers have the same challenge, they just have busier calendars.
We have tried various things, work blocks, no meeting days, etc. without ever really understand what the true root of the issue is.
I am curious how others have solved this dilemma in a very business driven world where things are to be managed.
- Get rid of as many standing meetings as you can, and then get rid of more of them (1 a week is max)
- At the end of every standing meeting, ask the group "Do we still need this meeting?"
- If you feel you need a regular standup, do it on slack/whatever-you-use instead and asynchronous
- The non-makers still need to be able to communicate with the makers, provide a clear chain of communication so that the smallest number of makers are disturbed in an ad-hoc fashion, preferably only 1 (usually a tech lead / engineering manager)
As an engineer-turned-manager, I try to be respectful of people's time when it comes to meetings.
Basic meeting courtesy is mandatory:
- Schedule meetings at convenient times for everyone, preferably around natural breaks like lunch time. 1PM meeting after lunch before everyone gets back to work is good. 10:30AM meetings that break up people's morning are bad.
- Send a short agenda for the meeting in the invite. No agenda = no meeting is a good rule. Request agendas from others when invited to a meeting.
- Stick to the agenda and respect people's time. If a conversation goes on more than a few minutes but only concerns a few people, either have them take it offline or add it to the bottom of the agenda so you can cover it after everyone else has been dismissed.
- Keep things as predictable as possible. It's much better if everyone knows that meetings are generally scheduled around lunch time, always come with an agenda, and that off-topic discussions will be discouraged. Don't keep people guessing about whether or not a meeting will be productive.
Finally, some employees can benefit from a little coaching and mentoring about how to get back in the groove. If someone is struggling to get anything done on days with meetings, they will likely benefit from some coaching about how to best manage interruptions and get back into the workflow. They can also benefit from increased accountability around those days, which doesn't have to be painful if handled correctly. Some people have some "learned helplessness" around interruptions at other companies where they don't bother doing anything on days where meetings are on their calendar. Training this out of employees and setting healthy but reasonable expectations is very important.
As such, I've been pushing all of these discussions and meetings to tuesday afternoon, or maybe thursday afternoon on some weeks. Sure, there might be 6 or 8 different topics on that afternoon, but that's fine with decent meeting culture and some preparation.
The last 2 VPs I've been under have had similar takes on meeting attendance: don't feel obliged to continue in a meeting if it's not providing value to you and you aren't providing value to it. This is, admittedly, way easier in COVID, where you can just drop off without much notice. But there's a polite way to do this in person (send an IM message to the meeting organizer politely saying you have other commitment/need to work on a near term delivery, and excuse yourself from the room).
Depending on the situation, I've found your-mileage-may-vary with trying no meeting days. Currently, as a principal engineer at a big tech company, it pretty much doesn't work. At smaller companies (or in smaller teams) I've found it works better.
- Is the manager reducing bureaucracy for you or increasing it? Reducing is better
- Is the manager able to solve people challenges or is he shoving it down to you? Politics is strictly a management domain. They should be able to talk around the org and get shit done, even when someone not on their team is impeding progress
- Does the manager take ownership of failures of the team or does he shove down the failure to ICs? For those uninitiated, the manager takes responsibility of failed projects
- Does the manager celebrate your achievements and success or do they just paper over it? The manager should be the biggest cheerleader of successes of their engineers. If they don't highlight your work to upper management, that will impede your growth in the career ladder. DO NOT WORK TOO HARD for such lazy, incompetent managers. Your work is not appreciated
- Does you manager lie? Should be obvious, but a lying manager will lie to save themselves, even if they are only lying to others today.
Is this checklist large? Not really considering how much impact a manager can have on an ICs career.
ICs should be aware of these traits and should hold their managers to high standards. If manager cannot do even this much, quit asap.
Co-incidentally I found myself working this same schedule at my first full-time job in the 90s. The 11am slipped into mid-afternoon and there was a period where an all-hands/devs meeting (I think it was for deciding the release details of our shrink-wrap physically shipped software) was set for 6pm to be certain I'd be present. It certainly was productive. Sometimes I'd have a vague idea in the afternoon and have a prototype running demos the next day that became a shipping feature within a week.
When you love what you're making, you can do it in small increments amid interruptions, and pick up right where you left off. Your brain never leaves "maker mode"; the gears keep spinning in the background while you're away from it.
That's how it's been on my side projects for years.
You might get large blocks of uninterrupted time at a job during weekday office hours, but not in side projects evenings and weekends. Not if you have a family.
When you love the project, you will be surprised at how well you can progress in 5, 10, 15-minute intervals virtually as if they were a single block of time.
I've returned to half-done code (not even syntactically valid), half-written commit messages, debug sessions, and picked it up without skipping a beat.
I think the interruptions are harmful when you're working on something you don't fully understand. You had to ramp up on it quickly, and to get through the task, you're juggling a whole clump of new, unfamiliar information in your short-term memory --- some of it not even proper information, but unconfirmed, competing hypotheses on how various things work. You have to work hard just to build that up so you can navigate and contextualize what you're doing. Much of that short term information can vaporize if you are interrupted.
But that's not exactly the situation of maker. The maker knows what he or she is making. He or she understands the existing thing, inside out; none of that vaporizes due to an interruption.
So how can someone deal with interruptions who is in this situation? I think: write stuff down! Don't carry it all in your head. Document. Open a "knowledge file" and type. If you have three competing, unconfirmed hypotheses about how something works, write them out. After an interruption, you can reload the context by re-reading that file. If you have a plan about what your next steps are, write those steps down. Write down what you've already tried and the results.
I also once kept the "dinner to 3 am" schedule with 10-4 meetings at Microsoft and it was very effective for everything except my personal life.
I've lived this both as an engineer and a PM. I tried to set aside at least 4 hrs focus time for people that reported to me, no matter their role. Not many others respect those boundaries.
It often manifests as an Agile/Scrum standup at 10AM that balloons into an hour-long status meeting. This effect worsens as people start to treat that meeting as the beginning of the work-day, and increasingly show up later, and more unprepared.
Then, after that meeting completes, there is a brief flurry to handle any follow-ups generated by the morning meetings, and then it is lunch time.
People drag back in from lunch, and maybe handle some responses from their pre-lunch follow-ups, and then it is time for the standing afternoon meeting. Usually this just recapitulates everything that was discussed in the morning, since no one has had any time to actually do anything. By the time it finally wraps up at 4:30 PM, everyone's brains have utterly dissolved, and they go home.
And then it starts again.
8-8:30 I check on all my chats, emails, plan my day
Usually something comes up that I need to address, look at etc...so suddenly it's 9:15-9:30. If I start, 10am will break my flow right when I go deep, if I don't I feel like I wasted 30 minutes.
Then 30m-1hr standup....anything out of the standup affects my 11 to 11:30...but then lunch is starting in 30 minutes. So again at the same problem start and break flow or don't start at all?
Combine that with a 1:30 meeting or something like that I can't do any deep work till 3pm.
What Paul Graham said that resonated with me was WHY he worked late nights...that solitude gave him that focus time.
I'd like to see an org function long term with no managers - I'll bet good money it can't be done.