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.