Why Email is a Bad Collaboration Tool 245
An anonymous reader writes "Isaac Garcia follows up his popular "The Good in Email" article with "The Bad in Email or (Why Steve Ballmer is the CTO of Microsoft)":
"In spite of email's universal success (as a collaboration tool), and in spite of its many good traits, email contains deep, inherent flaws that force users and markets to seek alternatives to collaborating via email."
The Real Problem (Score:4, Interesting)
Sort of like posting on slashdot.....
Re:Amen (Score:5, Interesting)
IMHO a simple improvement to email would be no more than twice a day delivery. People would know the corporate email shows up at 6:00 a.m. and 2:00 p.m. Therefore, if that time has passed, you won't get a reply before the next email dump. This removes the pressure on the recipient, who knows he has at least 8 hours before anything has to be done with that email.
A side benefit is that there is only new email twice a day; when you arrive, and mid-afternoon. No more checking it every five minutes, no more boss yelling "did you get my email yet", no little dings/mailbox flags, etc, going off and distracting you from your job. Go a step farther, and let an intelligent agent apply your rules of priority to the message "has the word "superbowl video", so file it under "never"", rather than the sender's, and some of the issues are gone.
For colllabortion between more than 2-3 people, use a Wiki or Notes. Email should be for person-person, ephemeral, communication.
Re:Amen (Score:5, Interesting)
The disease I'd like to complain about today is the "read receipt". I can only imagine how much time people waste looking up whether I've read their message or not. You can turn that off, too, but some people really go crazy if they don't get their read receipts.
IM (or IRC) and Wiki (Score:5, Interesting)
This has been true for me working on OSS at night with a partner in Qubec as well as working in the same office with a developer two aisles away.
The Al-Queda e-mail method for collaboration (Score:2, Interesting)
There is a way to use e-mail as such a tool, which was the preferred method used by the Spanish Al-Queda cell:
1. Open e-mail account (on your own web mail server, preferably) and publish username/password to members of cell/department/workgroup.
2. Write e-mail detailing plan and save as "draft."
3. After connecting by SSL, other co-workers/conspirators view and edit draft or attach comments for all to browse and update.
4. If server is owned by group, files are as secure as the passwords and OS. If a public/commercial server is used, drafts and connection IPs may be discovered and will persist on backups and logs.
E-mail R.I.P. (1968-1999) (Score:2, Interesting)
I stopped using e-mail as my primary form of communications almost 7 years ago (about the time I started using SMS en masse, combined with instant messaging when available). For me, e-mail is no different than TV, radio and telephone -- all technologies that should have been replaced eons ago but for whatever reason have been held back from evolving.
I agree that e-mail is a terrible collaboration tool, but considering when it was "invented" and how few real iterations of change we've seen with in, I don't expect it to ever blossom into a truly useful tool for productivity. I would have to guess that while e-mail is more efficient than a fax or a letter, it is not a telephone replacement, nor is it a replacement for even a simple post-it note. The only collaboration-friendly element of e-mail is the idea that it leaves a log or an audit trail of exchanges, but it is missing all the other important elements for group-think or idea creation.
I believe the future of connecting everyone within a group to one another plus incorporating outside groups into the "conversation" will likely come out of a different technology than e-mail. I see great possibilities in RSS and XML as a platform for long term collaboration, and the Wiki idea is a step in the right direction. Combine both with a tagging feature and incorporate more than just text, and you have a mess of protocols that together can really make a difference for building and sharing ideas. Maybe a little slashdot-style user-modifiable open-view moderation, too. Before any protocol or format can be created that really is the end-all solution, we need the underlying platform to be finalized. We need the Net available all the time, everywhere, at low cost (commodity-priced) and at high speed. I believe that the EDGE/3G networks are getting us closer (I am typing over an EDGE-connected T-Mobile link now), but we're not there yet. When information can be accessed immediately, when notifications can become part of the data stream, and when the ability stream your thought into a final product with anyone else, I think we'll see that product that many of us are waiting for without knowing it.
I've given a lot of thought to collaboration tools of the future, and I know exactly what I want. I just know that even if I implemented it today, most of my workers, friends, co-writers and readers would not be able to mesh with the Wiki-XML-SMS-Slashdot-tagging tree with the speed that I would think is necessary to make that collaboration better than a simple whiteboard and a boardroom.
Another few months, maybe. A few years, for sure.
And a good Collaboration Tool is.......? (Score:4, Interesting)
Thankfully the new project I'll be working will have 2 main developers in the same city so we'll actually have some sit down sessions but so far almost everything is in email. What are good collaboration practices(the article mostly just said email sucks)? For software I'm currently investigating gforge [gforge.org] with the wiki plugin. Does the slashdot community like wikis for collaboration between developers on software development projects or something else? Does all this really get solved when you have a dedicated project manager? Should your collaboration tool also be your project management tool? Any good project management tools(esp. ones that combine collaboration software). Thanks!
Re:Amen (Score:4, Interesting)
In case anyone is interested, here is the setup we had in a little company (now long sold) I setup with friends a while back (I wasn't the one who came up with the idea) to manage the "info" mail account (standard email addresses were still used back then) :
This would let you know who did what and it kept an archive in a platform independent format as well. It was used for other "global" addresses as well.
People could browse news in the same client (Netscape at the time) they used for email, which was convenient. We ran a mix of Linux, BSD, Windows and Irix.
Re:Better email (Score:3, Interesting)
as i saw, ratboy stated that this can not be guaranteed unless all participants comply with common rules or all links are controlled by a single entity.
if all links in an email-processing chain (your mail client -> your computer -> your server -> some other mailserver -> other computer -> other mail client) are working as they should, the message simply will be delivered.
now, wether it will be read... no, read notifications is not a good idea.
generally mail system is supposed to notificate you whenever there is a problem delivering the message - wether it would be unaccessible recipient server, incorrect recipient address, unaccepted content or whatever.
it will usually do this by sending you an email message stating that the message was not delivered and telling you why. in some cases you might get notified immediately, if your server can find a problem while your mail client is talking to it.
once the message has left your mailserver, it's completely the responsibility of other server[s] to inform you as a sender about any problems that result in inability to deliver the message to the final recipient.
phone conversation isn't exactly a good analogy as it's a two-way interactive communication. unless you propose one mail client talking to another, there always will be intermediate servers that will pass the mail, check it for viruses etc.
if you ever get unreliable mail delivery (meaning mail is getting simply lost), that SHOULD NOT HAPPEN. really. contact your administrator, together with him try to find the cause for it. once it is found (you might have to contact destination/sending party), push for it to be resolved.
now, the only case i can think of missing mail (that is not because of some massive network or infrastructure outages that you should be noticing anyway) is spam filters. yes, spam filters that discard messages can cause this, but anyway are controlled by one of the sending/receiving party, thus finding which has snapped the mail and preventing that from happening should be done as soon as possible. and the message itself still must be possible to retrieve from the spamfilter if, for example, it's your organisation's infrastructure that has classified the message incorrectly.
other approach is flagging all the mail and letting it to fall in a separate mailfolder at user's client. that is easy to do with current tools and probably is the best thing to do at your organisation if losing email can be critical and users are sophisticated enough to find the occasional filtered away message (and they have the possibility to set individual thresholds so that one would have more manual spam-hunting to do, other would cope with a mail getting classified incorrectly now and then).
Re:Amen (Score:2, Interesting)
Me personally I try to at least respond to an email asap, but I may not fill the person's request immediately. But everyone has their own service level standards, based on who your customer is and how many responsibilities you have. I think a good twist on your idea would be some kind of autoresponse, not in the form of email necessarily, that would allow you to set the expectations on a response to the email back to the sender, sort of like you can share your calendar in outlook. Something like the profile, but more simple, that indicates when you have access to email, or intend to respond to emails. I'm not exactly sure what form it would take, but that's why they pay the engineers the big bucks.
Re:IM (or IRC) and Wiki (Score:3, Interesting)
Incidentally, MeatballWiki has a great page that summarizes the role that wikis can play in a corporate environment here [usemod.com]. It's worth a read if you're thinking about deploying something like this.
Re:Amen (Score:3, Interesting)
Re:Amen (Score:1, Interesting)
I used to work as a developer in one particular nightmare shop (small family-owned business). One of the problems was that my boss, the owner, would email me every ten to fifteen minutes with a new job that was always "urgent" to him, but in reality, had absolutely no urgency whatsoever, he was just impatient. So every ten to fifteen minutes, I had to stop what I was doing and respond to him.
My solution to this was to set my mail client to check for new mail once every hour. His solution to my solution was to email me, then phone me up to tell me what was in the email.
<goldblum>Idiocy always finds a way.</goldblum>
<gilmore>PHB's view twice-a-day-delivery as censorship and route around it.</gilmore>
Missing the point? (Score:2, Interesting)
Blaming Microsoft because they've added things to make it possible to collaborate badly is just silly. They've just added a pink bun warmer to a honda civic. Extraneous and barely functional? Sure. Their fault this doesn't make it the perfect hot dog stand? Not really.