Unclear Asks are Killing your Team

We've all been in a meeting, wondering what the goal was, and why we were invited. Some of us have even gotten up, said something, and left. The truly bold may have suggested ending the entire meeting and reconvening with a plan.

We've also all gotten an email addressed to six or seven people, assumed someone would handle it, and moved on.

I've seen a few people circulating this medium post that blames asynchronous communication like email for wasting time. But the problem is not asynchronous communication, the problem is unclear responsibilities. And it manifests in all sorts of ways beyond email.

There are two facets of this: vague requests and diffuse responsibility.

Vague Requests

To start with the given example, an email to five people on a design team:

Hey there! Wanted to get some quick feedback on this presentation; esp. slide 7. See attached.Thanks so much!

Of these five people, no one knows what the author wants them to do.

• What is "quick feedback"? Is this 30% feedback where the whole structure up for revision, or 90% feedback where they want a proofreader?
• When do they need this?
• Of the five people, how should they divide this? Should the lead designer look at the content while the junior designer punches up the visuals? Do all five need to look at everything?
• Is this a collaboration, a sign-off, or an FYI?
• What's the right way to provide feedback? Is it to edit the deck and send it back, provide notes? (NB: using attachments instead of collaborative tools is killing you, too.)

The suggested solution is to lean toward synchronous meetings, in a case like this, preferring to ask one person for a few minutes of sync time. But that's a bandaid over the problem. Synchronous meetings won't save you from deciding and communicating what you need.

Diffuse Responsibility

Asking something of too many people is the same thing as asking no one.

I've seen this happen over and over:

• Unmanaged mailing lists for inbound communication. Who should answer? What happens if two people answer at the same time, or differently? If there's an action to be taken, who gets assigned to it? (If it's a full-time job to answer these, as in a customer service team, the list is probably managed as a queue and routed to different members somehow.)
• Undirected requests for code review. Who are the appropriate reviewers? When will they get to it? (Often this means a pull request or patch sits around until someone begs on Slack/IRC, at which point a dogpile of review happens, some of which take too long to be meaningful.)
• Meetings with a lot of invitees. Why is each person in the room? Can or should I delegate this, and get a summary? What are the agenda and goals?
• Emails with too many people copied. As in the original example. This one is pernicious because it often comes from upset stakeholders who think someone will answer them, or who are trying to escalate an issue but aren't using the "proper" channel for some reason—e.g. they don't know or don't trust it.

Again, you need to decide and communicate what you need.

Each of these scenarios can be addressed in different ways. The mailing list (I've been on a security@ mailing list with this issue) may need some kind of rotation or schedule. Code reviews should be assigned—not to too many people, each assigned reviewer should need to do the review or ask someone to replace them (GitHub's "suggested reviewer" and "requested reviewer" tools can help with this). Meetings absolutely need agendas. RACI matrices are incredibly powerful tools for making reasons for including people clear.

Panic emails are tricky if they originate outside your team, though you can still communicate expectations and areas of ownership internally that can help.

Asynchronous Communication is Critical

It is worth your time to learn to do asynchronous communication well.

Increasingly, the nature of work is distributed. While sometimes this means across state lines and time zones, it may simply mean the ability to be productive from home with a flexible schedule sometimes. This is an important inclusion issue. If you want to hire senior team members—particularly women who are often disproportionately responsible for childcare—who are more likely to have family obligations than younger people, an hour-long doctor's appointment or parent-teacher conference shouldn't be the difference between a productive day and a wasted one.

Interrupting flow also costs disproportionate amounts of productivity. This is one of the chief complaints about Slack and why I impress on my teams that anyone should feel OK muting and quitting it for a while to get uninterrupted work done.

And if you need a few minutes of someone's time, synchronously or not, there's no reason to demure on the details. "Ping" doesn't get you anything but a "pong," while "hey, who's the right person to talk to about event details?" can get you an answer. Not only does excluding details make people anxious, it prevents them from preparing, even if it's just "ok putting on my feedback hat." Sending an email that says "hey can we chat for 15 minutes about some structural issues I'm having with this presentation?" let's the recipient know what they'll be doing, and compared to "hey can we chat for 15 minutes?" is far less terrifying.

The original post recommends using short, synchronous conversations, but these are effective only insomuch as they are forcing factors to actually do the work. It also recommends, well, doing the work: "Bring clarity to asynchronous asks", "Give every (t)ask a time limit", "Put structure around collaborative editing tools".

If you ask five people to get in a room or video call for 5 minutes (which will take 20) with no clearer question than "hey look at this plz," you'll get no better result. If you clarify your ask, you can still put it in an email.