Multitasking refers to working on more than one task at a time. Although, as per research, it is not possible for humans to truly multitask like computers, we often hear this term at work. Among engineers, it comes up when there's more than one task assigned to them for the day. Typically, they spend a few hours (or probably minutes) on one task, then switch to another task by pausing the first one. With senior developers/managers, the degree (and expectation) of multitasking increases. If you have grown in a startup environment, you've likely done a lot of multitasking already (even beyond your job role).
Upon joining LocoNav, one of the concerns I raised with my seniors was my struggle to dedicate ample time to a single task, as I found myself constantly juggling multiple responsibilities. There was a time when I was assigned 4 tasks (mostly coding), and all of those were "on priority" for the respective stakeholders. I remember writing long emails back in 2018/19 regarding "context switching and productivity." I thought it's a planning problem (somewhat it was), but it was more to do with how fast-moving startups generally operate, and my mind took some time to get habitual.
Over time, I've had the opportunity to work in both multitasking and focused work environments. Additionally, I serve as an individual contributor or manager as needed. Given all this experience, I've developed some opinions around multitasking:
If you're given a second task when you're already in the middle of something, make sure to leave the first task in a state that it is efficient to continue again. For example, if you're in the middle of an investigation and it takes 1h to complete that, ask the team, "Can the second task wait for an hour?" If yes, close your investigation, log that in a comment, and then switch. Don't just abruptly switch. Sometimes, the second task takes so long that your manager would want someone else to continue on the first task. This is efficiently possible only if they can continue from where you left (without you explaining everything on a call).
If you're almost done in your current task or need 1-2h to complete, discuss and close this task first. Unless the second task is a P0 production bug, it should be possible to push back.
Multitasking productively is hard. Even with a lot of experience, we shouldn't expect that everyone can efficiently multitask. There are people who prefer to close one task and then pick the other one. Managers need to understand this.
You can't avoid multitasking. Even if your sprints are planned nicely, there are chances that you'll be assigned a production bug or some other escalation. So if you're in a team that faces such issues, don't think that an ideal world exists. This happens almost everywhere :)
You could feel burn out in the long run if you're multitasking regularly. This is so because your mind overworked and couldn't rest. After work, you might not have the mental energy for anything else. I've experienced this personally.
Regular multitasking might put you in a situation where you don't actually complete anything at the end of the day. All the tasks move a little bit, but nothing real gets delivered. None of the stakeholders are happy in this situation. Rather, we could have prioritised/completed 3 tasks out of 10 (for example).
Don't just accept tasks because they're coming to you. If you're working with multiple teams (shared resources), you might be assigned tasks from multiple managers where one manager might not know the complexity and priority of someone else's tasks. Pushing back some tasks works sometimes.
If you have so many tasks on your plate and you think you're just jumping from one to another, you should work on prioritizing them with your manager/team. As an example:
If you are a developer who mostly codes, try not to switch in more than 2-3 tasks.
If you are a manager (mostly delegating tasks), you can probably switch between 3-5 tasks also (depending on the complexity of tasks).
The numbers shared above are just examples. Sometimes senior engineers are working on architecture designs that require dedicating more time on a stretch. So they prefer to go on "Do Not Disturb (DND) mode" and not pick any other task. It all depends on the specific task and team setup.
Every team wants to move fast - Developers want to be as productive as possible, and managers also need tasks to be delivered sooner. Unless your role grows from a developer who has faced productivity issues, as a manager, it takes time to understand that multitasking is not everyone's cup of tea. As a developer, it is equally important to communicate and solve your productivity issues.
If you're someone who has faced these issues, please share your experiences. If you're someone who is still facing this, let's talk in the comments :)
If you liked reading this, I'd recommend these too: