As a manager, I coach engineers at various seniority levels. Some of them have much more experience in the industry than me, some have a similar experience, and some are less experienced. Regardless of the experience levels, I often see similarities between each one of them. Today, I write you about one similarity I often observe: trying to multitask.
There is tons of research about multitasking (191k results on Google Scholar), and there is a common finding: people cannot perform two attention-demanding activities simultaneously. People like software engineers need focus, and context-switching harms their train of thought.
Every task comes with a cognitive load that must be absorbed and kept while on the task. The cognitive load is what makes software engineering difficult and context-switching problematic.
In management roles, the cognitive load is a bit lighter. Managers don't have to know every detail of the task, its technicalities, and its solution like software engineers. For managers, other factors like challenges, risks, clarity of requirements, and timeline are more important.
Juggling multiple things at a time is common between engineering managers and staff engineers. It's due to a lack of company focus, not having enough people, or high expectations for productivity. Most of these issues are not in our hands, but there is one thing we can do. Within the endless backlog of tasks, features, and meetings, we have to stay focused.
The common advice I give junior engineers is to take one task with you, which is split thoughtfully and doesn't entangle with any other tasks. Then create a small pull request (or merge request) that does one thing from end to end. Most juniors I've seen struggle sticking to the scope of the task and getting it to the finish line.
When I became a manager, I forgot this advice myself and jumped into a lot of things and tried to do them simultaneously. Because similar to the junior engineers, I didn't know what I was supposed to do because I had no experience in management. There were tons of new things that I had to comprehend and figure out solutions for.
The same applies to staff engineers (at least for Architect and Right-Hand archetypes). Once senior engineers get a promotion, they must figure out many new things and how to become successful at their new job, which is often different from what they did until that time.
I was trying to achieve something between multiple tasks, projects, and people's problems and wishes, and my coaches recommended various strategies. They ranged from complicated Getting Things Done methodology to calendar management techniques, from delegation to learning how to say no. What they had in common was (and I wish I had seen it clearly at that time) to do one thing at a time. The exact same advice I give to engineers.
So, that is my recommendation for your whole life, independent from you being an engineer or manager. Stick to it, and you will achieve a lot.
Doing one thing at a time helps you focus on one just thing, do it well and finish it on time. It makes you reliable, trustworthy, and a problem-solver. When you do one thing well, you will also be surprised that you will have time for other things that need your partial attention.
When you're focused, nobody can pull you into side tracks. When they try, you kindly decline because focus demands saying no. Especially in leadership roles, you have to say no, decline meetings, and stay on track. I'll write in the future about these strategies, but for now, have a look at how many things you're trying to achieve. Are you multitasking? If you're, choose one topic and keep working on it until it's done.
Meanwhile, I don't recommend reducing all your projects, initiatives, or tasks to one and abandoning the rest. You'll have to learn how to run multiple things in parallel to have a greater impact. The point is to have only one of them in your focus and reduce context switching during the day and—if possible—during the week.
Choose your focus and keep the pace on others slow.
Give it a try, and let me know how it goes.
What I Published Over The Last Two Weeks
I wrote a short essay about the subtle difference between questioning and asking a question.
At the fundamental of any database, it stores data when we give it and retrieves data when we ask for it. We won't build a new database engine, but we roughly need to know how these operations work with hash indexes, LSM trees, SSTables, and B-Trees.
I will publish my notes from chapter 4 this Friday. If you want to receive an email about it, you can manage your email settings here.