What do you think about deep work (here’s a semi-arbitrarily-chosen explainer)? I suppose the Monday time block after the meeting lets you do that, but that’s maybe <10% of the workweek; you also did mention “If people want to focus deeply for a while, they can put on headphones”. That said, many of your points aren’t conducive to deep work (e.g. “If you need to be unblocked by someone, the fastest way is to just go to their desk and ask them in person” interrupts the other person’s deep work block, same with “use a real-time chat platform like Slack to communicate and add all team members to all channels relevant to the team”, and “if one of your teammates messages you directly, or if someone @ tags you, you want to respond basically immediately”).
I’ve always wondered about this, given my experience working at a few young-ish high-growth top-of-industry companies—I always hated the constant interruption but couldn’t deny how much faster everything moved; that said I mostly did deep work well after office hours (so a workweek would basically be 40 hours of getting interrupted to death followed by 20-30 hours of deep work + backlog-clearing), as did ~everyone else.
At least speaking from my experience, one of the default ways the Lightcone campus team gets deep-work done is by working in pairs. I also think we would structure things probably somewhat differently if we were doing more engineering or math work (e.g. the LessWrong team tends to be somewhat less interrupt driven).
I’ve found that by working in pairs with someone, I end up with a lot more robustness to losing context for a minute or two, and often get to expand my metacognition, while still getting a lot of the benefits of deep work. It doesn’t work for everything (for example, I have a really hard time co-writing long pieces of text with someone), but it works pretty well for other things (like programming, planning, preparing talks, legal work).
The lame answer: yeah, it does mess with deep work, and I’m not super sure how to balance them.
The spicy answer: I have an unwritten polemic entitled “Against Deep Work”. I can’t share it though since I have not written it. Fortunately, much of what I hope to say in that post is captured in Chapter 9 of the Lean Startup, which has a section that resonates a lot with my experience. I’ll just go ahead and quote it because it’s so damn good (starting on page 191 in the linked PDF).
Imagine you’re a product designer overseeing a new product and you need to produce thirty individual design drawings. It probably seems that the most efficient way to work is in seclusion, by yourself, producing the designs one by one. Then, when you’re done with all of them, you pass the drawings on to the engineering team and let them work. In other words, you work in large batches.
From the point of view of individual efficiency, working in large batches makes sense. It also has other benefits: it promotes skill building, makes it easier to hold individual contributors accountable, and, most important, allows experts to work without interruption. At least that’s the theory. Unfortunately, reality seldom works out that way.
Consider our hypothetical example. After passing thirty design drawings to engineering, the designer is free to turn his or her attention to the next project. But remember the problems that came up during the envelope-stuffing exercise. What happens when engineering has questions about how the drawings are supposed to work? What if some of the drawings are unclear? What if something goes wrong when engineering attempts to use the drawings?
These problems inevitably turn into interruptions for the designer, and now those interruptions are interfering with the next large batch the designer is supposed to be working on. If the drawings need to be redone, the engineers may become idle while they wait for the rework to be completed. If the designer is not available, the engineers may have to redo the designs themselves. This is why so few products are actually built the way they are designed.
When I work with product managers and designers in companies that use large batches, I often discover that they have to redo their work five or six times for every release. One product manager I worked with was so inundated with interruptions that he took to coming into the office in the middle of the night so that he could work uninterrupted. When I suggested that he try switching the work process from large-batch to single-piece flow, he refused— because that would be inefficient! So strong is the instinct to work in large batches, that even when a large-batch system is malfunctioning, we have a tendency to blame ourselves.
Large batches tend to grow over time. Because moving the batch forward often results in additional work, rework, delays, and interruptions, everyone has an incentive to do work in ever-larger batches, trying to minimize this overhead. This is called the large batch death spiral because, unlike in manufacturing, there are no physical limits on the maximum size of a batch. It is possible for batch size to keep growing and growing. Eventually, one batch will become the highest-priority project, a “bet the company” new version of the product, because the company has taken such a long time since the last release. But now the managers are incentivized to increase batch size rather than ship the product. In light of how long the product has been in development, why not fix one more bug or add one more feature? Who really wants to be the manager who risked the success of this huge release by failing to address a potentially critical flaw?
Overall I think deep work is sometimes important. But other times it’s just a symptom that you’re in a large batch death spiral; and changes that enable you to have more deep work will also trap the organisation harder in the death spiral.
I lead the LessWrong team within Lightcone (the “other” team) and I care a lot about protecting deep work time from interruptions. Though in practice due to the structure of the team (3 of us, usually 2 out 3 pairing), there’s not that much blocking arising. As team lead, I’m the one moost likely to be a blocker and I end up kind of in the pattern you describe of doing deep work outside of regular hours so I’m available during.
I’m not sure if there’s a better way if you’re trying to get a lot done.
What do you think about deep work (here’s a semi-arbitrarily-chosen explainer)? I suppose the Monday time block after the meeting lets you do that, but that’s maybe <10% of the workweek; you also did mention “If people want to focus deeply for a while, they can put on headphones”. That said, many of your points aren’t conducive to deep work (e.g. “If you need to be unblocked by someone, the fastest way is to just go to their desk and ask them in person” interrupts the other person’s deep work block, same with “use a real-time chat platform like Slack to communicate and add all team members to all channels relevant to the team”, and “if one of your teammates messages you directly, or if someone @ tags you, you want to respond basically immediately”).
I’ve always wondered about this, given my experience working at a few young-ish high-growth top-of-industry companies—I always hated the constant interruption but couldn’t deny how much faster everything moved; that said I mostly did deep work well after office hours (so a workweek would basically be 40 hours of getting interrupted to death followed by 20-30 hours of deep work + backlog-clearing), as did ~everyone else.
At least speaking from my experience, one of the default ways the Lightcone campus team gets deep-work done is by working in pairs. I also think we would structure things probably somewhat differently if we were doing more engineering or math work (e.g. the LessWrong team tends to be somewhat less interrupt driven).
I’ve found that by working in pairs with someone, I end up with a lot more robustness to losing context for a minute or two, and often get to expand my metacognition, while still getting a lot of the benefits of deep work. It doesn’t work for everything (for example, I have a really hard time co-writing long pieces of text with someone), but it works pretty well for other things (like programming, planning, preparing talks, legal work).
The lame answer: yeah, it does mess with deep work, and I’m not super sure how to balance them.
The spicy answer: I have an unwritten polemic entitled “Against Deep Work”. I can’t share it though since I have not written it. Fortunately, much of what I hope to say in that post is captured in Chapter 9 of the Lean Startup, which has a section that resonates a lot with my experience. I’ll just go ahead and quote it because it’s so damn good (starting on page 191 in the linked PDF).
Overall I think deep work is sometimes important. But other times it’s just a symptom that you’re in a large batch death spiral; and changes that enable you to have more deep work will also trap the organisation harder in the death spiral.
I lead the LessWrong team within Lightcone (the “other” team) and I care a lot about protecting deep work time from interruptions. Though in practice due to the structure of the team (3 of us, usually 2 out 3 pairing), there’s not that much blocking arising. As team lead, I’m the one moost likely to be a blocker and I end up kind of in the pattern you describe of doing deep work outside of regular hours so I’m available during.
I’m not sure if there’s a better way if you’re trying to get a lot done.