In either case, to what degree would Slack allow Stripe to replace email altogether? It seems set up to solve many of the problems their email system was created for.
However, email hasn't gone anywhere. As soon as you want to interface with the outside world, it's a hard requirement. It's also pretty hard to beat a lot of the properties of email: arbitrary-sized blobs of text and attachments that are fully searchable, taggable, organizable, and have read/archive states.
I think everyone would love to see an email killer come along (and I'd love if that were indeed Slack), but thus far I haven't seen anything come close.
Can you explain this?
I've heard this sentiment before and never really understood it. The common complaints I hear about email are usually inherent in the fact that it's a universal communication mechanism[0], or a symptom of inadequate clients[1].
I can understand the need for better email clients (that's what Gmail originally was, back in the day[2]). But I still haven't been able to find a compelling reason that email itself is fundamentally broken in a way that requires a new system altogether.
EDIT: I should acknowledge that privacy and security are obviously a major issue, and email is by design incompatible with security (Silent Circle tried this and failed, which is why they are creating an alternative protocol). But I generally hear this complaint in other contexts, so I don't think that's the reason.
[0] e.g. "I get too much of it" - thirty years ago, people complained about getting too much physical mail, simply because that's the way all important work was conducted then (dead trees).
[1] Having email clients tailored towards email power users can make up for problems like overwhelming volume - Google's "Inbox" app is an example of this.
[2] Along with providing massive amounts of space (which was itself a hard requirement in order to provide the many client-side improvements it brought).
I encourage lists at work but the first objection is often around our "need to know" security policy, thanks to ISO.
Can you speak to how you bring transparency to things like this?
One of the biggest problems we've found with using email transparency for "early discussions" is that it's often actively harmful (totally orthogonal to the content of the conversations). For example, we once were considering doing a particular acquisition. We approached it with full email transparency internally, sending on-list emails before we'd really figured out the parameters of the potential deal.
Immediately, people started to express strong opinions in favor or against it. We had a full-company sitdown to talk about it, but it was really weird because it was all just hypotheticals. Ultimately, we burned a lot of time on it, and the deal was kind of dead in the water due to this approach.
The list of exceptions are the cases (either found empirically or through inspection) where "absolute transparency" can be harmful. It's kind of like the "shouting fire in a closed theater" free speech idea — you should make sure your transparency mechanisms don't cause unnecessary emotional turmoil.
On the other hand, there tend to be good alternative mechanisms to make these cases transparent, such as talking about them at your all-hands meeting, where you can provide additional context and discuss in realtime.
This sounds like the sort of problem you solve with a policy, not by breaking the enabling technology. What about just telling your employees that nascent partnerships—like nascent microservices—start out "owned" by the people exploring them, and everyone can observe their development, but nobody has an implicit right to have input on them until they get to the "release-candidate" phase?
Why is this excluded from transparency?
