TFN#57: 🪜The key skill in Getting Things Done (GTD)

Reader, sometimes you look at your work and wonder why it isn’t moving at a fast pace. Your team and you might be giving your best and still, you can’t get things done.​
These things could be anything:

• Data analysis reports
• Software development
• Teacher training
• Student assessments
• Data collection
• Project launch
• Organizing a retreat
  Even non-knowledge work can also be covered, but we will limit our letter to knowledge work.

Before that, sharing a movie clip from my favourite 1994 classic Pulp Fiction. In this 9-minute clip, you will see the character Winston Wolf who is known to solve problems. He has 40 minutes to clean a blood-dripping car and a corpse. You can see Wolf identifying all the limiting factors, removing those factors and and getting things done. 😄

While writing this piece, I learned that David Allen coined the GTD term in a book with the same name and he’s kind of the productivity guru as I understand.
But.
But.

But I’m not interested in productivity

I’m talking about the natural expectation of getting any work done.
For example, if I were to run a 2-day teacher training program for 30 teachers, I expect the material to be ready in less than a week. Not more. It is not a productivity issue, it is a work-related issue.​
See, we can think about productivity after the work starts getting done as per expectation. But if the work chain is broken, there is no point in thinking about productivity.

The key skill

Identifying and addressing the limiting factors. That’s the key skill.
If you think about it, if your work is mostly delayed—albeit, completed in quality, that means the team doesn’t have competency issues. But there might be steps that are causing trouble. These steps LIMIT the pace of work. Identifying and addressing these limiting steps is one of the key skills in getting things done.

Let’s take an example

Suppose you run an HR team. Your team submits procurement requests through ERP software on a rolling basis. The requests are reviewed by 2-3 people. Upon approval, the procurement is done.
For example, the team submits a request for some stationery items for new joiners. And the way approvals work, it would take a week or more to get the approval and the stationery items.
All of this, when the vendor has a ready stock!

So, should we remove accountability?

From the approval example, it may seem that I’m suggesting removing approvals and associated accountability. But that is not correct.
I’m suggesting that by analysing which part of the process is causing the delay, we can optimize it.
In our example, if the approvals are taking time, there might be reasons:

• The request lacks context, specific need and timeline
• The approver has nothing to do with the request and she doesn’t understand its importance
  Whatever the case, limiting factors are always present.

Identifying and addressing them directly is a key skill in getting things done.

So, addressing the limiting factors helps us make people accountable. Not less.

In any case, what other skills do you think are important to get things done? Have you seen anything similar playing out in your work?
​Hit Reply and tell me.

If you enjoy these letters, go ahead and share them with your colleagues and friends.

Reads of the week:

Last week, I came across this resonating vision of barefoot software developers and truly “local-first” solutions.

Instead of aiming for a million users, aim to serve a dozen. And serving them with whole heart, by understanding their problems. Now, you will think every software company tries to do just that.

But there’s a huge chasm between what local problems need and what the Silicon Valley companies provide—and mind well, the intentions of those sitting in the Bay Area are to help. But there’s a limitation: local context.

Take, for example, developing a software solution for a local school in India. A US-based UX designer will try his/her best to get in the shoes of the user by asking questions. The real gap is in the things that are left unsaid because they were not asked. And the designer also doesn’t know that s/he such a use case is possible. For example, they may not be able to factor in the unsaid amount of vacation days the students might take because of some local festival.

That’s why we need “barefoot developers”. Developers who live within the community, understand their pains, and language, and imagine multiple scenarios.

Since I have been helping small Indian organizations develop solutions with a dozen users, this vision resonated with me.

I hope you too enjoy this read by Maggie Appleton.