Writing productivity tip: Focus sessions
- Session length
- Timer software
- What counts as writing
- Keeping glue tasks in check
- Other concerns become smaller
I recorded a short videocast for this post:
Or if you prefer the audio only:
Listen here:
Session length
I found that four hours, divided into one-hour sessions, is about perfect, and it keeps me much more on track. Ideally, for each focus session, I should turn off email and chat clients for the duration of the focus session. If I really want to focus and get in the zone, I’ll sometimes do that. However, I tend to leave email and chat on. If I find myself getting drawn into some other task, I just stop the session timer. The presence of the timer reminds me of my task and helps me focus even if I’m temporarily pulled over into other threads and errands.
Timer software
I use a macOS app called Focus - Time Management for my timer. It works fairly well, but there are dozens of other timers to choose from, including non-app timers as well (e.g., a stopwatch). However, the computer app works well because it appears on my screen in a more prominent way. When I see it counting down, it reminds me to stay on task. It also lets me customize the duration and number of the focus sessions.
What counts as writing
I consider writing to include any activity geared towards finishing a writing task. This could involve tasks such as reading design documents, interfacing with engineers, experimenting with a sample app, or even going through an e-learning course to learn more about some essential aspect related to the feature you’re documenting. As long as these supporting activities are necessary for you to complete a particular writing task, they should be considered part of the writing process. (Otherwise, writing is basically typing.)
What wouldn’t be considered “writing”? Some examples might be calendar planning, general meetings, internal team documentation, reviewing and responding to email, attending standups, reviewing candidate writing samples, renewing software licenses, fixing computer issues, conducting peer reviews, adding to the style guide, and such. Exactly what is and isn’t writing isn’t always clear, but the gist of this technique is that the task should be necessary for you to complete the specific writing task. If the meeting, email, and peer reviews are all focused on the writing task, then I would consider that writing.
Keeping glue tasks in check
One reason I like the four-hour time is that it helps keep time spent on “glue tasks” in check. For more about glue, see Being glue by Tanya Reilly. Tanya describes how engineers, who are usually expected to write code, are often derailed into many supporting non-coding tasks that are important but for which they receive little recognition. These tasks are glue in that they hold a team together, but glue alone doesn’t seem all that exciting. Some sample glue tasks are as follows:
- Setting up team meetings
- Establishing coding standards
- Improving team processes
- Mentoring & coaching
- Improving onboarding
Tanya found she was excellent at doing these glue tasks, but they detracted from her coding time. Her calendar started to fill up with glue:
With a calendar like this, how do you find time to code? And if you don’t have significant code that you’re pushing out, how are you valued, recognized, and promoted?
Her advice is that if these glue tasks count towards your promotion or otherwise fit into your career trajectory, great, keep doing them. But if spending time on glue tasks removes your time from coding, and all management cares about is the code you push out, then consider cutting back on glue.
I think that focusing half my day on writing tasks helps me keep an appropriate balance between important tasks versus glue tasks. (Also, this whole metaphor about glue being potentially less important assumes your role is an individual contributor rather than a manager. Many of the more promotion-worthy tasks ironically tend to require non-writing projects, but this discussion is veering off into another direction. Let’s go back to focus sessions.)
Other concerns become smaller
I noticed that if I can knock out a lot of writing tasks, other issues no longer become issues. For example, I might not need to spend extra meetings trying to prioritize my project load, push out timelines, decide where to cut corners, respond to email crises about the status of docs, and such.
Also, many times writing tasks take less time than I think. I often have doc tasks that I procrastinate and push off, but when I finally sit down to do them, the task only takes a couple of hours. Afterwards, I think, why did I wait so long to do this? It wasn’t so bad.
It’s like staring at the weeds in yard. I’ve been looking at the weeds for several weeks now, procrastinating the work and pushing it off, and feeling embarrassed by the state of my lawn. Yesterday I finally went out there to weed it, and after a couple of hours, I had mostly cut down the jungle. Writing is often like that — a lot of build-up for a task that ultimately doesn’t take that long.
Do you have any writing productivity tips? If so, feel free to share them below. Also note that this technique about focus sessions ties into a larger technique called the Pomodoro Technique. If you haven’t heard of this technique, check it out sometime. It’s a good way to break up a tedious task into more approachable chunks.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.