Everyone on your team works remotely. Someone just asked you a question in a Slack DM and you’re in the middle of something. What do you do?
My answer: wait till I’m free to sit down and read the question carefully before writing a reply.
Right? Isn’t that what you would do too?
Well, I lied. Maybe you did, too?
Replying only when I’m ready is a standard I hold myself to but occasionally fail.
I’ve seen many people slip on this, too. It’s because they’re busy, yet they want to help you get unstuck since they have the answer, so they skim your question (instead of reading it carefully) and throw you a quick answer (instead of editing before hitting send).
This often turns out to be counterproductive because poorly considered answers to poorly understood questions lead to more confusion. People ask questions to gain clarity. Confusion is in the opposite direction of having clarity.
So instead of being a person who unblocks the asking person’s work, you’ve wasted his time and attention and thereby creating a small additional obstacle.
I believe this pattern happens often enough that we would all be better off instituting a blanket rule across a team: don’t reply when you’re not ready to.
I find this to be especially important in the async, remote-first “workplace” because when we reply haphazardly, we are breaking people’s attention and negating the benefits brought about by async work.
Here’s an analogy: replying before you’re ready is like invoking a callback with erroneous data, making the caller hit the catch block and having to parse the error and then retry the initial question request.
That is a waste of a round trip. How not very engineer-y of you (and me) to waste bandwidth and precious seconds!
