I've known companies that had pretty good email policies....until they got sued and every email debate was turned into the evidence that they knew X or considered Y or thought about Z and were therefore guilty. :-(
Hi (I'm Stripe's lawyer). Litigation discovery is something that any company needs to think about when crafting its email policy. But whether an email goes to a few individual recipients or to a broader list won't impact whether it needs to be disclosed in discovery. The seemingly private email between two or three co-workers will almost always persist in someone's inbox for a very long time, and ultimately be discovered.
In most cases, the kinds of emails you are talking about -- where someone says something that can be mischaracterized or otherwise damaging to the company in the future -- are a result of poor judgment. And that's where I think Stripe's policy has a distinct advantage. When people know they're sending things to a broader group of recipients they tend to be more thoughtful in how they communicate and just avoid saying many of the imprudent things that would be troublesome in future discovery.
Random question relating to both e-mail and the law...
So everyone puts these signatures/disclaimers on their e-mail now which say (paraphrasing):
> This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing deadlines as incoming e-mails are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.
Or similar. Do these things actually have a legal purpose/meaning? I mean can you really enforce a contract the other person hasn't agreed to? Can you really demand what THEY do with an e-mail YOU sent them?
A few years ago I thought this stuff was silly but now a lot of big companies are doing it and I can only assume these companies have a legal department...
PS - If you were to reply I wouldn't assume it was legal advice, I am asking you as a person who just happens to be a lawyer, not as a lawyer. :)
I think people do these things mainly to deal with inadvertent disclosure (e.g., an incorrectly addressed email) or further downstream distribution of an email. The idea is to have some indicator that the original sender meant the communication to remain in confidence (which may be required to maintain, for example, attorney client privilege, or to preserve trade secret protection). When they are affixed automatically to every email (as they are by many firms), I really doubt they work. I'm not aware of any case where the existence of this kind of disclaimer has been a factor, and I suspect most people put this in the "it couldn't hurt" category, rather than really thinking it'll be effective. Would be interested to hear if anyone is aware of evidence to the contrary.
They are effectively worthless if it can be shown they are added automatically to every mail. Privileged communication requires something explicit or genuine intent, i.e. the sender writing 'privileged' at the top. It actually can be quite bad if it's shown that the privileged communication was abused (either in terms of piercing all veils or censure).
My experience is people add these signatures because they see other people doing it and they assume it's a good practice or seemingly professional. It may be some inexperienced lawyers recommend it so they have something to say about email policy. It's not hurting anyone beyond eating up mail quotas, right?
Hey John, that's pretty much what I found when I did an explainer for Wired about them:
“You have no obligation to obey the disclaimer if you decide to read a misdirected email, send it to your friends, or send it to a Wired reporter,” says Susan Lyon, a privacy and data security attorney for Perkins Coie. “You don’t have to worry about that.”
I would imagine that this open email policy actually reduces the amount of lawsuit-relevant emails in one sense:
If you want to talk about something sensitive or private you would probably pick up the phone or walk over to the person, knowing an email is shared with the entire company.
Full disclosure: I've worked on eDiscovery products and may be biased. This is a net good thing, I think, for a company to reduce its dependence on arbitrary communication that is written and backed up forever.
This is a real risk. One company I worked for had me modify already sent and archived emails and Yahoo Messenger logs to remove incriminating evidence in preparation for an expected unfair dismissal trial. And also conveniently 'lose' the backup tapes for the period where the original data existed. Thankfully it was settled out of court.
Mind you, the dishonesty was rife there. The boss had me scan in his cellphone bills and edit to remove all records of calls to his mistress, so he could print them out (as 'photocopies') and prove to his wife that he wasn't cheating on her.
Kind of regret all that now, but payment alleviates conscience.
"Every person who, knowing that any book, paper, record,
instrument in writing, or other matter or thing, is about to be produced in evidence upon any trial, inquiry, or investigation whatever, authorized by law, willfully destroys or conceals the same, with intent thereby to prevent it from being produced, is guilty of a misdemeanor." (Cal. Pen. Code. S. 135)
What if the paperwork in question isn't being used in an investigation, but rather as a way of proving residence in a particular area for the purpose of receiving services provided in that area?
Pretty sure that the laws of all 50 states considers that to be fraud.
If the person committing the fraud is poor however or very young, the will to prosecute the fraud is often absent, but you cannot count on that.
For example, someone was prosecuted here in California for helping a friend without health insurance obtain medical care by trying to get the hospital to believe that his friend was him.
I agree. This was years ago - I wouldn't do it now as I have financial freedom and (probably) a higher standard of morals. But back then, keeping my employers satisfied so my sole source of income was safe, was a large motivator.
"We use Gmail for email and Google Groups for lists."
"What we have today works pretty well for our current size—around 45 people."
So if I can manage to get the Google authentication credentials for just one of Stripe's 45 employees, I can get access to the vast majority of Stripe's email? I hope they require two factor authentication.
Yes, we do require two factor auth, and we're very stringent about laptop security generally. We're pretty cognizant that, even at a less open company, compromising any employee can generally be used to obtain a surprising amount of sensitive company information.
In light of this issue, what have you done to restrict the amount of harm that even a trusted employee can do? I'd be happy to learn that after a suitable time period for disputes, literally no employee would be able to provide any demographic info related to a particular charge. You can't harm my customers if you don't have access to their data.
Yikes. I was just skimming HN before a meeting to talk about how we are going to handle payment flow. Literally just put a huge question mark next to Stripe on my list now.
A compromised employee machine will always cause problems. (Just look at Google, the New York Times, etc.) We're obviously careful about what goes in email, and I think the open-by-default policy largely makes the security properties of email clearer. (I.e., don't put sensitive material here.)
Very cool experiment. How do you deal with less technical people in the team who don't find it fun to tweak email filters all day long? Is your tooling to the point of polish where that's no longer an issue? Or are you simply at a stage where you don't (yet) need to hire non technical people? We've found this to be the main obstacle in getting full adoption for things like this.
Speaking as a non-technical person at Stripe, the google groups web interface good, but not great. Andreas on our team built a filter manager, which makes it much easier: https://github.com/antifuchs/gmail-britta
I was all set up with filters on my first day and then made tweaks over my first couple of weeks to improve efficiency.
This is cool. We had cargo-culted the idea of open email and CCing the entire company at CircleCi, so its great to see the details exposed. Looks like that structure will be really useful once we get a few more people.
Lists work well to a certain extent but would not be suitable for a number of cases. Say a team member decides to add an existing email conversation to the list at a later point in time. This would break the original email thread structure when added to list. What happens to an email in a conversation which came from someone outside the company. Someone forwards it to list again? Say someone forgets to do a "reply all" in an ongoing conversation, this email never lands up in the list.
We like using email for most of our tasks too. We use our own product GrexIt's (http://grexit.com) Shared Labels to share information and even collaborate right from our email inbox. Shared labels allow you to share particular Gmail label among a group of people in your company. Every email conversation on which a shared label is applied gets pushed to the user's inbox who were part of the shared label. All followup emails that arrive in an ongoing conversation also keep getting shared automatically. This approach requires minimal effort to share information and works better than lists. Most importantly users continue to access information from their inbox itself.
We use the shared labels approach for a variety of use cases like support and development. As soon as support email arrives to the support@ email-id it get shared with everyone. We have shared labels with every team member's name, say Task:John. To assign an email to someone, we simply apply the user's shared label on that email. This allows us to collaborate easily without needing any
3rd party tools
We've tried Yammer, and it's never really taken off. The nice thing about just copying an email to a list is the barrier to entry is so low -- the sender doesn't have to open a new tab, or create any additional content.
Nearly all of these use cases are covered by a number of social enterprise platforms such as Yammer or Socialcast without the need for new employees to setup filters.
In Socialcast activity streams can be filtered by groups which could be public, private or externally facing(meaning you can invite people outside your company to participate in them).
People can be notified directly by @-mentioning them in your posts and so forth.
And of course all the content is searchable and filterable.
The usefulness of these social enterprise tools was not clear to me until I saw it being used in both a 40-people company and a 13,000-people company. It brings about collaboration, transparency, a way for people to discuss their issues and to often vent about things they dont like.
Maybe its time for Stripe to check it out too :)
Disclaimer: I work for Socialcast, the VMWare company
This is an interesting tactic. I think it can work well for companies up to a certain size, at which point new hires start getting auto added to certain lists and you start to have enterprise email issues (I think Stripe will manage to avoid this fate though) ;)
This is a timely article for me though. We actually did a Show HN earlier today for a product (lightermail.com) whose ideal use is exactly this scenario. It allows people to control the flow of email from specific senders or domains. We see it being ideal for companies who have these sort of mailing lists, because it allows employees to subscribe to all the relevant lists without getting distracted by all the associated email throughout the day.
Good luck with your experiment! It will be interesting to see how it goes.
I'm curious about your thoughts on mailing lists vs. private newsgroups. I think of email and news as just two different ways of sharing MIME messages, with the difference that email is sent to specific people and newsgroups are stored on a server and can be archived and made (semi-)public.
I realize that newsgroups have received much, much less attention than email recently, and it may just be that there isn't enough software support for news to make it worth bothering with, but it does seem like a mailing list with archives is a lot like what news was trying to accomplish. (The only other big difference I can think of is push vs. pull notifications. But newsgroup readers can fetch all new messages, so I don't think that's a big deal.)
When I was an engineer at Google, most Googlers tended to handle the email the same way. And of course, all 50k+ employees used the same Gmail and Google Groups as you and me.
I absolutely loved the system, and I've convinced my startups and organizations use solely Google Groups to communicate as well. Especially as an engineer in a company with thousands of simultaneous projects, it was extremely helpful to have a searchable archive of every conversation or set of meeting notes that was relevant to something I was working on.
The legal liabilities, however, that this system could obviously bring up, as greggman mentioned, are an entirely different conversation.
How do you handle customers' emails? Is support@stripe going to a "support" mailing list? How do you make sure every email is answered only once? I.e. that all the team can see the conversation and can opt-in optionally. Thanks!
Support emails do not go to the support@ mailing list, they're handled through a helpdesk management tool that allows us to see full contact history, etc.
Part of the issue around transparency is that email inbox silos may be the wrong tool for a collaborative and productive tech company.
In general, email is now being seen (as often remarked by ShowHN MVPs) as To Do lists, and in a tech shop, multiple people have an interest in that process. This results in unenforceable policies about To: vs Cc: and unwieldy threads you're never sure if you should delete the tail nested indent history from. As the ShowHN projects assert, email's a poor To Do list tracker.
To refine that slightly, emails tend to be requests.
You don't create a new email thread to give yourself a To Do item. You create a new email thread to ask someone for something. The recipient doesn't care about your agenda. You're the interested party asking, and you need to track your requests.
Employees and clients email requesting action from someone: do this for me, let me do this for you, give me a resource, read this, take action on this, file this, and of course, receive a copy of this to cover my ass. Your To Do items (emails) are now in their lists (inboxes), and once there, you've lost control over the prioritization and handling of them. You'll probably lose visibility too, the moment you stop getting CC'd on your own email thread.
So, we quit using email.
Instead, we use Request Tracker, tracking all those requests. Instead of the Inbox, we have the RT dashboard, backed by automation with full extensibility:
We all use it, and clients are trained (by sales, by contract, and by firm account managment and support response) to use tickets for anything as well. If there's no ticket, you didn't really request it. RT makes this easy, because the client can still just use email -- there's no web interface (well, there is, but they don't have to use it) for them to have to learn. They can just email a team (internally, an RT "ticket queue") and be sure the team will sort out who's handling it with an SLA promise.
If someone on a team has a family emergency, it's no issue, as anyone else on the team can take over that person's tickets till they're back, and immediately see the whole history.
All this is public within the company and fully searchable, going back about a decade.
When I said above we quit using email, I lied!
We actually all use email, but what we're emailing are RT tickets. So throughout the day, we can use any email capable device in the world to interact with this shared request handling history. RT automates the history and the cc lists. You can search your own requests using your email client, or hit the web interface to search everything. Through the web interface we enjoy the benefits of the dashboard summary, automatic response SLA monitoring, cross linked issue tracking, and visibility/searchability by everyone.
Note that RT can pick apart email addresses and subject lines, so you can route all your RT queues through a single Gmail account if you want, spam protecting your system and giving you a master archive searchable using Google's search tools as well.
Stripe is essentially slowly reinventing Best Practical's Request Tracker. Might be worth giving RT a try.
You don't create a new email thread to give yourself a To Do item
Maybe I'm just weird, but I do this pretty frequently (fire off quick instructions/reminders with "TODO:" prepended); after all, there's very little besides email that I care enough about to check frequently enough for any action items I assign to myself to matter.
I understand and agree with the idea behind the "Show HN" projects you mention, but as a potential user, at the end of the day all I really care about is that my personal system/workflow works and helps me get stuff done, not how structured or semantically beautiful my data is. The last thing I need is yet another application/service to demand time/attention from my day.
(On a similar note, I've never been able to commit myself to a well-organised file structure with meaningful nested directories, an indexing system, and so forth, when a flat directory holding tens of thousands of files + ls and whatever regexes has Just Worked for me for years, despite not being pretty.)
Maybe I'm just weird, but I do this [send emails as todo items] pretty frequently (fire off quick instructions/reminders with "TODO:" prepended);
It's also something that I do indirectly via Google Now or Samsung Voice - launch it, say "Note to self - Fix a time with Patricia" or "Remind me to book train tickets". It sends an email to me with that content.
I've used Request Tracker, I actually installed it at an all-Microsoft consulting firm ( http://www.pcubed.com/ ) around 2005.
Pcubed loved it, most of their consultants were out in the field and email was the only tool that we could guarantee that they all had access to. yet we could ensure that everyone involved with a client was included in any conversation about the client. Yes most would just filter these into folders so that if need be they could look things up, but what really made the difference was being able to manage meta-data and ticket state around the emails so that we could see that risks were mitigated, issues addressed.
Virtually no-one used the web interface in RT (except admins to configure new client emails and add users), and that was no surprise to us. We wrote a custom backend that would pull the data and dump it into SQL Server and then SharePoint and Reporting Server... for a Microsoft shop these were the tools they wanted, user controlled reporting capabilities and visibility in the place they were most likely to look (SharePoint).
RT is good, but it is a bit long in the tooth... have you seen http://copyin.com/ ?
CopyIn is not an RT clone, but it does provide group based email addresses, with a web front-end, wiki-spaces for those groups, and so on.
It's about a year old, started by a YC alum who is on here ( https://news.ycombinator.com/user?id=petenixey ), and currently in a closed beta, but from what I've seen (a demo) it brings a very fresh approach to this whole problem space (email-centric group awareness and collaboration).
I'd say it's worth anyone looking to implement this stuff to ping Pete Nixey and see if they can get on the beta.
And as others are asking for disclaimers, I work for neither RequestTracker nor Copyin, having only implemented the former and seen a demo of the latter. Pete is a London based founder and I've met him quite a few times. I gain in no way from you choosing to use Copyin, but perhaps we all gain by a nicer tool emerging and getting established in this space.
I remember during the late 90's early 2000's RT was used in almost every NOC because it was one of the few options available.
From the screenshots it looks like it hasn't gotten any better since then. Are you sure your positive experiences aren't just from lack of exposure to newer tools?
I wouldn't confuse the interface with the engine. Under the hood, the advances have been significant over the years.
Best Practical isn't a web design shop, but you can certainly spend time making this pretty if that's a good use of your time.
As noted in a sibling comment, we do try new alternatives constantly. Haven't found anything else that comes close for the seamless email integration, ticket volume, and workflow flexibility we need.
Also as noted in sibling comments, much newer companies than us, tech stars you've heard of, have found RT useful quite recently.
I believe I just shared that. Our company's used RT since 2003.
Over the years we have also tried ZenDesk, Tender Support, etc. They have their place. For example, I like Tender Support for adding help to a small end user facing SAS web site.
But RT can provide automatically structured metadata for extraordinary volumes of internal, client facing, and end user facing email.
If you email some company's support address, and get an email with something like "[company #12345] Your original subject" in the reply, and you can simply reply to that without quoting the original and without any "paste your reply between these lines" nonsense, there's a decent chance they're using RT.
And then, too often, you need to speak to the sender to find out what the email actually meant in the first place, only to find out that it had no relevance to you.
I like the info sharing and should lead to increased efficiency, but its something that IMHO needs very careful scrutiny.
I have been working on this use case of private/shared email and have been testing in private beta for a year with a firm of 40 staff. If you are interested, please send me an email (joran@ronomon.com).
