Getting Things Done Together

Like many people of approximately my generation, I have long been an advocate of David Allen’s famous ‘Getting Things Done‘ methodology. In case you’ve been living in a cave for a couple of decades and haven’t come across ‘GTD’, it was an appealing and genuinely useful system for handling, originally, the ever-growing flood of paperwork that people were experiencing towards the end of the last millennium. Allen was fortunate (or canny) in that most of his book, originally published in 2001, translated very nicely into the emerging predominantly-digital world. He did for filing cabinets and in-trays what Marie Kondo now does for wardrobes and sock drawers.

Over the following couple of decades, many software products sprang up to help you adapt the GTD task-management techniques to your new digital world; the most complete and sophisticated probably being OmniFocus. If you juggle lots of big and complex projects and are really into this stuff, OmniFocus is immensely capable, and I started using it as soon as it was first available as a beta release about 13 years ago. I typically have two or three part-time jobs at any one time, and many projects within each one, and something like OmniFocus can definitely help keep your world manageable especially if, like me, your brain is not one that is naturally drawn to rigorous and careful planning and organisation! In recent months, though, I’ve switched to the rather wonderful ‘Things‘, which is for me the perfect half-way point between a simple to-do list and the all-encompassing and baroque structures I had previously created within OmniFocus.

Anyway, all of this meant that I was very interested when John linked to this New Yorker piece by Cal Newport, talking about the history of GTD and some of its limitations in the current climate. It’s a good read; here are a couple of short extracts:

In this context, the shortcomings of personal-productivity systems like G.T.D. become clear. They don’t directly address the fundamental problem: the insidiously haphazard way that work unfolds at the organizational level. They only help individuals cope with its effects. A highly optimized implementation of G.T.D. might have helped Mann organize the hundreds of tasks that arrived haphazardly in his in-box daily, but it could do nothing to reduce the quantity of these requests.

It seems likely that any successful effort to reform professional life must start by making it easier to figure out who is working on what, and how it’s going. Because so much of our effort in the office now unfolds in rapid exchanges of digital messages, it’s convenient to allow our in-boxes to become an informal repository for everything we need to get done. This strategy, however, obscures many of the worst aspects of overload culture. When I don’t know how much is currently on your plate, it’s easy for me to add one more thing. When I cannot see what my team is up to, I can allow accidental inequities to arise, in which the willing end up overloaded and the unwilling remain happily unbothered.

In a distributed working-from-home world, he argues, techniques like Kanban boards — or the electronic versions encapsulated in products like Trello — can be more appropriate ways to manage tasks when your workforce is distributed. You need to make your to-do list more public, so others in your organisation, and particularly those responsible for managing you, can see what you’re working on and whether you have too much (or too little) on your plate. Software developers have been doing this for years, of course, but it’s interesting to think about how many other kinds of work might benefit from some of our techniques in the Covid age.

My favourite example of a public to-do list, though, probably just predated the publication of GTD, and was not digital, even though I was working in a cutting-edge high-technology lab at the time.

The sysadmins — about four of them, I think — all worked in a shared office, and people like me would wander in and ask them to do things which, of course, always needed to be done immediately if they possibly could. So at one point, they adopted a brilliant scheme.

On the wall outside their office, they put up a big board showing the queue of things that people had asked them to do. If you came in with a request, they’d say ‘Sure! We can do that!’, and hand you a little card. You’d write your name and your request on the card and go and pin it on the board at the bottom of the queue. When one of them finished dealing with the current issue, they’d go and take the next card off the board. If you felt that your card was more important than some of the other ones there, you could try to make the case that the queue should be re-ordered. But if the queue was really long, you sometimes discovered that actually you didn’t need this as much as you thought you did, or perhaps you could sort it out yourself.

It was, of course, just a ticketing system, but run very much on a first-come, first-served basis and, since the tickets were all public, it was one which gave everybody, not just management, a very clear idea of what was going on. I’ve always thought it was brilliant, and something which should be replicated more often in the digital world.

Enjoyed this post? Why not sign up to receive Status-Q in your inbox?

2 Comments

I’ve started using GoodTask which is based on Reminders because I too was wanting something less complex and more based on lists. I liked Things but something about GoodTask is really appealing and it does everything I want it to.

Apart from anything else constantly changing to do list tools is a great displacement activity… 😉

I find Trello and the like to be useful in principle, but commonly abused as a micromanagement tool. If one is working on a regular engineering project, knowing what you’re supposed to be working on, and everyone else knowing what you are supposed to be working on, is fine. Your work may impact others, there will be dependencies not adequately represented in Trello (GANTT/PERT anybody??).

But in a research project, you are often asked to think and come up with a clever way to do something difficult. If it wasn’t novel and difficult, it would not be a research project. But that also means that it is difficult to meaningfully decompose the task, except into ridiculously broad trenches.

So, I have repeatedly found that I have come up with ideas and progressed them, but in my free time, with all the dead-ends, backtracking and retrenching involved – and then ‘donated’ the winning ideas back to the project – simply so that I was doing whatever boring guff the Trello board said I should be doing, at any given moment!

My argument is that overly managing research, stifles hunches, insights and serendipity – and the known requirement to fail and regroup, at times.

Got Something To Say:

Your email address will not be published.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

*

© Copyright Quentin Stafford-Fraser