Effective Context Switching #

What do we get by Context Switching efficiently? #

Context switching efficiently is how we,

• Prioritize mindful attention and celebrate the positive impact of single-tasking.
• Avoid unnecessary context switching to focus on tasks efficiently and achieve a sense of accomplishment.

Contrary to multitasking, the brain functions optimally when dedicated to one task. Deeper understanding and creative solutions can be generated by staying focused on a single task.

What can we do to reduce it? #

Some tips to minimize context switching include scheduling dedicated time for specific tasks, setting boundaries to limit interruptions, and using tools to help manage distractions.

Hence we encourage breaks and rest when needed and value-focused work over constant availability.

Have thoughtful, asynchronous communication #

We encourage asynchronous communication as the first mode and getting on to meetings only when needed. Check Being Axelerant | Meetings on how to effectively avoid and conduct meetings if the need arises.

Capture tasks somewhere that’s not your head #

Just thinking about another task splits our attention and makes it harder to focus on what’s in front of us at the moment. Studies show that simply making a plan to complete a task later helps to reduce repetitive thoughts about the task.

Prioritize your work #

Check The Eisenhower Matrix: Prioritize Your Time on What Matters Most - Knock Down Silos by Slab on detailed guidelines for the same.

Unlocking Your Potential: Organize Work and Calendar for Peak Performance #

Understand, identify, and classify items (excluding meetings) that need more time and those that need less time.

Large #

• Developing/working on a custom code is something that requires at least 3 or more hours of focussed time or fixing a challenging bug.

Medium #

• Ticket grooming is something that might need 2-4 hours of focused time.
• Giving feedback to peers.

Small #

• Peer reviews are something that can be completed in less time compared to above, like 15-30 mins, unless it involves many files and is for large enhancement, in case of which it falls into Medium work.
• Guiding peers/unblocking them (you are not expected to have long calls and do peer debugging with your peers unless it is explicitly called out). These are expected to be small-sized ranging from 30 mins to an hour.
• Checking Emails and Slack messages.

Note that all the above work listed under Large, Medium and Small falls under quadrants 1 and 2 of the Eisenhower matrix.

Now a combination of prioritizing and organizing your work will help in a large way. Do the below in the same order.

• Prepare your Eisenhower matrix. Generalize things here so that you can quickly decide where each work falls in as it comes.

  • Get inputs from all stakeholders (Team and Client) to understand what is important and urgent so that they are in the best interest of the project, portfolio, and Axelerant.
  • Also, do consider your interests in the different areas of work, acknowledge, and balance them along with the above inputs to make sure you are satisfied with your efforts at the end of the day/week.
  • Identify the action items you need to take to rekindle lost interest.

• Schedule time in the calendar for quadrant 2 large and medium-sized tasks of the Eisenhower matrix, which can be in this or next week.

  • This can be a recurring meeting with you as well.
  • Communicate to everyone that this is your focus time, including yourself.
  • This also requires you to look at the forthcoming work and plan for the same.

• Have some free slots a week to handle quadrant 1 tasks of the Eisenhower matrix. Make sure these slots are spread throughout the week and not on particular days, as urgency can come at any time.

• Utilize time in between meetings for small-sized tasks or take a break if you need.

• When your free slots are free, pick things from the small-sized bucket.

• If you continuously see your free slots are occupied, then rebalance your matrix.

Scenarios #

Below are some examples (inclusive but not exhaustive). Note that in all the below examples, it is important you rebalance your matrix when you see an imbalance.

When I deliver something on the fixed day, and if bugs come, then? #

Bugs will be the developers’ responsibility, and they need to do the necessary context-switching when any bugs are coming. In the long run, developers need to see how the bugs can be reduced so that context switching due to bugs can also be reduced.

When we get security updates to do in multiple projects on the same day, this increases my context switching #

We consider security updates as work that consumes very minimal or less cognitive efforts; hence, context switching is minimal. However following the steps as given below for unplanned context switching makes it easy for you to resume the work once done with security updates.

When the client comes with urgent work to look into, then we have to work over it immediately, which derails the week’s plan and increases my context switching #

Immediately, replan for urgent needs. In the long run, work over the technical debts. PMs need to also make sure features are not considered as urgent. You can also ask for help from the peer developer in the project.

When estimation needs comes, then I have to do unplanned context switching #

Below are the recommended steps to be done by the developers before they switch to doing the estimates

1. Whatever the state of the code, commit it, even if it requires adding a no verify flag and bypassing the coding standards temporarily. Push it to the feature branch.
2. Add detailed internal comments in JIRA about the progress of the development. It is okay if the comment is more technical, as it will help you when you get back to the development.
3. Finally, add forthcoming approaches and any technical plan or solutions that you want to do for this ticket. Add it as an internal comment in JIRA.
4. Once you have given the required time to the grooming/estimation, then come back to the development, and the above process will help you to have a better context switching.

My weekly plan is often distributed by the milestone delivery urgencies, and what I thought to be doing on the week was not at the end of the week #

If milestones deliveries are planned, then PMs are expected to communicate with each other to ensure that your weekly plan is communicated to you in advance.

I have to interact with multiple PMs and team members when working on multiple projects #

Plan your focus time for development in the calendar and take the non-urgent/regular/non-client calls out of the focus time. In all other cases where you need to be on the call, kindly follow the guidelines mentioned above before switching to non-development work.