In this post I’m going to focus on the communication element: specifically, what we can do to make the most of the vast array of asynchronous communications channels we have at our disposal. (And when life returns to normal, all of these principles will continue to apply if perchance we are working in the same room at the same time.)
Far too often I’ve observed an async conversation – be it in a GitHub issue, a slack channel, a JIRA card, or an email – (does anyone use voice mail anymore besides telemarketers?) – where to me it appears that contributors are attempting to save time by being brief. (Oooh, is that a legacy of the good ol’ days of telex? Who else remembers paying by the character…?)
The illusion that communication is actually happening is dispelled by an endless game of comment ping-pong. Misunderstandings are soon followed by frustrations. The outcome: Threads that one must read from top to bottom (multiple times) to have a chance of grokking “the outcome.” And perhaps a few tweaked noses. So much collective time and energy wasted that could be better spent enjoying a virtual coffee or a beer…
There’s Got to Be an Easier Way
I offer the following tips, each requiring only a few extra moments upfront and yielding hours saved downstream:
Be really explicit
By that I mean “state clearly and in detail, leaving no room for confusion or doubt” – not that other kind of explicit, get your mind out of the gutter)
- Detail the expected “Next action towards Done” (What)
- Avoid pronouns – somebody, it, that, him – use proper names, specifics.
- Keep the flowery prose to a minimum, just the useful facts, please
- Tag a single assignee for the next action, avoiding the bystander effect where all watchers assume the other gal’s got it (Who)
- Give timing needs/expectations for a response (aka deadlines) (when)
- Provide your context by using the word “because” (I need your input by Thursday because code freeze is Friday.)
- Don’t say “in the ticket” in Slack – since you were likely just in there, do your receiver a favor, copy/paste the URL. Make it easy for them.
Focus on the right problem
- If you feel frustrated or see that tempers are flaring, do your best to focus everyone on attacking the problem, not each other. Oh, and maybe while you’re at it, take a moment make sure that everybody agrees on what the problem is you’re trying to solve...
Limit the number of unfruitful volleys
- After two or three back and forths, find an alternative way to communicate. It’s amazing how much information can be shared in a 7-minute Zoom or Google Hangout (as opposed to a 50-minute Slack flame war.) Zoom and Hangouts integrate nicely w Slack, btw. (And, yes, technically that will be a meeting but not all of ‘em are bad…)
Maintain a single canonical source of truth
- Keep what “Done” means in one common spot that everyone agrees upon – in the JIRA description field, or in the initial git issue comment. Update the Google doc and resolve the comments. It should not be necessary to read everything every time top to bottom to know what’s current.
- Minimize 1-1 threads or DM slack channels. Emails only end up in addressee’s inboxes…no one knows what’s in that DM or email chain or sidebar convo that they were not part of…
- And I bet you can comment below on many other techniques that you find valuable (Hey, add some now, I’ll wait…)
Be a Model Citizen in Your Asynchronous Communication
I’m no angel, but I am doing my best to model these behaviors with the teams I serve. And when I see problems surface (that illusion of communication) I take the opportunity to provide direct, timely and specific feedback… without being too much of a PITA I hope. “@Jane, please assign the card to @Tarzan next time… that way he’ll have less of a chance of missing the fact that he’s got to take @cheeta to the vet on Saturday…”If we all just slow down a bit, we might actually speed things up. Click To Tweet