The Email-to-20-Teammates Problem
In his rather nerd-famous Google Tech Talk "Inbox Zero" Merlin Mann takes question from the audience (Google employees). The issue in question is stated like this:
With a work account, frequently someone will email your team. And now there are maybe 20 people that could respond to this issue. So you might look at the email and you might say, well, I could respond or I could wait for one of the other 20 people to respond. – (around 48:28)
Interesing. I decided to build and publish TightOps for exactly this reason: Even though people 1) have the tools and 2) can operate them fluently (we are talking about email and Google employees), there still is confusion or ignorance about “what goes where”.
Stop the Madness
This isn’t just a minor problem, in fact. I see TightOps as a diagnosis tool which will help you indentify the problem and fix it. Here’s how I would proceed.
As we have not enough information about the content of the email in question, it sound as if it is either
A) a question, or
B) something that needs to be done (by someone on the team).
Following the model of the Communication Channel Code, this translates into the two categories
“collecting information” and “delegating work”.
If you need some information 1 , you should have a better understanding of where (from whom) to get it specifically (even if there are more than one possible sources) than to blindly address 20 teammates. Still, sending the email to 20 people, might not necessarily be a sign of laziness. I would suspect that this approach has a different reasoning: The sender wants to ask one / some of the recipients and inform everybody else at the same time. If that’s the case, the first improvement is to either split up the two parts, meaning, ask for information and spread the result separately. Or, depending on the details, choose a better communication channel, say the task manager, where you can assign a task and manage who will get notified about that task and its result / completion.
If this email really contains something like, “Something is broken. Who can have a look at it and fix it?”, that’s no good for sure. First, even in a fairly non-hierarchical structure, there should be a way to take on tasks / work from a list (like a backlog). Better even, there has to be someone responsible for delegating and coordinating work, a project manager or product owner.
It’s just not helpful to publish work in the form of an email to 20 people. There has to be a better system in place for this to happen.
The Dilemma (that is imposed on the recipients)
The person asking the question in Merlin’s talk also brings up the dilemma he is facing. As he knows that not answering (immediately) might be the best available tactic, he basically says:
There is some advantage to waiting to prevent everyone from responding simulaneously.
Because, either a) somebody else takes care of it or b), by ignoring the email for a while, he helps to avoid more chaos as there is a chance of multiple people replying at the same time which would create interference 2 .
I see three things you need to change to avoid this:
- If this is about something that needs to be done, add it to the task manager.
- If this is about collecting information, address the people who have that information directly and gather / process that information, then inform the team.
- If this is not simply delegating and informing, it might be part of a more complex decision. In that case, I’d suggest to gather all information about it, background, problems, possible solutions and then write it all up in a memo.
It’s Not Really a Problem With Email
As Merlin also points to in his answer in the talk, this has little to do with how you personally manage your email. It relates to system and processes in place. And I certainly think that the TightOps framework is fit to diagnose, fix and avoids this kind of problem.
Information in that sense is not to be confused with a decision. If you’re looking to make a decision, you have to choose other means / channels than if you’re simply collecting some information about X. Information gathering usually happens in preparation of decision making. ↩
That’s the difference between email and chat: You don’t know if and when the addressee will get, read and reply to your email. For chat communication, you usually know a few minutes later whether or not someone has received your message and will reply to it or not. ↩