Podcast: Dealing with Project Overload -- Strategies to Manage Overflowing Documentation Tasks
Listen here:
I was reading a post on the technical writing sub-Reddit community about dealing with project overload and thought it would be a good topic for a podcast. The Reddit post is In over my head - service docs, user docs, and localization (requesting advice). In part, the topic resonated with me because I’m sort of overloaded myself right now, so I thought it would be good to think through some of these challenges.
In the post, “keyboardqueen90” describes how she’s buried in work, her manager doesn’t understand what she does, others underestimate the time required to write docs, requests for more support fall on deaf ears, she doesn’t have time to ramp up on tools/tech or influence design because the docs fully occupy her time, she lacks any champion or advocate at the leadership level, she’s a team of one, and more.
My podcast is short, but here’s an even shorter summary. To manage incoming work, especially when it’s spilling over, you need a system or framework. Kanban is one system that attempts to manage flow by limiting the number of incoming items by a fixed amount. This approach seems sensible but doesn’t entirely work for tech docs because not every task is equal nor requires equal time.
Scrum, an agile methodology used by engineers for much the same purpose here, is a more common framework for managing the flow of tasks. I described the process for managing tech docs with Scrum in Following Scrum with documentation projects. In short, with Scrum you start by prioritizing the most important items in your backlog. You assign some of the items to a two-week sprint. You assign only as many items as your sprint capacity can handle. In your sprints, try to mix in some “quick win” tasks that are easy to accomplish (because they take an hour or less) but which might not be high-priority.
When people scream at you for docs with deadlines the next day, tell them you’ve assigned the work to an upcoming sprint. This usually appeases them because they know the work has been scheduled. When people realize you have a framework for managing tasks (one that aligns with engineering frameworks), they tend to be more understanding about pushing out timelines.
Another consideration, outside of scrum or agile, is to consider flow. If you’re constantly jumping from one task to another, you can’t get into any state of flow with a project, and your efficiency will plummet. I try to devote several days or a week to a single project before switching over to another one. I mentioned some strategies related to context switching in How to avoid inefficiencies even with context switching.
If you’re working on a project that you don’t have sufficient time to ramp up on (for example, it requires you to know X technology, but to learn X technology you’d have to spend a week doing tutorials, which would be fine except that the docs for X are due in two days), you can try this simple workaround: Meet with the engineer and ask him or her to explain and demo the task. Record the meeting. Then basically type out the content by listening and re-listening to the recording, shaping and editing it, and then have the engineer review it. Even if many of the details are still murky in your mind and untested, it might be a feasible solution to avoid derailing your focus on the projects that matter to you.
Finally, if your mind is tied up with anxiety and can’t focus due to the stress, check out the Calm Meditation app. I’ve done a number of 10-minute meditations here that put me in a more relaxed state, which is kind of essential for entering the more productive mental mindset for writing. For more on this, see this post on Medium: My system for managing overwhelm, anxiety, and stress when work is too difficult.
If you have advice for the situation, consider adding it to the comments on the Reddit post, or you can also add them below.
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.