How you, the manager, can help your overloaded engineer dig out

Because sometimes they need a little help

Overview

Imagine the following scene: you, the manager, have just completed a sprint and are reviewing team velocity. It’s ok overall but not what it once was. You loop through each assignee to see what might be going on and notice that one of your otherwise high performing engineers has only closed a few of their tickets. Your brow furrows - this feels familiar to the last sprint. You flip a few sprints back and a clear pattern emerges: for the past few months they have only been closing a small fraction of their tickets each sprint with the rest carrying over to the next sprint or getting reassigned to other engineers.

So you start to play closer attention to your report’s activities on Slack and in standup. You can see that they are always busy but with what? Or maybe you know what they are busy with and find yourself confused (or perhaps experiencing some more intense emotion) because none of it is directly related to their sprint work.

Or maybe your report is themself a TL or EM and their work isn’t captured neatly in a sprint but you can tell that their attention is spread thin. They aren’t making some of their meetings and the technical roadmap you asked for 3 weeks ago is nowhere in sight. What is going on?

This is pretty common and it can happen for a bunch of reasons including burnout, a loss of interest, a situation outside of work and so on. In this article, though, I will zero in on the overloaded report; this is someone who simply has too much on their plate at work and is struggling to clear it on their own. This is a problem which must be fixed before your overloaded engineer turns into a burned out engineer, a much harder problem to solve.

Fortunately, there’s a fairly straightforward exercise you can do with your report which I will expand on here. You will have them draw up a detailed list of everything (and I mean everything) they do at work. You will then go through the list together and, for each item, decide what doesn’t need to be done, what can be done less often, what can be automated, and what can be reassigned or delegated.

Your role as manager

To switch metaphors, your report is stuck in the muddy pit of Too Many Tasks. There isn’t enough light and the sides of the pit are slippery. Your role is to guide them out. Imagine yourself throwing down a ladder and instructing them on where to place their foot each step of the way.

This is the primary reason I have you, and not your report, lead this exercise. Here are a few more:

1. You will gain insight into your report’s workload. It’s amazing what you’ll find out about your report’s activities outside of the sprint.

2. This exercise is a handy way to find and eliminate toil for your team, always a win.

3. It can be easier for someone to learn this exercise from their manager first before applying it on their own in the future.

4. Your authority is key here for some items when deciding what can be left out or reassigned.

5. You have probably experienced this phenomenon yourself in the past, perhaps many times, and can guide your report with a helpful amount of firm compassion.

6. Going through this together and being the one to initiate the exercise builds trust and demonstrates to your report that you care about their wellbeing, which you do.

There may well be other reasons I missed above. Hopefully this list is long enough, though, to convince you of just how important your role is here and why it is good for you to be the one to lead this exercise.

The exercise

Do this together, live, in your 1:1.

1. Your report writes out all the things they do. Include the little things, erring on the side of more detail, not less. Prompt them when it feels like they may have left something out.

2. For each and every task:

   1. Does it need to be done?

      1. If not, cross it off the list.

      2. If yes, can it be automated?

         1. If so, automate it.

         2. If not, is it specific to their role?

            1. If yes, keep it. 

            2. If not, who on their team can do this task? 

               1. If someone exists and they have bandwidth, reassign.

               2. If no one exists, work together to figure out what needs to happen in order to up the bus factor. 

Deep dive on Task Actions

Here we will dig in to the different actions noted above: remove/reduce, automate, and reassign.

Remove/Reduce

Does it need to be done? Does it need to be done as often? If not, rejoice! You have discovered some low hanging fruit.

Perhaps your report has been checking the support email inbox twice a day but you already have an automated process to page the team. Or maybe they have been manually checking a dashboard daily when the thing they are worried about would only be actionable on a weekly basis. 

Or maybe there is no good substitute for this task but it just doesn’t align with the roadmap. This case can be a hard sell for your report. Engineers tend to get attached to work that sparks their interest. Work to understand the task’s meaning to your report. Blindly striking a project that your report loves can backfire and lead them toward burnout via a different route: boredom. Work with them to figure out how you can either give them the space to work on the fascinating thing or otherwise align their work with their interests. More on this in a later post.

Can it be automated?

Perhaps the task in question is necessary and cannot be done less often but is still toilsome.

Is your engineer manually shepherding a daily release process, running shell commands, clicking buttons, and tailing log output with bated breath? Or perhaps, upon receiving a weekly request to onboard a new data pipeline, they are running three somewhat janky blocks of SQL lovingly documented in their private Google Keep. 

Enter automation. Sometimes this requires a major project, but for the most part simply introducing a few well documented and/or source controlled scripts goes a long way toward reducing manual toil.

Reassign

OK - so the task is necessary, cannot be done less often and is not a good candidate for automation. The next question to ask is whether the task is specific to their role.

Let’s take the common example of a newly minted Engineering Manager. 1:1’s are definitely specific to their role and must be done by them. But maybe they don’t need to be the code reviewer on every single PR, especially for a larger team. Some of those PR’s should likely be reassigned to another senior engineer. If your report is a manager then they should be leaning responsibly on that #1 management tool, delegation.

Or maybe your report is a senior IC who has always handled all things front end. This is a good time to up the bus factor. If there is someone on the team already up to speed on front end development, redistribute that work. If not, now is the time to build that expertise outside of your beleaguered report. This will likely take the form of documentation plus some live training (a short term cost for your report that will generate long term rewards) as well as a conversation between you and the other person or people who should take on this work.

Again, many engineers get attached to their tasks and may not want to give them up. Use that firm compassion to understand their reservations and then move the task.

NOTE: It can be tempting for you, their manager, to take an item off their plate for yourself. Sometimes this is appropriate, sometimes not. It can be all too easy for you to become overloaded yourself. If you do take a task, make sure it is a temporary state of affairs.

Tips and Limitations

Make sure to do this exercise live with your report during your regularly scheduled 1:1. Turning it into a collection of async tasks just puts more work on their plate which will 1) make your report feel unsupported (You’re asking them to fix their workload by spending more of their non-existent time on your exercise) and 2) make it less likely to get done because they need to prioritize your new ask against their existing asks.

You may find that, after doing this exercise, your report has tasks that should be reassigned but there is no one to reassign them to. If this is because you are staffed up but no one has the requisite knowledge, then this is a matter of training. This might take some of your overloaded report’s time, so do what you can to support them through that and pitch in. Consider, again, using your dedicated 1:1 to write up documentation together, for example.

Sometimes, however, this happens because you simply do not have enough people. This is a valuable signal to you as manager that you have a bigger problem. You probably already knew, intuitively, that your team was oversubscribed but now you have some written and detailed proof. It is time to reassess the team’s workload and roadmap and do the individual exercise described here at a larger scale. What should the team say ‘no’ or ‘not right now’ to? What toil exists today? What should be automated?

Parting Words

Overloaded engineers quickly turn into burned out engineers. Most engineers cannot climb out from under the weight of all those tasks on their own. Pick up a shovel. Understand your report’s workload today and partner with them to determine what can be removed/reduced, automated, or reassigned. Once you have these action items, execute on them right away so your report can get out into the fresh air as soon as possible.

For more unsolicited advice about getting your engineer unstuck please check out:

Let's Do It Now, Together

And for a take on overload from the engineer’s perspective where I reuse the pit metaphor, please read:

Crawling out of the Incident pit of despair