Context switching is a computing term that describes how an operating system stores the state of One process (A) before starting another process (B). Before resuming process A, the state of process B must be stored. We use the same term to describe how humans switch from one task to another. Although context switching involves working on different processes or projects, it is not the same as multitasking.

Multitasking is doing two or more things at the same time; for example, texting while driving. With multitasking, one or both tasks suffer from decreased attention. Context switching is stopping one task before starting another, like alternately texting and driving. Each time you want to read or send a text message, you have to find a safe place to pull off the road, pull over, put your car in park, pick up your phone and then text. To resume driving you have to move the phone aside, put the car in gear, and then get back on the road and up to speed.

Hidden costs of context switching

Developing code carries an extremely high cost of context switching. The most productive way for our developers to work is to focus on one project each week. In our experience, we’ve seen that trying to devote attention to more than one project in the same week results in multiple inefficiencies. The time spent getting back up to speed on a different project is the first inefficiency; however, it’s not the biggest offender. The mental cost of context switching is where the cost of context switching skyrockets.

Finding elegant solutions to problems is everyone’s goal on a project. When working on complex coding problems, creative problem solving is required to come up with the best solutions. Being immersed in a project, considering problems from different angles, and allowing the time and space needed to devise solutions is how brilliant ideas are generated.

Being asked to stop work on one project and pick up another from one day to the next; or worse, in the same day, is unproductive and demotivating to our developers. They lose momentum they’ve built getting up to speed in the original project and may lose a train of thinking that was leading to an innovative idea. Switching from project to project requires a great deal of mental energy and can quickly lead to burnout.

Using time blocks to prevent context switching and promote saw sharpening

As a company, we work on multiple projects at the same time; however, we ensure that individual developers are protected against context switching. To prevent context switching, we make sure that each developer is focused on one project per week. Monday to Thursday is one block of developer time, and that block is 100% devoted to the same project. Our no context switching policy is in place to protect both our resources and our clients against the detrimental effects of context switching.

If a pain point arises during the week, it can be solved on Friday without compromising the project schedule. For example, if we discover an inconsistent coding practice in the application we’re building, we would take the time on Friday to standardize everything to ensure consistency. Fridays also have time reserved for “saw sharpening” — a habit recommended by productivity expert Dr. Stephen R. Covey. On Fridays, people can take the time to learn, improve, and expand their skills. Continuous improvement keeps our team extremely sharp and efficient.

Why our clients prefer time blocks

Clients benefit from our time block system several ways. The first benefit is quality. Clients reap the rewards of having “sharp” development resources focused on only their project during each time block. Another benefit is billing regularity. Clients have a predictable amount of billing each month, with no spikes or dips in hours.

Minimizing context switching and working in time blocks has proven to be an effective way to keep our team operating at a high level. Time block scheduling is also a cost-effective strategy for our clients.