I want to explain why learning GTD is such an important skill for developers. Any time management you can do is going to be improve you, there’s no doubt about that. No developer should be without a way of planning their work, and GTD is the best way I’ve found to date.

Yet trying to explain it to people in the past, the arguments against it are that it’s too convoluted, inefficient, overkill or unwieldy.  I’d argue precisely the opposite, that once you get up to speed with it, you’ll find the speed at which you can sort your work and clear your head is anything but clunky. For developers, I think GTD, is the best choice because you have a system already laid out.

So why should developers care about GTD?

Based on the explanation from David Allen himself and my own experience, I’d say GTD is a way of:

Managing your commitments

  • Ever missed important meeting prep because you were fire-fighting something else? GTD can help you see the the ‘woods for the trees’.
  • Struggling to make sense of everything that’s on your plate? GTD will give you clarity.
  • Going round in circles, unsure of how to break something down? GTD can help you again.

Having ideas, not holding them

More than one productivity expert would say the idea of a ‘second brain’ is vital in the ‘Knowledge Worker’ age. GTD offloads all of the ‘what I have to do‘ and the ‘when I have to do’. More specifically, once you’ve determined the above, you don’t constantly fret about it. You have a trusted place to go back and review at any time you need to feel you’re across everything.

Being appropriately engaged

Ever been at a meeting and then remembered you forgot to ask all of the questions you need? Ever had thoughts from work buzzing around your head at home, or had home errands distract you at work? Your ‘second brain’ can help alleviate this.

Handle ‘getting attacked from all fronts’

GTD for developers - how to not get attacked on all fronts

Photo by Quino Al on Unsplash

For a start, I think we’re our own worst enemy. We distract ourselves so easily when we procrastinate and lose our thread. That’s without including:

  • Context switching – something often forced on us by changing priorities and collaboration with co-workers
  • The fact that we get inputs from email, Instant Messaging, SMS, face to face conversations
  • Our brain gives us random, unrelated ideas at an inappropriate time that we might not want to lose
  • Our brain gives us relevant, really great ideas that we really don’t want to lose either.

GTD lets us take all of these, and streamline them in a uniform way.

What is GTD not?

It’s worth being clear on what GTD cannot do so as not to misrepresent it. It won’t let you:

  • Stop you making ridiculous commitments (I wish).
  • Magically make more hours in the day (My wife wishes on our behalf).
  • Make you better at prioritising the most important work first (You’re still a decision making machine after all).

There are many debates about things like ‘Efficiency vs Effectiveness’,  that treating every input equally like GTD does is not the best way to prioritise. I personally think that’s missing the point. I think of GTD as complementary to Agile techniques and I think of GTD as the weapon of choice once we’ve decided on our work.

So how can a developer use GTD then?

I’ve linked to a workflow of the process to explain the high level concepts. I’d suggest reading through that first and then give a more specific guide. Finally, this next article shows how a 2 week sprint can be brought under control using GTD.