In software engineering, we often rely on “exponential back-off” when retrying failed network requests − a technique where each subsequent attempt is spaced out further in time to avoid overloading the system. Oddly enough, I’ve found myself applying a similar concept to human communication.
As a Engineering lead, I’m frequently on the receiving end of an unrelenting stream of requests:
- A Slack ping about a pressing issue
- A pull request to review
- A CV from a recruiter
- Another CV for a completely different role
- A message from customer support about an urgent user complaint
- An escalation from the Security team
- A calendar invite
- A last-moment meeting reschedule
- A quick question (this one’s my favorite)
All of this happens while I’m trying to carve out focused time to work on broader goals: improving team processes, ensuring teams have clear direction, and writing progress reports or strategic documentation. Even with AI-assisted tools, writing takes time − because effective communication requires tailoring the message to its audience. Tone matters. Clarity matters. Accuracy matters.
“Exponential back-off communication”
To avoid drowning in a flood of requests, I’ve developed a coping mechanism I half-jokingly call “exponential back-off communication”. I try not to rely on it too often − it doesn’t sound nice really, and honestly, it would be great not to use it at all. But it’s sometimes the only way to protect deep work from being drowned out by reactive tasks.
Here’s how it works in practice
Everyone who reaches out deserves a response − obviously. But occasionally, someone will send a message and get a response − and immediately follow up with four more. Responding to every single request in real time would mean spending my day doing their job – instead of mine. Most likely, that wouldn’t be what I was hired for, and it’s not how I add the most value.
So, I start spacing out my responses − especially if the requests aren’t urgent or relevant to my core responsibilities. The more they push, the longer the delay between replies becomes. I don’t ghost people. Don’t ignore them. But I shift the cadence to reflect the actual priority.
Informal priority classes
This approach isn’t purely algorithmic. It’s also guided by informal “priority classes” based on two main factors:
- Relevance: how closely is the person’s request aligned with my responsibilities?
- Pushiness: how frequently and insistently are they demanding attention?
Sometimes, someone’s job depends on my timely input. Other times, it’s just easier for them to ask me than to try solving something on their own. I have to weigh that trade-off − not out of ego, but out of necessity.
And let’s be honest: replying isn’t always as simple as writing back in Slack. It might require investigating a system, talking to other stakeholders, or checking documentation, maybe collecting some historical data. All of that takes time. And then there’s context switching − that quiet productivity drain we all contribute to, even if we don’t mean to.
This approach has worked well for me − and, as far as I can tell, for most of the people I interact with regularly. It helps set expectations, reduces friction, and creates space for more meaningful conversations.
Responding with intention
In an ideal world, every request would receive an immediate, high-quality response. In reality, prioritizing quality and meaningful progress sometimes means slowing things down − and that’s okay. I wouldn’t use exponential back-off by default, but when the signal-to-noise ratio gets too high, it becomes a helpful tool − a way to protect focus without compromising on what truly matters.
Links and resources
🚧 tech information overload ahead 🚧
More about exponential backoff in the context of Redis or in general terms on Wikipedia
