In a small startup, everyone is wearing multiple hats. On a typical working day, I have many tasks. Some require coding; others require writing or having meetings and take actions item.
In the beginning, my strategy was to keep a running checklist of things to do similar to my previous experience as an engineering manager at Venmo. I bucket things to do in different sections, such as “TODO,” “DOING,” and “WAITING.” And I try to update the status of those tasks as a new task comes up, or I finish one task. However, after a few weeks of running this strategy, I felt burnt out and not accomplishing as much as I expected. One main reason is context switching - I constantly find myself having to switch between coding and non-coding tasks - I would be writing meeting notes for 15 minutes, then on to code review for another 15 minutes, then on to writing a strategy document for another 30 minutes, then developing a feature for another 30 minutes before someone has a question about the strategy document I wrote. The constant context switching made it hard for me to think deeply about any issue that I’m dealing with at any given moment, and I feel the need to catch up on all the work that I need to do.
If we think about why context switching is a major time sink - imagine we try to write two names, like “Michael” and “Rachel.” One way is to write one whole name at a time: first M-I-C-H-A-E-L, and then R-A-C-H-E-L. Another way is to write one letter at a time while switching between the two names: M-R-I-A-C-C-H-H-A-E-E-L-E. Compare the two ways, the first way takes significantly less time, and it produces significantly fewer errors. Such is the power of minimizing context switching - it’s faster and more efficient.
Having reflected on the negative aspect of context switching, I decided to rearrange my time to be more efficient. I spend every morning of each day on non-coding stuff - meetings, writing documents, having 1-1s, and then I use lunchtime as the buffer for me to switch my hats. In the afternoon, I spend my afternoon writing code, review code, and build infrastructure - that is, to put my full engineering hat on. I made it transparent to the team that I plan to structure my day using this new schedule, and why I am doing it.
The improvement was significant. I feel more grounded during the chunk of a day, and towards the end of the day, I feel more accomplished because I have a better recall of what I have done for any given day.
My current success with minimizing context switch encourages me to improve my time management further and form better habits based on this mindset. There’s value in spending a chunk of time to commit to one thing at a time.