Assumed Audience: people already persuaded of the value—at least to some extent—of “getting things done” strategies.

One of the things I’ve found over the last couple months is that my calendar is increasingly full—full of meetings with this person or that team. This is not unexpected in an organization as large as LinkedIn, and I had a feeling I’d probably run into this as I transitioned from new guy on the block to someone whose expertise people want. That it’s happening means I’m doing my job: I am in a leadership role, and my team’s customers are other developers! It’s important for me to be a resource to other people.

However, I am not a manager, and have no desire to be a manager. That means that it’s also important that I not only be a resource to other people. I also need to continue doing technical work myself, and indeed growing technically myself. It’s impossible to do that when each day is punctuated by anywhere between 2 and 8 meetings, often in no particular arrangement. Building software well, like most other non-managerial work, requires time to think and sustained attention to a specific problem.

This week was the tipping point for me. I’ve had multiple meetings every single day, and no sustained blocks for working except in the early morning before any colleagues were working.¹ My progress on a feature I’m implementing has been predictably slow as a result. While many of the meetings I have had were somewhat or even very valuable, many others were in the dread urgent-but-not-important bucket. Even for relatively straightforward programming tasks, half-hour blocks with meetings in between just won’t do it.²

My solution is one I’ve employed before when similarly starting to get over-busy: book myself.³ People check my calendar to see when I’m available for meetings, so I have simply blocked out large stretches of my time under the heading Getting Things Done. I left open a few hours each day for people to book meetings with me—remember: it’s part of my job to help others, too!—and of course I have recurring team and project meetings. But outside of those, I now have time allocated to do the hard technical work I was hired to do.

When someone wants to book a meeting with me, there are times available to them. Importantly, they’re in times of day when I know from experience that I won’t be effective on hard technical work anyway. And if someone ever complains that I’m not really busy in those slots I have booked, I’ll remind them that in fact I am busy: busy doing the other parts of the job for which I was hired!

I encourage you to do the same. Use your calendar’s tools to carve out time for things that are genuinely important—not just what others think is urgent. Make space for deep work.

---

1. I tend to start my day early and then slot my workout into the middle of the day; I’m not working extra-long days or any such nonsense.↩

2. You might be curious how that maps to my habit of doing pomodoro sessions. The difference is that 25 minutes of hard thinking with 5 minutes of mental rest and then diving back in for another session enables deep thought for sustained periods. They allow me to keep pushing on a problem without hitting a mental wall. From experience, I can say that a 5-minute break—especially if I’m walking!—does not cause me to lose context, but in fact simply re-energizes me and often provides new insights into the problem. By contrast, 30-minute blocks interrupted by 30 minutes or more of meetings mean I lose all my working memory and therefore context. 5 minutes is very different from 30, and a meeting is not a walk! What’s more: meetings are very rarely generative of insights into problems I’m working on (unless they’re about that problem).↩

3. In a healthier culture, like the one the folks at Basecamp have built, this might not be quite as necessary. Certainly I think our culture could improve in the direction of defaulting to how Basecamp does things calendar-wise. But also: Basecamp has 50 employees; there are more engineers than that on the app my team supports! Some of these dynamics are simply a matter of scale. If you want to argue that no company should ever be the size of LinkedIn, of course, that’s a possible solution. As much as I share a hostility to scale-for-scale’s sake, though, I also think there can be something good in large groups of people collaborating to do something far bigger than a small group can accomplish. There are goods in both of these approaches. There are also negatives. The key, in this broken world, is learning to encourage the goods and minimize the negatives.↩