7 Tips for Context Switching Without Losing Momentum

Originally posted December 11, 2017

At Revelry, we partner with a lot of different companies to deliver innovative solutions using technology. Our communication process and our one week sprints mean that on any given week, we might be playing a bit of musical chairs.

That means we have to be adept at context switching. No, this doesn’t mean that we float from project to project throughout the day. But, it’s very possible that when I move to another project, I will have to dig in with implementation right away. And it’s likely that I left some issues lingering in QA or UAT on another project from the week before.

Our assignments aren’t random—we resource the most appropriate person to work on the highest priority problem from week to week. This process requires trust and skill at context switching.

Here is my list of 7 tips to make it easy for yourself and others to switch tasks and cope with juggling project work.

Let’s dive in.

1. Document Everything

Make context switching easier for others first. Why? This will benefit you too. When you leave an unfinished project, someone is always left holding the bag. In these cases, you want to do all you can to help that person succeed and push it over the finish line.

How do you make context switching easier for others? It all starts with documentation. Consider future you: what questions do you have when jumping in a project? What problems do you constantly run into? Be nice to people, like your future self, and tee those things up before they become a question that you know you will be asked.

2. Write a Beautiful Project README… and Keep it Beautiful

At Revelry, we use a README for everything. It is our main source of info when jumping on a project. It should contain all relevant links, list all team members, write a nice product overview, and document any environment setup needed on the project.

I’ve set up an example README here utilizing GitHub.

What Should a README Contain?

No matter which collaboration document or tool you use, your README should contain, at MINIMUM, the following information:

Project Brief

What is the overview of this product we’re building? Give the main idea, who this thing is being built for, and the main problem we’re trying to solve. There are sections for the Core Loop, what does this project accomplish at its most base level? Nouns and Verbs provide context on user types and actions in the project. We also like to include a BPMN model so people can get a visual representation of the project. All of this isn’t always necessary but context is key. You get a better product when the person building it has the whole gist.

Roles and Responsibilities

Who does what? When jumping into a project, I should know who owns this product, who manages this product, who designs this product, and who tests this product. Who do I go to for questions? All of these should be answered without having to ask anyone.

Relevant Links and Docs

Anything used in the management and building of the project should be here. Google Drive folders, Kanban boards, Continuous Integration, whatever. If it’s related, drop a link.

Development Environment and Stack Specifications

This part should be thorough. Really, really thorough. Nothing worse than jumping into a project and spending days just trying to work. Preferably this is a script you run and it’s done. I highly recommend spending the extra time and using setup scripts. Something as simple as a Brewfile can save hours and even days in some cases.

If setup scripts aren’t feasible for whatever reason, then write a step-by-step “For Dummies” type guide. Don’t forget to lay out any gotchas or common errors with their solutions during set up. Is this app using some sort of API or third-party integration? Link right to the docs. Your co-workers will love you for this.

3. Make Yourself Available

Have some empathy for the folks rolling in behind you on a project. Be ready to answer questions…a lot of questions, and help out when needed. Everybody is busy all the time. Pausing to help each other is nothing new. It will not kill you to scrape out a few minutes each day (context switching) to check-in and be helpful.

4. Create Clean, Readable Code

Hitting on the same theme from above, code like you’re explaining everything for the next person in line. Make sure your code is clean and readable. Follow KISS and DRY principles, be consistent in variable naming, and leave comments. Comments are especially helpful in the more confusing aspects of a project, especially with lots of context switching going on. Nobody is going to complain about too many well-written comments explaining what is going on.

If you really want to go the extra mile, write your commit messages like you’re telling a story. Be descriptive and make a real narrative.

5. Use Visible, Shared Time Blocks

You’ve done the noble thing and given the next person on your unfinished project a leg up. Now it’s time to set yourself up for successful context switching.

Context switching is like being torn between two worlds. You’ll spend hours being busy but feel like you’ve accomplished nothing if you’re not careful. Changing tasks can be one of the most draining things on your brain.

This is where you need to time block. At Revelry, we use Google Calendar to schedule meetings, and it offers a nifty “Find a Time” feature to see when someone is busy. So, we encourage each other to schedule heads down, non-interruption time.

What Is Time Blocking?

Take a few hours in the morning and block off time with the specific context you want to work on. This may seem contradictory to “Make yourself Available”. It’s not. There are enough hours in the day (seriously, there are…even as you’re thinking right now that there isn’t and this guy is an idiot. I promise you. There are enough if used effectively).

Most things can and will wait while you dive into a few hours of deep productivity.

If someone has an emergency, don’t worry; they will interrupt you. When you come up for air, be sure to check those notifications and emails, and help where you can.

Ask… politely, about all those meeting invites you have. Are you really needed at every meeting? Maybe the answer is yes, but maybe it’s no. You may have just bought yourself an extra 15 to 30 minutes.

6. Stop Multi-Tasking and Be Smart About Your Task Management

To build on blocking off time… STOP multi-tasking. It doesn’t work.

The brain just doesn’t operate that way. Use those heads-down time blocks, and use them with specific written out intentions. The more specific you get, the more productive you’ll be. At the very least it should be “1-hour heads down on project A”. It’s also important to know your schedule. Have a day full of meetings and interruption? Maybe don’t work on that major feature today. Focus on smaller, more manageable tasks.

7. Allow Plenty of Time for Setup

Allow yourself ample time for a new project set up, and start ASAP. Don’t wait for a scheduled kickoff.

As a developer, setup can be one of the most unpleasant experiences when jumping on a new project. Don’t get discouraged, but be prepared for dependency hell. Keep pushing through and don’t let small things block you. Just mark those blockers to revisit later, and unblock yourself via context switching where you can.

In Conclusion

Changing projects can be a pain, and sometimes there’s just no avoiding it. It helps to center your focus instead of feeling overwhelmed and inadequate when juggling projects. Hopefully these tips for effective context switching helps you moving forward.

---

Process Productivity