Cranking widgets: “Getting Things Done” (GTD) as a tech writer

“Getting Things Done”, David Allen’s productivity method, works well for a technical writer who’s lined up tasks, so they’re ready to go and as easy as cranking widgets. Here’s how in my #2 GTD Principle for Tech Writers. (My #1 principle is about universal capture.)

Cranking widgets

Most of us technical writers face two different types of tasks: Deciding what to do – and actually doing it. It’s the second part that David Allen calls “cranking widgets”. It sounds like a mindless activity, but I take it to mean to get down to our craft and actually write. (For a more GTD-like take, try zenhabits’ recipe…)

I believe, and have experienced, that it makes sense to distinguish and to separate those two types of tasks as soon as a task appears. That gives me a slim chance that I’ll even have the time to decide before I actually have to do it.

The benefit is that I get to group similar tasks together and do related work at once, so I don’t have to jump around in the documentation with every single task I get.

The challenge is to juggle the deciding and the doing. Often I don’t have the time to do all the deciding until my inbox is empty and all tasks are neatly laid out and ready to be done.

Deciding before doing

This kind of task often comes disguised as the second type:

  • I get a phone call that asks me to correct something in existing documentation.
  • I receive an email about something that hasn’t been documented yet.
  • I get a request to furnish screenshots for a localized manual.

All these things need to be done eventually. But for efficient and effective documentation, it makes sense to first decide what to do exactly:

  • Is the correction in existing documentation actually legitimate? And if so, when is the best time to do it?
  • Is the missing documentation actually missing, or overdue from the latest release, or really part of a future release? Again, when is the best time to write and provide it?
  • What’s the most efficient way to get the screenshots for localization? Do I have to do those, or can I ask an intern to do them? If I should do them, should I change my process and create them along with the ones in the source language?

How to decide

The reason to keep the deciding apart from the doing is that the first engages me in a very different way. Deciding what to do is mainly thinking, planning and organizing: Is a request legitimate and timely? What do I need to do that? When is the best time to do it? This part is mainly concerned with logistics.

My answer is usually one of those four decisions:

  1. Do it now. This is what I choose for tasks that simply cannot wait and for tasks which don’t take very long. In other words, tasks which get much bigger by looking and deciding a couple of times. The risk is that these tasks take up much of my daily time, but the reward is that they’re in and out fairly quickly.
  2. Defer it to a set deadline. This goes for all requests that come with a deadline, whether it’s explicit or implied, for example, because it’s connected to an upcoming version or release of the documentation. These tasks go onto my to-do-list. You can also put them into your calendar or project plan…
  3. Defer it to sometime later. This is for everything that’s currently out of scope or merely nice to have. It goes on to a wish list.
  4. Delegate it. This is frequently wishful thinking, because most of the time I don’t have anyone to delegate to… 🙂 But occasionally, I get lucky and can ask an intern to take those screenshots… After I delegate the task, I’ll have to make sure to follow up, especially when it’s got a deadline.

Doing after deciding

Once I have sorted out (hopefully most of) my tasks, I can set about doing them, starting with the most urgent ones, but taking all the related ones together. I’m cranking widgets and, if I’m lucky, I might get into the flow.

Your turn

Does arranging your tasks work for you? Or do you have your work arranged for you? Or do you simply not have the time to even bother? Feel free to leave a comment.

Advertisements

4 Responses

  1. For implementing GTD you can use this web-based application:

    Gtdagenda.com

    You can use it to manage your goals, projects and tasks, set next actions and contexts, use checklists, schedules and a calendar.
    Comes with a mobile version too, and with an Android app.

    • Thanks, Dan. I’m afraid that the app you recommend is a bit too GTD-literal for my needs. Does it also work as a task list with a slight GTD flavor?

  2. This part hit me:

    Deciding before doing
    This kind of task often comes disguised as the second type…

    When I am in this spot, I do what I previously called “pushing back”, i.e. asking the questions that you list. I often think I sound like a nag! Now I can tell people that I am merely doing the sensible thing. I have to put the task in perspective so that I can deal with it in the most efficient manner.

    Because it is disguised, as you write, I have felt guilty pushing back, yet I feel I must ask those questions. You have removed my guilt feeling! Thanks! 🙂

    • You’re welcome, Karen… 🙂 Yes, it took me a while to get out of the “unconditional helper” mode that is a natural for many writers. But in fact, most people who request changes or additions on the documentation don’t know how documentation is best written…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: