Managing Overload: Part 1

The Daily Challenge

As technical leads, we have a lot on our plates:

• Architectural decisions

• Personal productivity

• Team productivity

• The big picture

• Timelines

It’s a lot to keep in mind. Technical health is our job.

But when you get requests coming in faster than you can deal with them, what do you do?

This article explores the first of several techniques I use to manage my workloads and keep my teams productive.

The First Solution

This approach might sound brutal until you understand why it isn’t.

I don’t respond immediately.

In an age of remote work, most of my requests come through Slack or email.

Not all questions require an instant answer.

Some requests have clear priorities: give an architectural design review of ABC.
Some aren’t: an engineer is stuck on XYZ.

The latter consumes over 60% of my requests.
Roughly 30% are automatically resolved with this approach.

Why It Works

Engineers work hard to be lazy.

That’s the stereotype. And it’s a demographic to which I can relate.

Sometimes that laziness goes a bit too far.

Jumping in to save everyone the moment they have a question does two things:

1. reinforces this behavior

2. caters to this practice

In the heat of a problem, an engineer’s first thought should not be, “I need help, so I’ll ask ABC since he/she probably knows.”

The first thought should be, “I need help, so I’m going to dig in and figure this out.”

After all, when the pros get stuck, there’s often no one to ask. So, they have no choice but to do the same and dig in.

When To Relent

The goal isn’t to remain silent.

The goal is to:

• readjust your thinking as someone who doesn’t always need to swoop in to save your team

• readjust your team’s thinking into independent thinkers

My wait time is a sliding scale:

• If the issue is urgent and has a broad impact, don’t wait to reply.

• If the associate is relatively competent with a non-urgent question, maybe 10-20 minutes.

• If your colleague is just getting started and needs hand-holding, maybe 30-45 minutes.

In general, the more inexperienced the colleague, the more likely their question to you was mixed within a flurry of Google/ChatGPT searches. Given a bit more time, they’ll likely find what they need.

More experienced engineers tend to have already tried their options and don’t need to be kept waiting as long.

This isn’t a formula, but a guideline. Adjust to suit your team.

The best learning is accomplished through trials.
The best retention comes when you breakthrough yourself.

Give your team a bit of a chance to take the hard path and win their own, sweet victories.