a16z Podcast - a16z Podcast: Tools for How We Work Today

Episode Date: February 11, 2015

You've heard the story: Slack began as a game. But almost exactly 1 year ago today, the internal tool the team built for its own use became a team communication app that anyone (and especially enterprises) can use -- and is now one of the fastest growing ones at that. It seems like collaboration is "something software should be helping us with” Slack co-founder Stewart Butterfield observes, yet it typically isn't. So what can an app like Slack tell us about how we work today, and how the nature of work will change (fewer meetings? less emails)? Butterfield is joined in this edition of the a16z podcast by a16z board partner Steven Sinofsky and a16z's Benedict Evans. The trio examines the origins of messaging and task management tools (many of which Sinofsky worked on at Microsoft) -- and how the advent of cloud-based services and mobile in particular have changed the requirements for modern workplace tools and information management. The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

The content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Good afternoon, everybody. My name is Steven Sinovsky, and I'm here with another edition of the A16Z podcast. Also with us today is Benedict Evans, and also excited to have Stuart Butterfield. the co-founder and the CEO of Slack. And so today we're going to do a product-focused discussion talking about what's going on with Slack, where it came from, and really try to focus on the product and what it is. And so first of all, we'll just kind of dive right into it, and that's sort of a dozen questions for our Stewart.

So first, good afternoon, Stuart. Good afternoon. Thanks for having me. Sure. So let's first go back before you had Slack up and run. running, both the company and the product. And when you were just part of another organization or a larger organization, how did you personally go about sharing information there? And I'm guessing it was a lot like a typical company thing, like email, and it was slow and painful. Because I think that's going to be important in the genesis of how Slack came to be as a product.

I think there's an ongoing joke about software developers and software designers that among the very first apps that they wanted to crack are either a replacement for email or a to-do list or a little bit of both. And I think that's been ongoing in my own career. I've seen, you know, many times I've stopped whatever I was working on to work on some better way to manage the things that I was working on, all of which have been more or less completely ineffective. And, you know, a lot of the software that's been designed for the collaboration, broadly speaking, which I'm sure we'll get into in a bit, has proven to be ineffective, so it's kind of, it seems like something that software should be able to help us with, and software typically isn't. But I have used ad hoc email

obviously quite a bit. By ad hoc, I mean manually entering the two in the CC or the BCC fields, mailing lists, wikis, purpose belt project management tools, task tracking, bug tracking, and all kinds of stuff like that. The thing that happened for me and for this company that caused us to come up with Slack was really when we founded the company, which not everyone knows was six years ago to build a web-based massively multiplayer game.

Which is the natural evolution for collaborative software as you first built a game. Massively multiplayer games are really hard to make and so they're good warm-up practice for making other kinds of software. Because you didn't know quite what to do so you thought you'd focus a little on building some of the infrastructure to then build the game.

Yeah. So there are four co-founders, all of whom were on the original Flickr team, and we had two people in Vancouver, BC, one in New York, and one here in San Francisco, and no one was going to move. And so the natural thing for us was to use a very old messaging system called IRC to communicate. It was the natural thing because in IRC, the basic form of communication is to send a message to a channel

rather than an individual or a group of individuals. And the channel is something that can exist before the people, people are there and continue to exist after the people are there. Now, IRC is 25 years old. It actually predates the web by a little bit. A little bit kind of wonky. Yeah, I mean, it's a little bit wonky. It's definitely most IRC clients and servers haven't evolved much since the, maybe

early 90s, and, you know, definitely not widely used. I think the peak of popularity was probably the mid, late 90s, something like that, only a few hundred thousand people left in the world who use it. But for some critical things, like, you know, all the HTML standards and things like that sort of took place in that framework. Still popular among the developer community and in particular open source projects. So like I think Linux is still a large of on Mozilla is a giant network of IRC channels. But for us, one of the critical deficiencies was that if I send a message to you when you're not online, you'll never see it. There's no store and forward of messages.

There's no archiving. So the very first thing we built was archiving messages. And once we had archives, we wanted to be able to search them. There weren't good iPhone clients available. So the next thing we built was a way to view the archives through an HTML5 interface. And once we had that, we wanted to be able to post messages from this iPhone app and on and on. So over the course of about three and a half years. Let's just know out there because Benedict's here.

And I think that's a fascinating insight. I mean, like even though it was six years ago, you sort of were like right away mobile. What, I mean, as a bunch of developers, that seems fairly unique. yeah I think it was even then it was a requirement because I'm not unique in this habit and it's a terrible habit and I'm trying to break it but everyone does it first thing I do when I wake up is roll over and pick up my phone and start reading I haven't put my contacts in yet so I'm squinting at my phone and I'm reading these things that are just making me either anxious or angry before I even get out of bed into the shower and for some reason that's a critical business need and so we had to design for that particular use case, making me angry before I get out of bed. On over the next three and a half years, we built more and more little features and tools on top of IRC

because what we saw happening was when we hired the first employees, so the number five at the company, through to the 45th employee, everyone got an IRC, everyone started using it, and we didn't use email at all, and that wasn't ideological, it wasn't intentional even, And it was something that we actually only noticed after the fact.

But the reason we didn't use it is because everyone was paying attention to IRC. So IRC was the one thing you had open alongside whatever your rule-specific bit of software was. And that rule-specific bit of software might have been Excel or it might be Photoshop or it might be because we were making a game, our level-building tool. But in other examples, it could be Salesforce or it could be even an email client. It could be Excel. It could be whatever it is that you do all day. And we found a interesting positive feedback loop or virtuous cycle whereby because people paid attention to IRC, that's where we routed information.

So when someone uploaded a file to the file server, that got announced into IRC. When the daily stats run was ready, we pumped the stats into IRC. When there was a database alert, instead of emailing it or paging people, that went into IRC. And the positive feedback loop was, of course, then people paid more attention to it, and we kept on routing more information. So the game didn't work out. Obviously, we shut it down, and at the point we shut it down, we realized we would never work without a tool like this again. And instead of being a hacky series of kind of jury-rigged fixes on top of IRC

and all these kind of cluges, we should start again with what our dream system would look like from this kind of thing and build that, and that slack. So, okay, so here's an easy one then. So that describes how you got there. It's actually interesting as a story for me personally. Like, you ended up with the same way. We were trying to build the specs for office. And, of course, we didn't quite know what to build.

So we built, like, a spec place to put all the Word documents and spreadsheets. And that became SharePoint. And it was, like, 90% of the time on 10% of the problem, building a tool. And I think a lot of the tools in the space do arrive, arise from that. Here's a pretty straightforward one that I think a lot of times people always find tricky. I think it's really important for, particularly for enterprise products, like, to be able to describe them succinctly and tell people what it is. So what's your longer than a tweet,

less than a blog post version of what Slack is today and where it's heading? Well, you know, I think it could actually fit in a tweet. And there's two alternatives, the half tweet length version or the 45-minute version. I personally don't know how to do anything in a tweet, so I'm all for you, give it in a shot. We say all your team communication

in one place, instantly searchable and available wherever you go. And I can unpack that a little bit, but the first part is all kinds of messages that you might send. So they might include an announcement about a policy change for HR, the spec or the goals for Q4. It might be, I'm five minutes late for this meeting. Can you guys please apologize? Any kind of messaging of that sort from person to person or person to group. And communication that happens outside of the context

of your regular messaging system. And so that sounds a bit weird. But what I mean is, in our case, every time someone tweets at us at our company, that goes into our Slack instance, every time a customer creates a ticket through Zendesk that goes into our Slack instance. Every time someone signs up for the service through our own internal integration, that gets pumped in every time a new team is created. We use PagerDuty for monitoring and alerting, and that will send notifications into Slack as well. When we create a bug, that will get pumped into Slack.

And I can keep going like this for another couple dozen examples. But whatever tools people use, that emit or can be made to emit some kind of message, that can go into Slack as well. The second part of it was instantly searchable, so we put a lot of emphasis into search. So, first of all, just the quality of the search is very good, and we have a unique approach to message search, which we can get into if it's interesting. But I can also search for things like specific phrases that people have used when they're tweeting at us, or keywords inside of help tickets that have been directed us. When I'm looking for someone's Slack account because they mention a problem or something to me, I can search for the email address associated with their Slack account through Slack itself. all those things, rather than going to some separate tool.

And then the last thing available, wherever you go, again, is just mobile. Yeah, it's interesting. I mean, quite a lot of what you're talking about is things that are not actually IRC and aren't really chat, and not necessarily things that you would do with email. That's to say you're kind of finding a new sort of interaction model for solving problems that would previously be done by going looking at a database or going to a website or editing a document or going to a spreadsheet or Google sheet or something. and you're kind of going down to what's actually the thing that we're trying to achieve here

and say, well, actually that could be done through this entirely different model. You know, we don't need to put a spreadsheet here. We could do it in a conversation or through an API feed or something like that. And then all of a sudden that doesn't need to be a web browser or it doesn't need to be Microsoft Office or Salesforce. It can be this much lighter weight, more kind of universal, more portable interface. So suddenly you can kind of go and see you and search all of your help tickets in an iPhone app rather than having to have an iPhone app from that particular provider. So it makes it much more of a universal interface in some ways.

Yeah, and I'd even be willing to admit that in many cases, using a purpose-built specific tool for each of those items might be the better experience, but the value of having them all in one place just so completely overwhelms any benefit you can get by splitting them up hard. And this is maybe a slightly different topic, but one of the shifts that we're trying to take advantage of

is in contrast, and I had this conversation with Stephen before, but in contrast to when I got started making my living with computer stuff, which was the mid, late 90s, when Microsoft completely dominated everything. Now, for... Because customers chose Microsoft. It was not like an active domination thing. Well, you know, it's funny because it was just, it was the environment in which we swam to a certain set.

You know, I worked at a design agency and we used Windows on the desktop. We use Windows for workgroups for our local networking. We used Microsoft server technology for the sites we developed. We used Office. The project manager used MS Project and we had custom written some VBScript to connect that to Outlook for task creation.

The original full stack. Yeah, but it was. I mean, there was IE, and there was ActiveX, and there's OLE, and all these things that made Microsoft stuff work well together. And now for nearly every product category that Microsoft once dominated, there's a dozen good vendors.

Most of whom are cloud-based. And there's categories that are almost unrecognizable. compared to their late 90s form, like CRM, post-sales force is a totally different thing. And there's product categories that didn't exist then, like application performance monitoring is a whole new thing. And mobile.

Yeah, and definitely mobile. So in one sense, from the perspective of a business customer, the world is better because this software is easier to use. It's much, much cheaper. It's much, much easier to manage and deploy. It's more powerful. It's simpler. In every respect, it's better, except that nothing works together.

And this isn't anyone's intention, but if we manage our customers' issues in Zendesk and we manage our developer issues in GitHub, those are two things that ought to be at least accessible in the same forum, but they're siloed. And again, this is not GitHub's intention. It's not Zendesk intention. It's just they want to do the thing that they do very well, and they do the thing that they do very well. And that is not just for those two product categories, but for the 30 or 40 or 50 tools a company might use across the board. board, everything from marketing analytics to BI, document creation, editing, data warehousing. There's so many services these days, and we keep on inventing new categories, and it's just so scattered. So there's a huge value of bringing it all together.

Wow. I think that's super interesting. That wow was genuine, because one of the things that, like, I was thinking about, like, the typical IT answer to 50 different silos, and then overlay the mobile one because everything is like I got to do all this in a browser and then by the way I have to figure out that whole reflecting it in a mobile as well but the typical answer is to make them all work together is sort of this very heavyweight integration you either go to all the vendors and try to get them to agree on some high fidelity data interchange which is impossible and the cloud almost says well that's sort of not the way that we would think about

solving the problem or you you try to think of it from like the the dashboard client perspective and get everything to integrate at some deep, deep level. Like, okay, I'm a Salesforce person and we now need to have, you know, Zendesk stuff show up. So now I'm going to write a bunch of code to get Zendesk to be displaying in the middle of my Salesforce display. But the problem is that that solves the sort of the fringe case of the person who's, like, constantly immersed in both. But a lot of what you were saying is also this, well, there's a lot of uses to connect all these things,

but you don't have to be so heavy about the whole thing because so much of the usage is not this massively weighty challenge. Is that something that... Yeah, no, I think in one case, you end up with the very lowest common denominator kind of integration, which is smushing down whatever kind of data into a message. But I think that's saved by the fact that almost everything has a URL these days. So you might just get the short summary of the item.

You might just get a little bit of the information and obviously not have the full functionality of that third-party application available to you inside of Slack, but if you have URLs, you can do anything. So you can just go back to the original source, and that's this, you know, very, very lightweight, but very powerful form of information. So the thing that strikes me listening to you, which is if we think back to our computing experience 15 years ago, you had a network drive with 150 folders, and you had no idea which folder the files were in.

But once you found it, you double-click on it, and then the application would open. And then you go to the cloud, and you've got 150 different applications, and you've got no clear which of those applications, the meeting notes you're looking for it and might be They might be in Evernote, they might be in Salesforce, they might be in Vendez, they might be in this or that, and the next thing. And theoretically, you could have gone to search a network drive, no matter how well that would have worked. And that would have, again, that would have kind of given you that lowest common denominator.

You would have found a project file that said, this is the thing for this client, and then you'd open it. And you're almost kind of giving that kind of experience, again, that actually you can find all the stuff, and then you open it in the thing that created it. Yeah, we actually, we often use the analogy of what it was like for us, and I think this is true for many, many people, and certainly most listeners of this podcast, of what it was like to switch to Gmail from another email claim, where it wasn't just the fact that you could search for the messages and find that again after, which obviously is very important, but the

cognitive cost of processing the incoming messages fell through the floor in comparison to a world where you had to manually choose the folder in which you'd file something away. Suddenly, it didn't really matter. You could just throw it all in one big pile. You could archive messages, willy-nilly, because you knew that if you ever needed to find them again, the search was good enough that you'd be able to. And this is in contrast to my experience, and I think most of people's experience, and I'm trying to, I'm hedging

so much because you're in the room, Stephen. But of... I feel free. I, you know, go ahead. You want to make a clippy joke? Make a clippy joke, and we'll move on. I've used an outlook 11 years ago, which, you know, obviously had a search feature, but it was more or less a nominal search feature. It didn't work. I'm going to swear, I promise. It didn't work. It would take four or five minutes for the results

to come back, and they weren't good. And so you might as well have not had the search. So the experience was exactly like we were saying, benefit of having to try to remember what folder is something that's in. And we have this all the time now. You know, there was a McKinsey study, and I can make any consultancy come up with a study that says anything I want them to say. However, I think this is probably pretty accurate about the amount of time people spend using email. And one of the other aspects of it was the amount of time people spend looking for stuff. Yeah. And when I need a stat, because I want to put

it in a presentation, and it was in an article that someone sent to me, and I don't remember the publication. I don't remember the title. Maybe I remember the person who sent to me, but I don't remember the medium through which they sent it, whether it was a text, it was a Google Hangout message, it was an email, it was any one of these, you know, it was a comment on a task in Asana or who knows where, having everything come together in one place and making it searchable has incredible value. Well, it's fascinating because, you know, this whole, one of the biggest transformations that the cloud enables is sort of this infinite, you know, secure, reliable storage kind of thing, and of course, not technically infinite, but

what happened is there's transformation from, you know, everybody on their device being, and mobile is a huge part of this, because your mobile devices don't have the storage that you can save everything. And so now everybody's trying to figure out, like, which part goes where, when really you just leave it all in the cloud, and then you never have any of it, and that's, like, way more secure, the Sony breach doesn't happen and all this stuff. But people are used to spending all of this time, like, being filers, like instead of a pilot, Like, that was the acronym we always, the little saying we did with Outlook was, are you a piler or a filer? And, and the problem was, and I, and so this is the question really is, the typical folks in IT, they are trying to figure out an information sort of management solution for the company for the enterprise or the company that actually supports filing.

Like if you, so I'm curious how they, how some of your early customers with Slack and how they see it because they're, their, their first motivation or their first. responses, okay, first I need the finance department, then I need the legal department, then I need the accounting, then I need the accounting, and I need tax. And then within tax, I need domestic and internet. And they have these hierarchies, which often look just like the org chart when they're done, even though they're not. And really what you're saying is that's the part you don't need. Like, because you spend all that energy and if you just keep pushing it, we'll find it. And the weird part for me is always people want to do that or people don't want to do that, and then they go and use Google. And then Google,

has no big giant hierarchy. In fact, Yahoo sort of lost that battle over having a higher. And so how does that conversation with enterprise customers go in terms of thinking, like, don't spend all your energy doing that. Like, just get people in it. Well, I'm not sure if we actually have that as an explosive conversation. Yeah, yeah. Because it tends to be very bottoms up.

But that's actually, I've never heard that pilers versus filers, then that's sort of perfect from my perspective. Because the degree to which you can remove friction, even in the tiniest little instances, makes a world of different. You know, this is a slightly different example, but one of the very first integrations we built for our own uses in Slack was a bug command. So I would type the slash character and then the word B-U-G, and then at somebody's username, and then a bunch of text. And I hit enter, and a bug will get created assigned to the person whose name I mentioned, and then all the text will become the subject of the bug. And then the URL will get echoed back to me in Slack.

Where does the bug go? So the bug goes to our bug tracker. So it's our own internal tool, but it would work. You can do the same thing with Asana now, and I think you can do the same thing with Giro. And if you can't yet, then it's coming soon. The URL gets echo back to me so I can click it and then add some more detail. But the difference is, and this is the stuff that you lose, the friction that you lose, and it doesn't sound like much, but it ends up being a lot.

And that's switching away from Slack to my browser, command T to open a new tab, starting to type the URL, the bug tracker, waiting until I've typed enough characters that are recognized, hit enter, wait for the page to load, hit the new bug button, and then start to... Well, and two-factor off and all of the stuff that's going to happen. But that little bit of friction meant that we were a lot better and more disciplined about the creation of bugs, because when we had some conversation, then we realized, okay, I see, that is a bug, and now someone needs to report it.

It wasn't this giant ordeal. I mean, I say giant ordeal. That's what it feels like just to have to switch applications and open a new tab and type of over. I think there's a strand running through all of this, which is a lot of the heavyweight things that one would do with a mouse and a keyboard and a web browser or a PC application and a file browser. You kind of need a PC. So you want to do that full bug tracking thing. You're not going to do that on a smartphone standing in the street because you've just seen an issue. And so then you'll say, well, you know, I need a PC to do this job.

You know, I need a big PC and I need a big keyboard and a big screen. But actually that's just because of the tool that you're using required you to have a big screen and a keyboard and a mouse. But actually the underlying task is I just kind of need to send this little packet of information or make this decision or give this piece of information and pass it to somebody. And so when you boil it away from what was the tool that we were using to what is the underlying objective, then all of a sudden the device you need can change quite a lot. Yeah, and again, it does end up lowest common denominator.

So if you use something just to extend this as the example, If you use something really complicated like Bugzilla or Gira or some more sophisticated bug tracker, which might have 14 fields that you're supposed to fill out for severity and priority and reproduction steps and version it applies to and a screenshot and all that kind of stuff, you won't get to do all of that. But that's not something that you're going to do while waiting in the line at the bank anyway. You're just going to type out the very bare bones basic. But it seems to me, I mean, that metaphor, though, is sort of consistent with, like,

keeping the organization going. because the alternative is, you know, like I experienced the bug, and now it's on my own personal to-do list, and I'm probably going to drop that, whereas at least if I put it on with just the title and the minimal information, now the organization knows it. And someone can hound me and keep sending me the URL saying, will you finish filling this in?

Because, you know, you were online at the grocery store with the bug. So it seems to me that, again, this benefit of having this is, it's not just that it's mobile. It's just that it's connected to all of these line of business systems that keep the organization rolling and doesn't slow down. The mobile versus desktop distinction is kind of interesting for us, too, because we explicitly said at the beginning, and this has still been our experience, that Slack is not really designed for a mobile-only workforce and not designed for jobs where people aren't going to have a computing device in their hands most of the time. So we automatically disqualified, say, retail, food service, health care, 70% of the U.S. workforce. But that the other 30% are people who will at least at some point during the day use a desktop. So I think that Slack is probably not use or if one person on the team is mobile only, that's fine.

If 60% of the team is mobile only, that's fine. If 100% of the team is mobile only, it might not be a great product for them because there's that little bit of utility that it's difficult to deliver on a phone. we have I think I don't have the latest stats on this but let's this is to be close enough 99% of our daily active users will lock into Slack at least once on that date that they're active on the desktop but only about 65% will do the same thing on a mobile yeah that we should look at our Andrews and Horowitz members because I think we're all like we might be an interesting use case because we're very mobile and I think a lot but one of the let me just ask this in terms of the usage then what the average customer

who gets the bottom-up deployment who signs up, what's the first thing people do us like where it feels rewarding and it brings in more people? It's a great question, and it's hard to answer because it's so variable. We look through, and this is obviously of critical importance, to figure out

what the patterns are in successful implementations versus unsuccessful ones, but there's so much variability. It can take a whole year in some cases for the team to really convert. There'll be the couple of initial evaluations and then it'll die off, and it'll be a few months before they get a small team using it,

and then the small team will use it for six months before the whole company switch is over. This is not a eureka moment for people, and this is kind of a slow boil, but I think the ultimate difference is, and this is the big contrast between Slack and an organization that's primarily driven by email usage or communication primarily happens by email,

where in the email case, everyone has a small slice, and I'm gesturing with my hands to make a very small slice of a big wedge of the communication that's happening around the company. And all of the rest is completely opaque to them. And when they leave the company, their slice just disappears. It's gone forever. And even more important, when someone joins, they start with an empty inbox.

They start with literally nothing, despite the fact that there might have been tens of millions of messages passed back and forth. In contrast, when someone joins a team that's using Slack, and this is why I think it might take a while for them to get the most important bit of the value, they can scroll back through everything. They can search through everything. And of course, they don't want necessarily to get everything. In our case, on our team, we have three and a half million messages in the archive. But they can get a sense of what's going on now, what's important now. They can get a sense of how people interact with each other. They can get a sense of

who knows the answers to what kinds of questions and who really makes the decisions. And, of course, they also, through search, have access to every link that's been posted, every document's been shared, every decision, every discussion. And you can go back and figure out why do we do this crazy thing this way? And you can see the origin of that conversation. You can see what happened the last time this issue arose and how we dealt with it and all that kind of stuff. So it's a lot like, you know,

sort of a Twitter phenomenon that you see, which is someone new follows you or you follow someone new, and then you go to their history. And then all of a sudden that's when you start seeing the, you know, December 14th, you know, 2007 favorite. That's actually a great example. I hadn't thought of that before, but that is, you know, having this pre-existing stream

of information that exists that you can dip your toe into whenever you like, you can have a glimpse into. And that's actually maybe the second part of the value of Slack, which is transparency across the organization. And transparency seems like a loaded word because it has all these political connotations. I don't mean Edward Snowden or any kind of political kind of transparency. I just mean literally the opposite of opacity, so that, for example, the technical operations team can see what's going on with customer support. So they're having a lot of people reporting this issue over and over again, and someone on the tech ops team says, oh, crap, we just change the load balancer, I bet that's why. Rather than that be an issue that's escalated

to the customer support manager, and then the next day's standout meeting, the customer support manager relays it to the manager tech ops and goes down. Or any of us that, the engineers can see what the designers are coming up with next. The marketing team can see where the sales team is having issues and they need better support documentation, all that kind of stuff. Cool. So, you know, what, okay, so then as the usage goes on, so there are lots of different ways to start? What's the thing that you think people stop using? Like what kind of products have slack displaced? I don't mean that to be in an aggressive sales kind of way, but just, you know, wow, maybe they stop using the front end to some

things or do they, I think it's a good question. I don't think it's sales at all because one of the things that we realized early on is if we don't either replace or consolidate some other form of communication or interaction between people, then this is going to be another thing that they have to do. And if it's another thing they have to do, then it will inevitably fail. And I don't want to sound like I'm picking on them, but that was my experience of Yammer and many other people's experience of Yammer and products like that, like in that same category, chatter, and Convo, social cast, where it wasn't quite sufficient, this is, by the way, what I'm thinking is probably going to happen with Facebook at work, too. It wasn't quite sufficient

to replace email usage internally, or wasn't quite sufficient to replace use of messaging internally, or whatever it is. And so it becomes this other place. And what we found is that success with Slack is very binary. If we get to 80% of the team using Slack, it might sound like I'm going to say something good, but no, 0% will be using it soon. It has to be 100%. You have to be able to trust that if you send the message in this way,

then people will see it. In the same way that if you send someone in email, you know that they will see it, they might hate you, they might have too much to do, it might get lost, they may never respond to it because they have too much other stuff going on, but you know that they will see it, whereas if you can't trust that a message 10,

to this meeting will reach the group or the individual that you're trying to get to, then eventually you'll stop using it. So in most cases the thing that it will replace is email usage. And I want to just stress because we get this in headlines quite a bit that we want to be an email killer. Email is not going away. We've got at least three or four decades left of heavy email uses because it is lowest common denominator. And I mean that in a good way. It'll cross organizational boundaries very easily.

It's how we coordinated this meeting today. But I think if you use email as your primary means of communication internally for the kinds of knowledge worker, for lack of a better term, teams that use Slack, that's, you're foolish. I mean, and it's such a big disadvantage that you will eventually be made to switch by losing out to your competition. All right. Well, I mean, I think that in a sense it's the practical answer because showing up and saying you're going to replace email is a very challenging value proposition given that companies need it to run. But, you know, certainly if you ask a reporter, I'm going to use Twitter as an example. Like, Twitter has changed the workflow of being a reporter. And it changed their nature of work.

It changed where tips come from and leads and who reads their story and how they talk about their stories. But it seems like the same thing could happen once you get to 100% Slack, that like the daily workflow of somebody is different. And then, you know, mobile seems to fit into that as well. So do you think that in the places that have really deeply engaged with Slack outside? of this building, that their workflow is really different and that their nature of work has changed? Yeah, and I think, you know, Slack is not some panace, it's not, it's not magic, it's not going to transform people by itself, it's a tool, and it's a good tool, but people will, especially in the transition period, struggle to figure out how they're supposed to use it most

effectively. It can feel like it's noisier, potentially, it can feel like, because you have established patterns of behavior, both in terms of your own daily routine, like, you know, with the points at which you stop to check email, and in how people are expected to behave, like so, for example, the meeting notes are circulated after the meeting by email or something like that. It can be a very big change, and that's a, you know, we think of that as a request that we're making of our customers, you know, that we're asking them to change very fundamental, and in some cases very ingrained set of behaviors that all interact, and we're asking them to change it at the group level, which is even more challenging than

the individual level. So it's a very, very big ask. And this is maybe a little bit of a side, but that's why we focus so much on new user experience, on communicating the value up front and all those kinds of things. But it can often take a while before people find their legs. And even in our own case, you know, we're the people who make Slack. When we first started, it was eight people working on the team. And so Slack was absolutely perfectly designed for an eight-person team. And if you were like a 12-person team, it's a piece of crap. We found that out pretty quick because when we first begged our friends to use it, we got Ardeo as one of the very first external customers. And not long after they started using it,

they had 120 people on it. They had all these cards of complaints that we didn't ever anticipate things we didn't really understand. But even in our own usage, as we've gone from eight people to now, 100 people ourselves. We had a very, very, I'm not sure what the word is, like consensus-driven or collaborative approach to decision-making where everyone gets their two cents in, which is fine at eight people and fine at 15 people and even fine at 25 people. And then it's kind of not so great at 50 people and it's a disaster with 100 people. Because it's the amount of time you're taking up to have everyone give their input and the sheer number of messages doesn't work. So we've had to adjust our own behavior in light of that. It's, you know, it really really

depends on the nature of the organization, but the kinds of changes that we typically see or have reported back to us are, of course, a drop in internal email usage. In some cases, completely, you know, not using email at all internally, which was a side effect that we hoped for, because again, having all the messages in one place from the big memo down to the I'm going to be five minutes late has value in itself. The other one is canceling a lot of a very specific type of meeting, which is the daily stand-up or the status report kind of meetings because there's a steady flow of information emanated from each team. So if you want to know what's going on with technical operations,

you just open their channel and have a look. If you want to see what's going on with the front-end engineering, you have a look. If you want to see what's going on with the sales team or what accounts are being closed or any of those bits of information, you can just look for yourself. I mean, there's a classic kind of use case I always talk about, which I think of my friends in big companies who, once a week or once a fortnight, they have to go into an internal system and put out a bunch of operating data and then drop that into Excel and make charts and then put the charts into PowerPoint

and then write bullet points in the PowerPoint and then email that to a team. And you can't do that on a smartphone, you can't do that on a tablet. But actually, that should be a SaaS dashboard and it should be a conversation in something like Slack or it could just be it okay. If the charts change, you paste it into the Slack channel

and you write Y and then you're done. And now that's not two hours once a fortnight and it's not a copy of PowerPoint. So let's just, I think, It's been super interesting. I think we could keep going on this for a long time because we, and maybe we'll end up doing a part two at some point to talk more about the depth of this. But, you know, kind of just want to ask in a sense, like, because this space has always had a bunch of products and they've always had a little trouble getting traction, and I've been up to Seattle and I've seen companies using it, and I've seen people using it in D.C., you must as an organization and you personally sort of have a belief or an insight about how. how people use tools that other people sort of either question or don't share.

What do you think is that sort of secret magic beans that Slack holds that other people might not? It's a good question. And at the very beginning I talked about my own history and like most people who've made software, trying to build task management software at some point. One of the, you know, so when we were first starting on this and we thought about the core feature set and what we wanted to get in and what we didn't want to do, we decided to be wanted to avoid anything that has too much structure or too much ideology behind it.

And so task management would be one of those things, although there's a whole world moving towards the piling metaphor that you used before versus the filing metaphor. Having something that's as loose as a message, which can include a link or it could be a file that's uploaded, it could be short, it could be long, it could have formatting, it could not have formatting. and just having the basic model of people on the team or services you've integrated with the team can admit messages into channels and you can join as many channels as you like. Having that very lucid infrastructure covers a wide variety of use cases.

So I think that's the key thing because the more specific the tool, the more constrained it is, the less general its application will be and the less like it will work in any specific use case. And just one more point on that when we thought about what we would build

as a task management piece of bit of software this is something that, again, that I've done before in the past, you have to have some ideology about how work gets done. You have to have some ideology about what priority means or what an assignment means or due dates or severity or any of those kinds of things, how tasks should be described or defined and how they should be presented and ordered and all those kinds of things. And the more specific you get, the more that ideology gets cooked into the model or the schema,

in the literal sense, the database model, like the field names, and what columns you have, the less likely it is going to work for any given individual because people are very idiosyncratic and groups of people are like a multiplication of all the idiosyncrasies of the people making up the group. Wow, well, thanks. You know, actually, I have to say that, like, it is an insight.

Like, I think that every tool that I've known in 25 of more years has always started from, like, first we're going to define our structure and then we're going to define the methodology for how work is done. And then we're going to define the methodology for how it's stored and cataloged as well. And so that seems super unique. It's great to have a chance to talk to Stuart Butterfield and with Ben and Zek-Devins here as well. And so thanks so much. This has been another A16Z podcast.

Thank you. Thank you.