Here’s the challenge: write valuable notes for 30+ one hour 1–1 meetings a month. And very importantly, have a life and time for more than just writing notes!
How could that possibly be relevant to you? That’s a totally reasonable question. The addressable market for this specific challenge has to be tiny. Bear with me though. While you may not have this particular problem I’m hoping it has structural similarities to problems you do have and is therefore helpful to you.
For example does your day contain a mix of shallow and deep work? Do you feel like you’re unable to keep up with the deep work? Are you looking for ways to be more productive in this type of mixed work environment? If so read on!
For this challenge I’m defining deep work as work that requires full concentration and is best done with an uninterrupted period of time. Shallow work on the other hand is easier and can be done in shorter spurts. For those familiar with Cal Newport’s Deep Work these definitions are slightly different but they work better in this context.
Let’s get back to the notes challenge. My 1–1 meetings are with Software Engineering managers and for each meeting I write detailed notes that I send to them and sometimes also to their manager. Writing the notes is deep work for me. For some reason that I can’t logically explain the prospect of starting or continuing a set of notes when I only have 15–30 mins available feels daunting.
During the meetings I write shorthand notes by hand on my iPad (love Notability and the Apple pencil), and I record the audio for reasons that will be clear soon. On a typical busy day I’ll have three meetings with an hour free between each one. I need that full hour to get into deep work. With only an hour in between meetings you can see how fragile my schedule is. Any interruption (e.g. lunch, an unexpected meeting, or coffee break) and I don’t have enough time for deep work. I end up doing other shallow work and putting off the deep work until later.
What happens when my schedule breaks down? After a single day I may end up with two sets of unwritten notes. After a week I might be six sets of notes behind. Writing the notes from memory takes me 1–2 hours. But if I’m unable to do it from memory I need to listen to the audio and a 1–2 hour process can become a 3–4 hour process! If I’m six meetings behind that’s a lot of work.
What are some better ways to do this? Certainly I can work harder, change my schedule, have fewer meetings, or write quicker notes. All of those have merit. It’s pretty clear that having to re-listen to the meetings is super inefficient so I asked myself if there was a way to consistently avoid it. I pulled from various sources and came up with a plan using these ideas:
- Shallow and deep work
- Scheduling time based on the amount of time available and type of work
- Spaced repetition
- The Pareto principle (80/20 rule)
- Getting clear on the value add and priorities
Here’s how I use each one:
- Define the shallow and deep work. The deep work is transcribing handwritten informal notes into more organized formal notes. The shallow work is filling out my shorthand notes from the meetings with informal handwritten notes and flushing out the valuable content. Also in the shallow work pool is editing the formal notes.
- Scheduling. I explicitly schedule time for writing notes in my calendar. For the deep work I schedule at least an hour. The most critical change is that if I’m unable to write the formal notes right after the meeting I schedule time for shallow work to prep for the deep work! During this prep step I review my shorthand notes from the meeting, I highlight the points that are worth transcribing, and I create an outline for the formal notes.
- Spaced repetition. I use an imprecise implementation of spaced repetition to avoid having to listen to the recordings. I review my notes at varying intervals before writing the formal notes. As an example I will do the prep after the meeting (usually 15–30 minutes), that night I might look at the notes for 5 minutes, and a day or two later I might spend another 5–15 minutes reviewing them. In those subsequent reviews I’ll re-read and do some editing. When it comes time to transcribe the formal notes I can do it based on my informal notes and memory.
- Pareto principle. I don’t try to capture every single thing from the meeting. My goal is not to be perfect but to write valuable notes relatively efficiently. Even if I miss some valuable or interesting content that’s okay as long as I convey the most valuable info.
- Priorities. Related to the Pareto principle at the beginning of the prep step I write down this question: What’s most important here? I try to focus on that in the prep and review sessions.
Applying the strategy to a different domain
You may still be wondering how this applies to you. Let’s use a software engineering example to apply the same strategy to a different problem. Let’s say that you’re working on a challenging programming project and you’re a senior engineer and/or manager. You have plenty of meetings and interruptions that make it hard to focus on your coding. What could you do?
- Define the shallow and deep work. Identify shallow work that supports your deep work (programming). For example setting up your build/environment, emailing with PMs, or even writing some of the boilerplate or straightforward code/tests.
- Scheduling. Accept that to do your best coding you’re going to need 1–2 hours of uninterrupted time. Look at your calendar, find a block that works and block it off. Use the shorter blocks in your calendar for the shallow work. When that deep work comes, protect it! Find an office, go home, or a quiet spot in the office. Turn off your email/chat, put your phone away and get to work!
- Spaced repetition. Use spaced repetition to keep the work fresh in your mind between deep work sessions. Write down or edit some notes. Draw some diagrams to make it visual. Look at the code itself and write comments for yourself, or just think about it. The goal is to minimize the cost of context switching so you can get into your deep work sessions more efficiently. As a bonus your sub-conscious will probably keep working on the problem which may lead to some ah-ha moments.
- Pareto principle and priorities. Spend some time thinking about what you’re trying to accomplish and what is most important for this code to do. We all want to write beautiful high-quality code and we should aim for high-quality work, but do you really need that last feature or need to refactor that entire module? Use the 80/20 rule and realize when you’ve done enough for now.
This is an example of the strategy applied to two very different problems. The jury is still out on my productivity challenge, but what I’ve learned from it has been helpful. When faced with a difficult problem one option is to put your head down and work harder. Another is to pause, take a step back and look for a better approach. I hope this inspires you to search for the key that will unlock your own productivity challenge. Good luck!