In last weeks video we said that in the quest for faster time to value, it is alright to incur context switching costs. A few folks reached out to me over the last week asking whether context switching is always a good thing.
To explore that let us first take a quick look at what context switching is: Lets say you are working on a presentation and suddenly you have to look at a bank account and reconcile a few transactions. Your brain will take some time to switch from the presentation context to the bank account context. The time spent to switch context is essentially the cost of context switching. On a lighter note, I hate account reconciliation and dread that time of the month when I need to do it :-(
In last weeks video we said that in the context of product development, it is ok to incur the cost of context switching if it allows you to get to value sooner.
There are however scenarios where the context switching doesn’t really help. For example lets say there are 2 things you need to work on. Say feature A and Feature B. And assume that feature A takes 10 days and feature B also takes 10 days.
If you spend 1 day on feature A, then another day on feature B, and keep alternating between the two, that’s not ideal. This has 2 key issues:
Every day you are incurring the context switching cost between A & B
You will be done with Feature A on the 19th day and Feature B on the 20th day
In this scenario, what you should do is to identify the higher priority activity and focus on getting that done before starting the next one.
Remember the finish what you start video? That’s exactly what you have to do.