I was working on writing this for the upstatement.com blog when I was laid off, so it is unfinished - it would have gotten at least 1 more editing pass and had some images added to break up the text more.

“Deep Work” (coined by Cal Newport in his book “Deep Work: Rules for Focused Success in a Distracted World”) is an idea that has been becoming more prevalent in the last couple of years, particularly with so many of us adjusting to working remotely, where the distractions can be considerably more plentiful (especially for those with kids, pets, housemates, etc).

Software Engineers have long-understood the need to have focus time, but Newport’s book has brought the idea to a much wider audience and given it a more relatable name. The idea behind Deep Work is being able to work “without distraction on a cognitively demanding task.”

One could make a case that “distraction” is the enemy of Deep Work, but Newport’s book speaks of Deep Work as a skill that you can hone, getting better at blocking those things out. Bearing that in mind, I think the true villain is what we call Context Switching.

Studies show that our brains can only hold so many things in the forefront at any time. There’s also an aspect of breadth versus depth: jumping between open apps and ongoing conversations might be easy when those things are light, but much more difficult if one is emotionally-charged conversation or when one is important legal paperwork. That’s because it takes time and focus to get into the “headspace” for those deeper things—and context switching disrupts that focus.

In that sense, context switching is like cruising along the highway at a steady 65mph—and then you come up to a toll. Everything has to slow down, vehicles have to sort themselves out as everyone picks a lane, and although you’re eventually going to get back up to 65mph, it takes a few minutes for things to clear. Context switching incurs a similar cost to your time and productivity; you’d be further along in your journey if you didn’t have to stop for that toll. Now imagine that your work environment could be such that you have tolls every 5 miles.

Context switching is the enemy of deep work because it prevents you from being able to reach the zen-like state of being fully engrossed in a task. Additionally, context switching challenges our brains because, as much as we can try to limit our distractions, typically the reason we context switch is out of our hands; it’s more akin to the start-and-stop jerking of heavy traffic. An alert comes in that something is broken, someone on your team reaches out with a question, there’s a meeting about to start, and so on.

In an ideal world, you’d be able to cut out context switching and stay focused on your tasks, choosing when you enter deep work and when you come up for air. In reality, that’s rarely the case, but you can develop strategies that help you context switch effectively—just like teaching yourself to be better at driving in traffic. You need to know the right lanes to be in, what speed each is moving at, when to change lanes, etc. These days, we often will just defer to a GPS system to get where we’re going. My father, before any 10+ mile drive, takes 5 minutes to look at a map - figuring out which highways he wants to take and when he wants to switch before he even gets on the road. It’s all about having the right strategies that work for you.

I have been a web developer full time for over a decade. While most of my background is in product, for the past four years I’ve been working at the design & development agency Upstatement. During my time at Upstatement, I’ve often been juggling multiple projects at once (In 4 years I’ve worked on 25+ projects, more than any other engineer by a fairly wide margin). I’m often tapped when a project has a short timeline, when someone is going on vacation, or when something is on fire.

As much as I thought I knew about context switching before, this environment has taught me even more. I do not presume to have all of the answers as to how to manage this, but I bring it up because I’ve been asked before what kind of tools and strategies I’ve used to be successful in this position, so I am going to lay them out for you, dear reader.

Identify

The first thing that you can do is identify the kind of work you need to do on your project(s). Knowing what is required of you and where your responsibilities lie can really help to allocate your time—and more importantly, your mental bandwidth—more efficiently.

As a project’s technical lead, you need to set aside more time to check in with others, to organize and make sure the project is on track. As more of a support engineer, you need to know the tech really well so you can jump in and help out where needed. As an infantry boots-on-the-ground engineer, you need to know what you’re building and why. These positions have wildly different priorities—and sometimes you can even have different roles at the same time, depending on your projects.

To give an example of this: In 2021, senior engineer Gino Jacob and I were working on two different projects at the same time. We were doing some high level technical direction and strategy for one group (let’s call them Beetle), while at the same time we were building Up the Block . If we were building both at the same time, they would have had very different codebases — Up the Block used Gridsome / Vue as a static site with data stored in Airtable, while Beetle would have used Craft CMS with some custom plugins on top of that. They weren’t just different codebases, though: the entire way we thought about those projects was very different. They had different needs and objectives and obstacles.

Some time ago, lead engineer Scott Batson gave a talk at Upstatement about “how to read more books each year”, and one of the strategies he proposed was to read multiple books at once. This feels counter-intuitive and like it can be confusing, but he explained that sometimes you’re in a rut with one book or just aren’t in the mood for it, and if you don’t have another that you might be in the mood for, you probably just won’t read at all. To go back to our highway analogy - having two lanes that you can jump between as needed keeps you more on track / constantly moving forward.

Situations like this can allow you to flex different parts of your brain and that can be really invigorating. Gino and I were able to let big ideas simmer in the back of our minds while working on building something else. What this meant for us was that while Beetle could be quite taxing and required a lot of Deep Work, Up the Block became a cognitive break . We knew exactly what it needed to be and it was easy to split the work into bite-size chunks that could be developed without needing a lot of focus-time.

I caught up with Gino for writing this and asked him if he had any big takeaways, and he brought this up, which is also a really good point:

Plan

Much of the impetus for context switching comes from outside of us - but the idea here is that you can still be prepared for it.

When you know what kind of work each project (or facet of the project) requires, you can budget better. If you know that there are areas that will require more Deep Work, you can do what you can to set that time aside.

If I’m boots-on-the-ground coding something, I like to have long blocks where I can get really deep into that project. That’s harder to schedule if I have multiple projects that fit that same criteria. If I’m the Technical Director doing more research and writing documentation, that’s easier to do in bursts—but also likely means I have more meetings. If I’m playing the role of a Support Engineer and mostly helping out fixing bugs and jumping in to assist with design implementation, that’s also easier to do in short bursts, but may have different requirements on timing.

There are times that I’m the sole engineer on a project, and when I’m on multiple projects where that’s the case, it can be tough to have the necessary long blocks set up for them. I may try to alternate (Monday is project A, Tuesday is project B, etc) but there are always other obligations - client interviews, stand-ups, sprint reviews, client check-in meetings, 1-on-1s, etc.

Those things can be tough context switches that I try to budget for, giving myself some buffer time. If you’re driving and you know the lane you’re in is merging, you might think of staying in it to get further ahead before you merge, but the less time you give yourself to switch over the more frazzled and anxious you might become. There’s little more jarring than being so distracted that you join a zoom without even knowing which project it’s for, or what the meeting is about.

You know when (most of) your meetings are, so you can think about what makes sense to do when. For me, I like to keep a 7am-3:30pm schedule, which means I have a few hours every morning that I can do deep work before most of the company even comes online. It’s not always the 6 hour stretch that I might want, but consistently getting 3 hours can still get me pretty far ahead - especially if the rest of the day does have a lot of context switching.

Something that I’ve done in the past is have my Google Calendar alerts go off 10 minutes before the meeting starts, and spend that time getting out of whatever I’m in, and preparing for the shift to something else. This is especially useful when you have a document to refresh yourself on, whether it’s someone’s resume or a proposed statement of work that you need to weigh in on, or even a sprint review where you need to look at the cards to remember what you actually did last week.

That said, when it comes to planning, I never look more than one week out. Any developer will tell you that the further you try to plan, the more you hit diminishing returns and a growing inaccuracy, because there are things you just can’t account for. We all want the perfect run, where there are no other cars on the road and we hit green lights the entire way. But that almost never actually comes up in practice.

What we want to plan for is needing to be adaptive and “go with the flow” at times. Our plan isn’t rigid , but simply represents our “best-case scenario”. This is your “I-90 is backed up but I can still take US-20” kind of situation. You have a plan, but you may need to make adjustments along the way. Making calls in the moment, yeah, you may arrive a little later than you hoped for, but without the flexibility, you could also still be sitting in traffic on I-90.

Prioritize

It’s obviously important to know what needs to happen when. When sprint reviews are, what deadlines exist, when your intended launch date is, etc. This is where I find having a Sprint Goal to be incredibly useful. When I sit down on Monday morning and ask myself, “Okay, what’s the most important thing for me to do this week?” the sprint goal acts as a guiding star. It allows me to develop a degree of focus: “This week, I need to do X.” Deep work is in service of that goal.

This can also tie into what we talked about before with identifying needs and having a plan. If you know when the launch date is for a project, you also know that the time leading up to that date (and on it itself) will be busy putting out fires and wrapping things up, and that’s time you will want to set aside.

My main concern when I’m working on multiple projects is being prepared for the very next thing. If that’s a client meeting, do I need to have X done before then? I also ask myself, “When will someone else be blocked by me?” I don’t want to show up for Standup and have someone say that they are behind because I didn’t finish something. I want us to be able to look forward to what’s next.

It can feel counter-intuitive to be focused on the very next meeting, because it can feel like you’re always playing catch-up, but in this case that’s By Design. A few months ago, I was co-founding a startup in my off time, and I asked Nondini Naqui (who I knew as a fellow startup founder) how she prioritized things. It was a situation where I had 40,000 things I needed to do and only my very limited free time to do them in. It’s not a unique or new problem - but with so much undefined, how do you justify spending cycles on some things that won’t yield results?

She gave me what might be the most useful advice I’ve ever gotten:

If you’re doing something today that you don’t need done until next week, you can feel like you’re ahead of the game. However, that might catch up with you if it means you’re not doing the thing you need to have done for tomorrow.

Especially with multiple projects, time is your most precious resource, and it’s about being conscious of where you spend it, and trying to maximize the value gain vs time invested. You may never feel ahead, but you’re also always steadily adding value.

Communicate

Realistically, the best way to make this work for you is to not do it in a vacuum. The more your team understands your working style (and you, theirs), the more you can make the most of each other’s time and not be distracting otherwise.

I was working with a veteran Upstatement designer for the first time a few months ago, and he DM’d me early in the project with a question, before following it up with:

That’s it - it’s low-effort and communicates a respectfulness of my own process while also proposing an approach that has thought behind it. Plenty of developers would probably rather keep things in the channel, to avoid the distracting notifications that come from direct messages. On this particular project, I’m doing a combination of Leading and Support Engineering, so I’m more accustomed to being pinged, and am somewhat less in need of Deep Work hours.

There is a simple but powerful thing that I do - and that’s to leverage my calendar. I mentioned that I sit down first thing at the start of the week to get a sense of my schedule and priorities. What I also do is add blocks to my calendar for things I need to do, identifying potential spots for deep work. For instance, I’m writing this now during a 2-hour block that I put on my calendar.

I also learned this helpful trick from Upstatement Principal Kim Miller: Don’t just create the blocks, but color code them to each project as well.

This is a screenshot of my actual calendar from the end of August, 2022. Grey is for general company or personal things, Red is for PBS NewsHour - we had a project around election coverage with some hard deadlines. Blue is for the American Thoracic Society, a nonprofit around connecting researchers. And Earth Alliance, a climate change initiative co-chaired by Leonardo DiCaprio and Laurene Powell Jobs, is green. All fantastic projects that I wanted to dedicate as much time as possible to.

Each day has one long block where I hope to do deep work. This also communicates to my team where my focus is, and when I would prefer not **to have meetings scheduled. With PBS NewsHour, I had one real task, so that got the biggest chunk of my freest day, even though it meant not circling back until the end of the week. With ATS, I could break things into smaller chunks: today Algolia search integration, tomorrow placeholder content. Earth Alliance required less of me, but I intentionally still kept open blocks of time in the afternoon if I did need to pivot to do more for it.

The other benefit of having a gap between the PBS stuff is that because it was the most complicated thing to do, I also left myself room to let it simmer in my brain juice, and to be ready to conquer any problems by when I got back to it on Friday.

You can also see how this fits into my “What’s the next meeting” approach; a bunch of the PBS work on Monday is just before the meeting, then again on Friday before that meeting. The ATS stuff is Tuesday and Wednesday before that meeting (which was rescheduled to Thursday this week).

This also allows me to communicate with my teams proactively. Because I have this plan, I can tell my PBS team, “Hey, I’m gonna be focused on another project for the middle part of this week.” Similarly, I can say to my Earth Alliance team, “I’ve got some free hours Tues & Weds afternoon if I can help with anything.”

It’s about trying to keep focus. The calendar provides an easy way for me to gauge my progress and to keep the sprint goals in my sights. If I end up behind on something, I can quickly look to see where I can extend time or where I might need to shuffle something.

This same principle applies to those with different working styles. If you’re the type to work more of a 11am - 7pm shift, you may try to front-load your meetings as much as possible, leaving your Deep Work hours until later in the day after others (like me) have stopped working.

If you know there are other things you have to do, those can go on the calendar, too. If you have to write peer reviews (which typically have a strict deadline), or struggle to find time to do code reviews, you can make a little focus block for those things.

Sometimes there are meeting conflicts - knowing your schedule can also help with raising that to people early. “Can we move this” or “Hey I have a conflict but I’ll check in later to see what I missed!” - you’re keeping them informed where you are and putting any fears they have to rest that you aren’t paying attention or are too busy. You have to make the call on which places you’d add more value.

For instance, looking at that Monday, I skipped an ATS sync in favor of the PBS meeting. Why? Well, I knew what my goals were for the week where ATS was concerned, and I also had a standing meeting with them on Wednesday. If I skipped the PBS meeting I’d have gone all week without that touch-point. PBS was also a project with a smaller team and tighter timeline - ATS had another engineer on the project who could represent at that meeting, and fill me in on anything important that came up. You make the call, you let the team know, but you also leave room for someone to correct you. “Actually we really need you there because…” - and you re-evaluate.

The idea of having this schedule isn’t to budget every minute or even every hour - you still want to leave gaps and assume that things will change. It’s more about a visual representation of your priorities—and your plan for completing them. It’s intended to help keep things from being overwhelming, or being forgotten, and to know where you can best spend your focus at any given time.

Optimize

One of the most valuable things that you can do for yourself and your team in these kinds of circumstances is looking for ways to optimize. This is true for any development team, but is especially so when it comes to working on projects with shorter timelines. When your project has a 6-10 week timeline (24 - 40 days), saving a day here and there is pretty huge. Saving a week makes you a hero.

Something that I tried to do early at Upstatement was get different teams on the same page about what scale to use when story pointing. It’s a small thing, but when I was jumping between different projects where an 8 on one might be a 3 on another, it increased that cognitive load. And it wasn’t just for me that that was the case, but our project managers and creative directors, too, who are never on just one project at a time. When you want to remove distraction and streamline how your time is being used, these things can add up. Most of our projects aren’t long enough for tracking velocity in a meaningful way, so why are we spending time debating how many points this task is, or explaining which scale we’re using? Just get on the same page, throw a number down that everyone understands, and move on to the next thing.

A more valuable example is in better setting up future projects. We had a problem happen on a site once involving needing much more robust caching than we were prepared for, and we learned from it, and now it’s something we go into every project asking about. Even more beneficial than knowing which questions to ask on a new project, is already having prepared the tools and information that they’ll need.

One of my favorite things are the Editorial Starter Kits we have. I’ll talk more about those some day in another blog post, but they are Github Repositories for Craft CMS and WordPress that feature fresh installs with a lot of our own things added in. The WordPress one existed already when I joined, and I spent about two years worth of Fridays and between-projects time building out a version for Craft. We have used the Craft one on about 8 sites as of now, and it has saved between one and two weeks of developer hours every single time. That time really adds up.

And this doesn’t mean, you know, we save a week or two so we take things easy - rather, that’s more time we can spend working on things that clients want, more time we can spend testing, more time focusing on accessibility or writing documentation. It essentially increases our value by automating something simple. I think about it like this: With the starter kit, I press one button and we have a Craft or WordPress instance ready to go for a new project. Not only does this mean that I’m ready to jump in on programming stuff, but it also means that our designers are ready to get right in with implementing the styling. It doesn’t just save my time, but it also gets me out of the way. Without it, that’s hours to days where I’m blocking someone - a situation exacerbated if I have multiple projects I’m working on. “Sorry, I can’t get this repo spun up until Thursday” is not a good feeling for anyone.

There are other things I’ve done in this area, too - Standardized our CMS comparisons (another blog post to come) and technical briefs, meaning that we can get that information in the hands of clients faster, especially where they need to make decisions or sign off on things. Again, trying to optimize where our time is spent and not reinvent the wheel. The lift of writing a technical brief is less of a context switch when I have a template that I can work from. These efforts are also things I will block off time for in my calendar (and is even present in the screenshot above: The ESK block on Thursday).

Wrap Up

I think that part of why I’ve been so successful in this position is that the idea of improving & being efficient comes naturally to me. I love sprint / project retros where we take learnings away and use those for the new project. And really, I think that’s all that balancing multiple projects is, just on a tighter scale and with other obstacles, making it something of a puzzle to solve.

For me, it’s all about asking those questions: What’s most urgent for me to do right now? What adds the most value? What will most benefit the client / me / Upstatement in the long run? If I could only do one thing this sprint, or this week, or today, what should that thing be?

It’s not about overwhelming yourself with extra pressure and needing to answer all of the questions, but rather, a tool for evaluating where your efforts are best spent - and like most things, it becomes easier the more you do it. Story pointing and talking through making tickets is an exercise that’s great for junior developers, because it gets them to consider the full range of the feature and its parts and complexities, but the expectation is that once you get more experience and exposure, you’ll innately think about those things without the prompting. It’s the same thing here - you’ll get to a point where you won’t be spending an hour or two planning out your week, just, “Okay, what’s the next thing? Got it, let’s go.”

Something that can be tricky is gauging your own success, especially across projects. There’s only one metric that I really use. I consider myself to be succeeding if I am present enough, and adding enough value, on each of my projects, that my teams have no idea how many things I’m actually doing. That’s it.

It’s not about obscuring the data (it’s all plainly visible on my calendar), but what I mean is that I don’t want others to feel that pressure. I don’t want others to feel like I’m distracted or absent or unavailable. I don’t want others to have their own efforts / productivity / success impaired by me.

I’m not always successful at this, but I do learn more and improve, and that’s what it’s all about. In the same way that not every team adheres to the same strictness in Agile methodologies, there are things here that work for me that may not work for you.

When we get overwhelmed, the natural reaction can be to speed towards our destination recklessly. For me, these strategies have helped me to reduce the weight of that, stay grounded, and be mindful of the decisions I’m making.

My intention here isn’t to say “Hey do these things”, but to encourage you to think about the problem before you and how you can solve it in a different way. You may find yourself using a few of my strategies, you may find yourself tweaking them, and you may develop your own. In any case, I hope this helps, and I’d love to hear about what works for you.