Hacker News Reader

Comment by raganwald | Hacker News Reader

I have been building custom office automation software for some little time, and the reality is that any new system is always trying to wean people off managing all their communication and process by email.

Even as we speak I am building something for a client and we are taking the view that writing things on "walls" and commenting on "stories" just like Facebook as some potential for diverting information from email into the app. We don't know if we're right, but that's how we're betting.

We could simply tell people to use our app for everything, but my experience is that if whatever you build is dictated by managers in the hopes of straightjacketing people into some new process, they will route around it using email as a back-channel.

To beat this, you have to be better than email in some way that the users themselves appreciate.

View on HN

The problem with trying to force people out of email is that everyone

a) Knows how to use email

b) Has access to email

Don't underestimate these things. If I'm at home and I need to log into a company VPN just to update my status for my manager, that's a lot more effort than sending off a quick update via email or just picking up the phone.

Conversely, if someone asks me for some help on a project and then asks me to learn an entirely new system for an hour of my time (including new logins, new bookmarks, possibly installers, etc) it is often a net loss for me and for them - by the time I am up-to-speed I am done with what they needed anyway.

Basically, I am happy to use whatever system can help me do my job better, but too often I am forced to drop back into email anyway. Eventually I am trained to just use email first, because once your tool gets out of sync, its usefulness decreases.

Plus, email works on 99 44/100ths of the available hardware and software platforms, natively :-)

Considering that 37signals products are web-based, they also work natively on a pretty large percentage of available hardware and software platforms (at least the ones you're likely to be using).

True, but people are already using email. Everyone knows how email works and how to attach files. Not everyone knows what a "writeboard" is and how it's different from a "message"

I agree fully that everyone knows how email works, and I'm not debating the point that email-capable devices outnumber javascript-web-capable devices. I'm questioning the point that because there are more email-capable devices, email is a superior medium for project communications -- because there are enough devices with modern web browsers to let people use more advanced tools.

I agree that web-based solutions could reach enough people for them to be a feasible replacement for email in terms of availability. The point I was trying to make by talking about access is that everyone has an email address I can send mail to, but generally access to project-specific tools are limited to folks on the project. So if I hash out an interesting technical approach with someone outside the project or outside the company, it will likely be done in email or via the phone.

Once I have resorted to using email, eventually I will forget to move a conversation over or I don't think it will be important and our "repository" has gotten out of sync, which leaves me with a merging issue (do I trust what my email says or the website), and eventually a duplication of effort (I know we talked about this, but my email says x, and the website says y)

As an aside, as I was writing this, I also realized that I tend to use email as my "archive of knowledge". When I move on to a new project I can search back through my email to find relevant discussions and apply them to my new work. I have not seen a tool with a similar ability to archive and take with me my lessons learned (whether because of company policy or lack of feature in the tool). I know lots of managers who religiously archive their email to avoid losing some obscure piece of information or process from years ago.

If "works" is reduced to the act of shuffling 7-bit characters around, then sure, and indeed, that's a big chunk of what e-mail does.

But trying to make sense of a large thread from five months ago with reply from many people (with little, or at least varying, ideas of quoting etiquette) on many different clients and platforms is not my idea of anything "working"...

email is a very generic communication, and in my opinion, it is possible to build tools on top of email that can give every collaboration/crm/project-management tool in the market a serious run for their money.

Every email front-end now supports extensions/plugins (for gmail, its gadgets+contextual api or DOM scraping), and of course there's imap to interact with the data, labels, headers and attachments. These two together yield a lot of potential to build a lot of tools that can be very useful.

We have built GrexIt (http://grexit.com) which allows Google Apps mail users to store email discussion from their inboxes to a shared area, where others who were not a part of the discussion can see them. This helps our users very easily create a knowledge base out of their work email. Some of our users are also now using GrexIt as a collaboration tool.

And the problem with keeping things in email are numerous and insidious. Consider:

email hides embedded knowledge and frail processes (Jane asks Bob for A in an email and only Bob knows that B and C are implied when Jane asks. If Bob is out, the process to ask for A can be completely paralyzed.)

no actionable meta-data (no easy way to harvest project name, members, status, dates, etc. Good luck trying to find out who you need to invite to an integration-of-two-systems meeting.)

no easy way to bring new people up-to-date, save massive retyping.

no easy way to know current progress without sending out a mass request-for-status email

history tracking problems (all it takes is one or two people to not hit reply-all, for an email history to be completely untrustworthy from any one inbox)

Naturally, people should aspire to make replacement systems as easy or more easy to use than the ones they replace. But email being easy is never a good argument for leaving a process in it. Particularly not project-management tasks.

Absolutely. With email, business knowledge gets hidden in someone's inbox. It's of absolutely no value to the business in there.

It's a hard sell to get a business to change its behaviour and keep its information elsewhere where it can be shared for the greater good.

It's a big problem for a business.

Please don't mistake my comment as an argument for using email in all situations. I think that source control is widely accepted and about as frictionless as it should be. There are a variety of task-management tools and processes that can be used pretty easily within a team and also generally hit about the right level of friction. I love being able to integrate the two and further reduce needless friction. It is all the different discussions and conversations that go on around those items that are difficult because I don't want any friction in those discussions. I should be able to see what my client thinks of the new GUI, or ask an old roommate of mine to review some performance-critical code and see how he would approach it without requiring them to create a new account, get access from IT, purchase a license, or any of the other impediments usually placed on using these sorts of tools.

Basically, my thought is that if you are attempting to compete with/replace email, you need to address the friction issue for those items. Otherwise people will eventually revert to email at which point updating the repository becomes another item in the todo-list, and the reality I've experienced is that it will ALWAYS be the bottom item.

In short, I agree with all the problems you cite, I simply have not been able to experience the ideal because none of the systems I have attempted to use reduce the barriers to communication sufficiently to replace email.

Reply on news.ycombinator.com