Tag Archives: work

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.

Boredom, Toothbrushes and Terminals

When I was a child, we were not allowed to be bored. Boredom, my mother insisted, was a sign of laziness and lack of imagination, and nobody fortunate enough to have all their faculties intact should complain of it.

Some of this came, I think, from lessons my grandfather had instilled in her. Some of it may have been because we had just come back from several years in northern Kenya, where kids in extreme poverty who had no toys would just make their own out of sticks and bits of wire, and play happily with them for hours. Who were we, with boxes full of toys, shelves full of books, and minds full of stories, to complain of boredom? (And that was when the Web and YouTube were still decades away. There’s surely no excuse now!)

Anyway, it was a great lesson, and one that’s always stuck with me. I don’t remember ever being bored in my life, though the nearest I’ve come has not been when I’ve nothing to do, but when I’ve had to do some tedious repetitive task for hours on end…

Of toothbrushes and terminals

In my teens, I had a holiday job for a couple of weeks at the local factory where they made Wisdom toothbrushes. The company was changing the prices of the whole stock, and my job was to sit in front of the mainframe terminal and adjust the wholesale price of the blue toothbrush in a particular range from 23.4p to 23.9p, then do the same for the red toothbrush, the pink toothbrush, the yellow, the white… and so on for every colour they made — there were many — after which I would move on to the next range.

The problem was that this involved navigating very slowly through a deep hierarchical menu which was totally unsuited for this purpose. Today, if these were rows in a spreadsheet, it would be done in about 20 minutes. But we didn’t have spreadsheets back then, my lad. Instead, I had to dig about six layers into the keyboard-driven menu system for the particular stock item, make the change, and then exit from each layer to get back to the top before moving onto the next one.

There was no way to bypass these steps, to speed up the process. No way out of the menu. The display, which I think was probably something like the VT220 pictured above, updated very slowly over its slow connection to an overloaded mainframe. This explained why they had to employ me for many days to perform this simple task. It also taught me a lot about user interface design.

However…

It turned out that the terminal wasn’t completely dumb. On one of our tea-breaks — and yes, we really did have a tea-lady who would come through the office with a trolley of clinking cups at the allotted time — I discovered, in the back of a desk drawer, a manual for the terminal.

I found out that it could be programmed through a simple menu to send a set of keystrokes when it was switched on and connected to the mainframe, in order to identify itself, login, or whatever. This facility wasn’t used in our system, but — and this was the moment of enlightenment for me — you could also cause the sequence to be sent at any time by pressing Ctrl-Break! So I could use it as a kind of macro-recording system (not that I would have known of that concept back then).

Once I started on a new range of, say, the Mickey Mouse toothbrushes, I would work out the sequence of keystrokes needed to update one price: enter, right cursor, down, down, down, right, up, 23.9, enter, escape, enter, escape, escape, or whatever, followed by the down arrow to get to the next toothbrush. I’d program that into the terminal’s setup menu and then just hit Ctrl-Break a dozen times and sit back and watch the menu update as fast as the mainframe could manage (which wasn’t very fast).

Later that day, my boss — a great guy — came by and saw me reclining in my chair, reading something. “Having a quiet afternoon, are we, Quentin?”, he asked.

“No, I’m busy”, I explained, and gestured to the screen, where the all-too-familiar menus seemed to be operating themselves at great speed while I sat back and sipped my tea.

I’ll never forget the expression on his face.

However, I guess all such Sorcerer’s Apprentice tales must have a cautionary aspect to them. In my case, the work was finished much sooner, so I was out of a job.

Perhaps there’s a lesson there. In that case, though, I can’t say I was too sorry!

© Copyright Quentin Stafford-Fraser