Have B-Track Work

One of my best technical mentors, Cameron Behar (CTO of Sprinter Health), gave me this advice for working more efficiently when your project gets blocked or iteration times are slow: Have a secondary workstream that you can switch to when your primary one is blocked.

Getting blocked on work causes all sorts of issues for engineers: it's frustrating, it forces context switches, and it kills momentum. Personally, it's extremely frustrating and emotionally draining to have a high-pri task stuck in a way where I can't make progress. It feels like busy-waiting, a particularly expensive way a computer can wait for another task to finish by running in a loop constantly checking if it's done. Having a second workstream that you can jump to helps alleviate the problem by removing the question of "What should I be doing right now?" Instead of having to spend time and energy picking the next most important thing, you can pick it beforehand. I call this my "B-track". My main workstream is my "A-track" and my secondary is my "B-track". Instead of prioritizing everything I could be doing against everything else I could be doing, I only have to decide when the marginal utility of working on my A-track has dropped below the marginal utility of working on my B-track.

Here are some examples of when I might switch from my A-track to my B-track:

• Waiting for code to be reviewed. This might cause a few hours to a few days of downtime depending on how complex the changes were. A lot of that time is spent waiting in asynchronous back and forth conversations about feedback on diffs, where it's more efficient to leave your changes as they are and work on something else while you wait for your reviewers to have time to take a look. As a side-effect, it keeps the pipeline primed: if your B-track work advances enough to produce another diff, you can get that next review cooking asynchronously while you follow up on your A-track diffs.
• Waiting for a deliverable from another teammate. This could be waiting to review something with a designer, or waiting for a decision on some feature from a PM (product manager), or some other part of the process that isn't in my control. Structurally, this is similar to the code review situation, and it has the same pipeline efficiency benefits.
• Waiting for code to compile or infrastructure to spin up. Whenever something is rebuilding or compiling (looking at you, mobile apps and code generators), you could switch to your B-track. This one requires faster swapping between projects. Doing this requires that you have the ability to separate out your workspaces such that you can quickly swap between different workstreams: e.g. have two different version control branches checked out in different editors, or projects in different parts of the codebase (like frontend and backend). This works better when your B-track is simple and interruptible so you can switch back to your A-track quickly. Easy refactors fit the bill, as do certain process-management/accounting tasks. Things that have a lot of state or context wouldn't work here.

Compiling

xkcdAbout

B-track work has to be something you can easily make progress on. It has to be easy to swap back and forth to without needing a long wind-up or a costly context change. Generally, it shouldn't be anything that requires deep thought since those tasks are hard to get done in short chunks. Things that are already planned and just need execution are good candidates, as is work that is more mechanical than strategic. This kind of work can be a break that lets you relax without completely dropping out of your flow state. It keeps the momentum up and helps you feel more confident about your productivity. It can be especially helpful for more senior folks who have days where they're in and out of meetings in 30 minute chunks and don't have a long block get into a flow state. It can help you feel better about what you got done in a day because the tangible progress on the B-track work gives you something to point to while your long-term work slogs on. On the other hand, if the B-track work is too complicated and requires a huge context switch, it'll knock your A-track work out of your working memory and delay it. Pick a complexity commensurate with how often you'll be switching: if your A-track is blocked for days at a time, maybe you can afford to drop context on it in favor of your B-track when you swap. On the other hand, if you're switching for five minutes at a time, you'll need something extremely rote to do.

Good B-track work needs to be less important than your A-track work. Telling your team that a workstream is on your B-track signals that they shouldn't count on that workstream getting done by a particular time. It's explicitly there to soak up the excess resources you have while working on your A-track work, but the A-track work will always be the most important. If both things are equally important, you might still get some benefit from jumping back and forth between them when they get blocked, but you don't get the mental benefits of easy prioritization. Having your B-track be on the critical path means that it creates pressure for you instead of being a pressure release valve. On the other hand, it's a great way to get people on board with you working on something that's less urgent but more interesting. Hearing that it's strictly secondary to your primary work means that team leaders are less worried that your "side-project" will take resources away from your critical work. Instead, anything you get done on your B-track project is just extra productivity that would've otherwise been lost, and you've framed it as a win-win.

Ideally, B-track work is something that gives you energy and can recharge you. Cameron said that he likes to save "easy wins" for B-track work so that when you're discouraged by your A-track work being blocked, you can pick up small wins from your B-track work. Finding B-track work that excites you but still fits the criteria above can be challenging. I think that if we can't get to "exciting", we can settle for "satisfying". Here's a brainstorm of things that might qualify:

• Reviewing other people's code, especially when you're not a critical-path reviewer. Reading other people's diffs/pull requests can help you stay up to date on other projects, and providing effective feedback quickly can help newer folks ramp up faster.
• Fixing a small bug that bothers you, but isn't high-pri enough to be A-track.
• Improving the quality of the codebase by adding tests, improving alerting, refactoring things that have become unwieldy, fixing broken tests, or addressing build or runtime warnings that everyone has secretly learned to ignore. Alternatively, you could do non-coding things that improve technical quality like improving documentation or providing support to other teams that depend on your team’s work by answering questions in a support group.
• Trying something out. Sometimes you just wanna poke at an idea you have to see if it'll work such as a potential refactor or a new way to use an existing capability, and making it a B-track thing relieves the pressure of having to justify the risk of experimenting in case it doesn't work out.
• Getting ramped up on your next project. This could be dev environment setup work, reading documentation, sending reachouts to partners you’re gonna work with, or reading code to get familiar with the codebase.
• Catching up on “chores”. These aren’t necessarily exciting or intrinsically satisfying, but they’re things you need to get done that can get stressful if they’re allowed to build up. Things like filing expense reports, writing project update posts, and triaging tasks in the team backlog could qualify here.

I don't think there's anything too novel about the idea of having something to work on when your main work is blocked, but there's something simplifying about calling out what work is A-track vs B-track that works well for me. Internally, it helps me be efficient about prioritization. Instead of having to consult a backlog every time I have a free moment, I can instead just get something done. Externally, it's a much more succinct way to communicate a fairly nuanced set of expectations.