“I hope I’m not bothering you.”
For many folks, including myself and many other software engineers, that voice can be a background hum to a lot of human interactions.
This likely includes many of the software engineers you manage or work with.
After all, you’re bouncing from meeting to meeting, filing tickets, reviewing code and generally bustling about all day. And you’re meeting with every member of the team.
Of course you’re busy! And, let’s be real, you probably are. Managing the actual busy is a story for another day.
For today, though, you want to manage the perception of busy for your team.
Because, when your team perceives you as busy, things will fester and grow without the sunlight of your attention … or less poetically, you’re going to miss some shit.
Engineers won’t want to bother you when they’re stuck, or when something breaks, or when they get a bad feeling about something.
They won’t bother you when someone skips process and has them do something off-cycle as a favor, or when an incident first starts.
Any issue or information will need to cross a reporting threshold that is set by how busy your team thinks you are. Whatever the thing is – the question, the issue, the burgeoning incident – must cross a threshold of “bother.”
Essentially, your team will be calculating, “Is this enough to bother them about?”
It’s like a dam over the river of information you need to be effective at communicating status to the rest of the organization, and to avoid blind spots.
Long story short, an engineer I’m managing telling me they think I’m busy means I screwed up and run the risk of a cascade of shit.
This is why I would explicitly say the following or something similar to every engineer I managed:
“I am not busy. You might think I’m busy, but I’m not. I am waiting for you to email me, or send me a Slack message, or give me something to do to help you.”
Followed by:
“I want the people above me to think I’m busy, but not you. For you, I’m not busy, and you’re not bothering me.”
In addition to explicitly setting the expectation that you’re not busy, you can demonstrate the same using the following techniques:
- Be on time for 1:1s: This is common courtesy that you should be doing regardless, but don’t move 1:1 meetings, don’t show up late, be present. 1:1s are not your meeting; they are for the folks you manage, and the clearest and most direct way to show them you have time for them is when you show up to their meeting on time and present. Make it a priority. The most important meetings on your calendar are your 1:1s – everything else must move around them.
- Phone and laptops down: Related to being present, turn off screens for 1:1s – unless you’re doing them remotely. And even remotely, full screen the video window and don’t multitask during it. Communicate through your actions and attention that you have time for this engineer.
- Be available, but set boundaries: Part of selling “I’m not busy” is also responsiveness. How quickly you acknowledge and respond to messages and outreach also sends a powerful “I’m not busy” message. But you also need time for deep work, and life in general. Setting expectations and boundaries around the time you will not be available is just as important as being available in the first place. Be explicit about your schedule, when you actually _will be_ busy or occupied or elsewhere.
- Be proactive: Most of what we’ve talked about before now has been about opening up lines of communication from your engineers to you, but a well-timed “How’s things?” or “How are you?” can also work wonders. This is because for a lot of folks, the “bothering you” threshold never really goes away and will replenish the longer a gap is between communication. So, check in every once in a while, if only to reset that threshold for when things need to be communicated later.