Some Live situations during my work day:
- Sir, Can you help me compose a reply for the ticket raised by MKS
- Ring, Ring (phone call), Hello, Sunil, I need your intervention with a ticket I raised regarding my server’s performance
- Sunil, I have a prospect on call and he is asking a highly technical question, can I just hand you phone to address his query.
- Sir, our outgoing relay IP has been blacklisted!
- Sir, you are scheduled to take a telephonic interview now.
- Sir, when can you finish that blog you promised, I need to post it on our SM sites
- Blip, Blip (chat alert), Sunil, can you give me those projection numbers for April
- Blip, Blip (chat alert), The deployment in Guwahati is stuck and I need to review further course of action
… and this goes on until I go home ( and sometimes beyond).
On a couple of days I measured these “interruptions” and found them to be in the range of 20-25. I am not counting my more than 100 mail a day which I need to attend to.
Flitting by a dictionary definition means:
1. To move about rapidly and nimbly.
2. To move quickly from one condition or location to another.
3. A fluttering or darting movement.
Going by the definition, this is exactly what I do, “Flit” from one interruptions/tasks to another, desperately trying to find some free space to create something of value rather than simply “operate”. Many a times, I operate like a General Manager or COO, who is continuously handling exceptions, escalations, taking decisions and solving problems.
My day is majorly occupied with many such “flits, to a lesser extent with team reviews, and least with some free time to write/create.
This way of working is all about maintaining an already established system. Its like running the business system which has been established and dealing with exceptions which arise during the flows. However unless someone is looking at these exceptions, analysing them and asking the million dollar question: “what is the root cause of these exceptions“, “how can we improve the system to eliminate these exceptions“, this situation will continue day on day and only grows since the transactions are growing anyways.
Please note that, pending improvement in the system, all these exceptions in the system have to be handled as they arise. Someone or some team has to step in and resolve/fix situations. I am reminded of a real story about one of India’s oldest car companies. It was said that at the end of the assembly line, there was a QA division, which instead of just inspecting and ticking off the quality of the finished car, would actually initiate quick repairs to fix issues like ill fitting doors, unfinished assembly etc. So at the end of the assembly line, where it was expected that the car would arrive 100% complete and in top quality, the car actually arrived with a plethora of different problems and a team of workers would fix these defects. Ideally all these defects should have been taken care off upstream in the process (No prizes to guess which company I am talking about). On a similar note, the popular story about Toyota is that if any worker notices a problem in the assembly flow, he can raise a red flag, stop the process so that teams can come together to fix the problem before resuming the flow.
In most organisations, the teams to operate are always different from the teams who establish/improve the systems. If YOUR ORGANISATION or YOU don’t have the liberty of having a separate team to establish and improve the business system, consider the following suggestions:
1. If you must be interrupted with queries, decisions, tasks, I would suggest that you record the input for future action (maybe on the same day) and ensure complete closure of the work in hand. By complete closure I mean a logical closure of the entire task or of a “whole” part of the task so that you can switch to another task and come back to the original task by quickly re-establishing the context and re-starting the work. Leaving a task half done is a sure way to build stress, reduce focus and give superficial attention to the task at hand. Either ways if you must switch to the NMI (non maskable Interrupt at hand), do so with rapt attention and focus so that you can ensure complete logical closure of that new task at least. Learn this by practice.
2. Recording inputs for later action will help you identify/understand the improvements to be made in the system.
3. Establish Kaizen hours, days, weeks which are dedicated only to do improvements. Its like squeezing out those moments to improve the system, which by and by adds up to reduce exceptions/interruptions. Its like starting up a positive spiral.
4. I would say that even a single dedicated person on kaizen can start freeing up resources, which add up to more improvements, all leading to a smoother running system.
5. Examine the interruptions to see if some of them are simply some members of your team trying to put the monkey on your back, whereas they should be handling it themselves. Push the responsibility down the line. Your team will grow and you will find free time.
The kaizen falls in the range of minor cleanups, realignment of resources, documentation, re-architecting the system, eliminating waste, etc.
Yes! I do flit; Currently at this moment, It is necessary; But I also know that one at a time, I need to permanently resolve issues and re-architect the system to reduce friction and smoothen the flow.
Warning: Flitting can soon become a habit (not just at work but also in other aspects of your life), which prevents you from finding uninterrupted slots of time with undivided attention to work out issues, plan for the big projects, build understanding and refine skill sets. While its a comfort zone and also gives you a feeling of superficial achievement by keeping you very busy, its not very satisfying. You are constantly running on a treadmill.
I am deliberately not touching upon tips of time management. That could be the focus of another article. The below mentioned articles are good resources for that too.
A good article on building good personal habits: