Pro Tips for Context Switching Without Losing Momentum

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 flit from task to task 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 are the best ways to make it easy for yourself and others to switch tasks and cope with juggling project work.

Make context switching easier for others first.

Hint: 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 (unless you’re an asshole.)

It all starts with documentation.

Make 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, give a product overview, and document any environment setup needed on the project.

I’ve set up an example ReadMe here utilizing GitHub. But 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 thing we’re building? Give me the Main Idea, Who this thing is being built for, and the Main Problem we’re trying to solve. 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 Drives, Kanban boards, Continuous Integration, whatever. If it’s related, drop a link.
  • Development Environment and Stack specifications: This part should be thorough. Really, 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 this isn’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 3rd party integration? Link right to the docs. Your co-workers will love you for this.

Document everything. 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 the future of yourself, and tee those things up before the questions can be asked.

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 to check in and be helpful.

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 on the more confusing aspects of a project. 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.

Help you Help yourself

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.

Visible, Shared Time Blocks

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.

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 someone has an emergency, don’t worry; they will interrupt you. Most things can and will wait while you dive into a few hours of deep productivity. 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 in every meeting? Maybe the answer is yes, but maybe it’s no. You may have just bought yourself an extra 15 to 30 minutes.

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.

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 re-visit later, and unblock yourself where you can.

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.

How do you handle stresses like this on the job? Drop us a comment, we’re always trying to learn better methods for producing at a high level.

Revelry builds scalable digital transformation.

See how we deliver solutions on a faster and more transparent level. 

Check out more of our thoughts on development and product.

Keep in touch by subscribing to CODING CREATIVITY.

More Posts by Colin Scott: