It’s late Friday afternoon. You are sitting in your office, exhausted and frustrated. The week could not have been worse. The project is a mess, the team is in disarray and the VP is breathing down your neck. You have fought off about a dozen fires since morning. You almost had a fist-fight with that marketing ‘dude’. You are not even thinking about the upcoming conversation with the VP. The weekend is ruined. The best you can do to soothe yourself is by believing that its just one of those days (though you think there have been too many of them lately).
There was a knock at the door.
It’s Neville (hint: inspiration from Harry Potter series).
Gosh, no. With Neville, you know its trouble. The expressions on his face do not suggest otherwise.
“Boss, we have a problem”.
“I am listening”.
“I have been trying to get this fixed by myself for past 3 days, hoping it will go away. I fear that we have hit a hard rock. Our credit card processing system for the upcoming launch is completely broken. We do not have a solution.”
So only when you thought your day could not get worse, Neville proved you wrong.
What would you do?
Earlier I argued why GTD is valuable for knowledge workers and what my GTD system is. Here is how I do my Weekly Review – a critical piece of the GTD system.
All processes in life run forward. Good processes also have intermediary checkpoints where progress is analyzed and adjustments are made. (e.g. A Scrum project team does retrospectives at the end of every work iteration – where the good, the bad and the potential pitfalls ahead are reviewed and course corrected).
Weekly Review is just that. It is an explicit weekly checkpoint in our GTD life where we deliberately stop doing the regular stuff, rise up from the life’s battlefield, take a stock of all the stuff around us, analyze the previous week and look ahead the next. We adjust, tweak and re-prioritize and take away or add stuff in our lives. It’s an ‘inspect and adapt’ activity – and is immensely powerful.
As important as the review, is the fact that it is weekly. A week is the optimal work and planning unit. Give someone two weeks for a task and it will be most likely addressed in the second week. Hence, most planning and reporting is done on a weekly basis.
My Weekly Reviews are on Friday afternoons. It’s scheduled for 30 minutes on my calendar. Friday is a good time with work traffic slowing down and I have better visibility into the weekend and next week.
Last time I talked about GTD and why it helps a knowledge worker. Today, I’ll describe how I personally manage the GTD system – the tools, habits and the quirks.
Disclaimer: How I manage is what works for me. It may not be the same for you. The intent is to give you example of an implementation. The process is more important than the content. Had there been a one-size-fits-all implementation, GTD probably would have prescribed it.
I use electronic tools and external (cloud) storage of data (tasks, emails, documents etc.) for efficient access. My system has the following pieces:
– My Capture Lists
Once asked for his telephone number, Einstein looked it up in the directory. He replied to the curious requester that why should he waste his brain in storing something when he can easily retrieve it when required.
This is the essence of Getting Things Done (GTD) methodology – which I and million others use to organize our lives.
GTD is not a productivity tool. It is a methodology to manage stuff entering in our lives and how we manage it.
Most of what we call organizing consists of creating to-do lists and reminders. We are typically creating these artifacts with no process to manage and use them. The result is often “we forgot”, “it fell through the cracks” or “I never got around to doing it”. There is stress, inefficiency and lost opportunities.
Our brain is for processing, not storing stuff. We cannot depend on our memory to generate reminders or organize large information. At best, we can hold a few items in our brain at anytime. Enter a new input and an existing item may drop off. Our psyche cannot be our system.
On the field of battle, the spoken word does not carry far enough: hence the institution of gongs and drums. Nor can ordinary objects be seen clearly enough: hence the institution of banners and flags.
Gongs and drums, banners and flags, are means whereby the ears and eyes of the host may be focused on one particular point.
In night-fighting, then, make much use of signal-fires and drums, and in fighting by day, of flags and banners, as a means of influencing the ears and eyes of your army.
— Sun Tzu (The Art of War)
This has to be one of the most profound lessons from the great book – not only militarily but also for managers in knowledge organizations. Simply put: you cannot communicate by ordinary means in extra-ordinary circumstances. You have to use stronger and more forceful tools to get your message across the battle chaos.
In theatre in front of live audience, the gestures and motions of the actors on stage are louder and exaggerated – for example, they will move their hands in a wider area around their body. They will speak louder too. Even their facial makeups are more pronounced. This is to ensure that their emotions, gestures and words communicate effectively to the audience in a setting which is more challenging and demanding.
Remember, Communication is what the listener does?
This is a guest post I wrote for Knowledge Tester blog – an excellent repository of insights into today’s knowledge tester world. The author, Majd is a close friend and ex-colleague. We both had the privilege to work together for a great group of knowledge workers. The article appeared here and I am reproducing it for Thinking Spirits audience.
In early days, life was simple. If you got sick, you would simply go to the ‘doctor’ who could treat your eyes, fix your stomach, amputate your leg and give you a diet plan. Specialization was unheard of. The patients, their diseases and expectations were simple. The medical knowledge was limited.
With time and progress, as man and his endeavors became complex, so did the medical profession. Specialists sprouted and the knowledge base expanded. The poor old doctor was replaced with hordes of specialists.
Software evolved in a similar way, albeit in a shorter span. Early software would be written by the engineer who could do everything from designing, coding, testing and deploying. There was neither need nor capacity for specialization. Time and progress, however, demanded specialization – the architect, programmer, usability designer, tester, deployment engineer and so forth. The process is recursive. In a tester’s world, automation, performance testing, penetration testing, usability testing and many others are becoming specializations of their own.
This progressive specializations has flourished – and complicated – the “Knowledge Testing” world.