workplace chat and collaboration technology companies. Slack is going public on June 20th with implications for a wide variety of companies in the Seattle region and beyond. Microsoft is slacks, primary competitors with its team service and slack is a big Amazon. Web service is customer, but beyond that, many companies that sell technologies to businesses will be watching slacks. Stockmarket debut closely to assess their own potential in the public markets this week on G Choir were doing a deep dive on Slack, with a pair of episodes exploring its underlying business and technology. Later in the week will talk with a Pitchbook analyst who just published a major report on Slack. And on this episode, we're featuring a conversation with a co founder of Slack. Cal Henderson, the company's chief technology officer. Cal previously led the Flicker engineering team as its chief software architect. He was also an early pioneer in the use of Web AP Eyes I'm geek wear editor Todd Bishop and I spoke with Cal Henderson at the recent G Choir Cloud Summit about slacks, history as an accidental enterprise technology company and its approach to engineering in the cloud era.

So sort of the elephant in the room in this entire discussion is going to be June 20th which is the according to the sec, not to you, but to the SEC that dates of slacks. I po to use the colloquial term, but the direct filing, the fits like will be doing so My goal is to get through this with you revealing as much information as possible and not having to say no comment. But if you have to say no comment well, I don't know, just keep pushing on it. So you, uh, I have been through some fascinating pivots with Stewart Butterfield and team. You've made multiple video games and then gone into other products to tell us about your journey from the beginning. Pre pre flicker. Too slack

today. Yeah. So I've been working with the with the same set of people and co founders for a couple of decades now, what we've been doing on the kind of environment that we've been working and has changed significantly over that time. But there's definitely a couple of kind of common patterns. The studying way back in kind of 2000 won. We started a company to make video games on the Internet, which was terrible time to make video games on the Internet because they weren't such things At that point, nobody had kind of plug those two together, and we totally failed to do to do that at the time. But that turned into Flicka, which at the time was was fairly successful. Then fast forward a little bit after the acquisition by Yahoo in 2005 and we wanted to get back and try and do the same thing again. The Internet had changed a huge amount in the kind of in the five years. 56 years before that, there were so many more people on the Web, there was kind of the rise of social networks,

and people were used to interacting with each other online and around that time as well. With the rise of Zynga and fro like a brief moment in time, it seemed like online games was going to be a riel, a source of revenue as well. So it is easy to raise capital at that time to make games. We had this grand plan, we were finally going to be able to, you know, bring to market this vision that we've had years before on being being unable to realize at the time. Like this time around. We had everything going for us, were able to raise funding technology and moved along a long way. There were a lot more people on the Internet. People are willing to pay money for things over the Internet, and we totally failed to execute on it. With everything going for us,

I think we're just, like, quite bad at making video games. That turns out. But what we did look into was another pivot into something else. And so slack came to be because as we're working on on the game project, which was called Glitch at the time, probably nobody here played glitch. It's also why it doesn't exist anymore. The when we were trying to make the game, we were split between San Francisco and Vancouver and we built a set of tools to be able to communicate and collaborate better. We spent four years working on this game. We built the whole business around it, every kind of workflow, from the development side to the artwork creation to level building to accounting toe customer support. We built it all into these.

This till we're building ourselves. And it was it was a great way to work together and we didn't really think about it as like we're building a product is just way. Want to get our work done and we're developers. So we were software to do that. And when we shut the game down on Day one, we're trying to think about what we wanted to do next. We realize that whatever it was we did next, we wanted to keep working together in the same way, like it wasn't just the tool, said it was the way in which we're working together. It made us a lot more productive and made work feel different, as as a team of people spread across different offices around the world. We thought, if we like that as a team company of kind of 40 50 people at the time, maybe other companies doing similar things would find that you're useful as well. That's where Slap came from.

You had used this for so long. Internally, you almost have this very extended private beta test. You were so stable in terms of even the U I. In many ways,

We had the model, you know, almost 10 years ago now of that way of communicating. I think that's kind of two core concepts of the heart of the product that we stumbled upon. One is, and neither of them in isolation is it was an entirely new thing. The 1st 1 was using channels instead of using email that is instead off, you know, want among communication by default, organizing communication, discussion on work around topic or whether that's kind of topic or project or team. It's a very street in a kind of straightforward idea, but I think the thing that it shifts is this idea off. You know, we've been using email in the workplace for about 40 years, give or take, and it has a whole bunch of assumptions built into it.

You know, it's a 1 to 1 communication medium by default, you address the people you're sending to, and it's very push model. You know, we switched two more of a poor model with channels where you choose what you want to subscribe to. But more than that, when you join an organization that uses email, you start on Day one with an empty inbox, and you have zero context of what happened before. And if you leave that organizational, that team, the information that is locked up in your inbox just dies. And for as work has become increasingly more complex and more collaborative on people join projects or teams and leave them over time. That ability to have a a record that preserved independent, off of the people involved,

I think is huge, then on the other side is the kind of the applications and platform aspect. I think the one of the most interesting trends, which is very tired, toe cloud related topics, which I'm sure we'll talk about that has Bean the rial explosion off software used in the work place over the last 10 years. In a net scope study, which is now even two years old, the average mid to large size company is using more than 1000 different applications. And that's that's just an insane number of different bits of software. I'm not sure I could name 1000 different bits of software, and that's the average for a midsize company, and that's such a big change from a decade or two decades ago. It has been what's enabled that I'm sure we'll talk about. But where enterprises are using more and more software, it's just become more on Maur.

Where work happens has become more more fragmented. It's like work from this team happens in this application. Work from this team happens in this set of applications, and this department uses this set of applications to get work done on. It has meant work is more fragmented. I think one of the patterns that we hit upon was what if we can pull all of that work together at the communication lines?

Absolutely. And Slack now has more than 10 million average daily users, So clearly you've struck a nerve. And as we mentioned your soon to be a public company, let's talk about the technical challenges that you faced in the build up to that 2013 launch. What types of decisions did you make at that point technically, And what can this audience learned from them?

Well, I think there's a few different things we could talk about. That one is that when we started the company, I don't think we had any vision off how how large it could be of how a generally applicable. It could be because when we were building it for ourselves, we knew that we'd built a product that worked. Fire worked well for teams exactly like us off somewhere between five and 100 people off on initially like engineering teams building software. And we knew it. That worked well for us. And he thought that worked well for for that use case. I think it became very quickly apparent to us that it worked a kind of across all different job functions incisors company as well. But so saying to begin with, we definitely didn't build it, thinking that would have more than 10 million daily active users or beyond. And so we were just. And I think this is kind of for nearly any kind of software that any company is building outside of a few giant companies. The most important thing that you need to do is find that product market fit quickly,

and it's not about like if if this goes perfectly on every possible axis, what is the total addressable market? We'll see over the next 20 years on build to that, because the first thing you build is not gonna be the right thing and the very first version that we put in people's hands was definitely not the right thing, and we needed to be able to get right on that really quickly. And so the focus definitely for the first couple of years was on finding the the what? What would translate from what we had built on work for us, to what would work for more people. So Iterating Quickly understanding what how other teams worked on what the frustrations would be in really honing in on that product market fit. So I think that it's I'm I'm an engineer. I'm very excited by new and interesting and exciting technologies and, you know, definitely interested on the large scale distributed system side. I think it can be super kind of addicting to go and build something for massive scale, which you will then never see on dhe finding that that balance is really tough and it's the You don't wantto paint yourself into a corner and be able to build something which you will never be able to deliver a scale if you are successful. But it's the situation at the beginning. That's

Kate, so you are on the cloud. Now, in fact, we know that you're primarily on Amazon Web service is. Would you have been able to scale to the extent you have on efficiently, as you have with without those cloud technologies?

It would have been much, much harder back when we started the company and built flicker, we had our own physical data center on. We had to go and buy servers, and we were in Canada. So we had to buy servers and then drive down to the border to go and talk to the customs people to get them out of customs and then take them to the data center and rack them. And it still limits from a CD and then realized we didn't have enough network cables and go down to the shocking by network cable. So it's like that 1/4 to 1/3 of all of our time was just like useless, undifferentiated work that we had to do. So like the move from hosting your own small date. You know, having your own physical servers at the small scale to moving to infrastructure is a service or platform is the service. It was an incredible time, saving like it. It has really been the thing that has driven the ability for this explosion in software categories. Because kind of niche SAS businesses that just could not have existed a decade ago without AWS G C P. Azure can now exist because you just don't have to put in that either upfront capital investment or massive investment of time to be able to get to the point when you're proving out your product and finding that problem product market that

if you were launching something like flack today or slack today, what would you do differently given the mistakes you made back then, but also the evolution of the cloud and the available technologies since

then? Yeah, I think on the 1st 1 Sure, we made lots of product mistakes, and now we have a lot more data, so think like we would we wouldn't make any of the mistakes we made. But I think the cloud side isn't is more interesting, and that is that, you know, with moved on, moved a lot more from the kind of infrastructure as a service 10 years ago. Two more of the platform is the service and higher level kind of like moving further up the stack and being Maur hosted service is, as opposed to just will provide you with, like, you know, virtual machines very quickly. And I think that that it's it's a continuation of the same thing.

It's what can we do to avoid doing undifferentiated work that everybody else does, which doesn't make us any particularly better at the thing we're delivering. So you know, we're now we use kubernetes and we use Maur kind of high level hosted A W service is, for instance, and it just lets us spend more time on the things that are unique to us as a service or a company.

And I know that circuit 2015 there was an AWS case study and you were relying heavily on the sea, too. At eight of us. Is that still look a core part of your infrastructure?

It is definitely still a core part of our infrastructure. I think the I was definitely historically skeptical of higher level service's who have just started to adopt the more and more over time, and I think that's you know, whether that's kind of on the data warehouse side. I think that was probably where we made a big shift first, quite some time ago, into more hosted service's but kind of more across the board. We're moving further up the stack, and that's that's the same from older, all the major cloud providers.

So given that what are the fundamental cloud technologies? The key things in your toolbox today at Slack,

we use a lot of different surfaces and technology. I think I think kubernetes and containers have been big for us and rethinking the way that we make engineers effective and productive. It's how much control off, you know, deployed service is. Can we put in the hands of engineers? The model of the past was you have an operations team in that transition to like Everybody's a Bit Dev ops and Tomb, or you don't really think you don't really think about it so much as operations. It is part of building software is running it and deploying it Now, Andi, think the lowering the technical barrier to being able to be devil see by putting more tools in the hands of hands of your developers and that being the expectation off, you build it and you support that service has really changed how we think about building software.

We know this from the S one. And I know you can't comment on this, but we know that slack spends a minimum of $50 million a year with a W s big picture in the abstract. How do you think about issues like operating on multiple clouds, vendor lock in switching costs and the whole concept of wanting to stay flexible but also wanting to have maximum efficiency? How do you weigh those things in slacks? Operations?

You know, if you think about it from inefficiency, Point of view, Engineer, developer Time is actually super expensive. So the the idea that we could that we will tune for the ability for fast it oration and for fast development cycles over anything else is for really what were concentrated on. So that's the real differentiator. There are definitely very particular businesses where it might not make sense to use a cloud provider. You need us, you know, a very particular resource at massive scale, or you need some kind of, you know, service or hardware that doesn't exist in the cloud. But for nearly any kind of business of small to medium scale and makes a ton of sense because you're you're like your developer costs too high and your opportunity costs of the highest thing. It's like, What could you be doing? Instead of thinking about how to do very small cost optimization in the grand scheme of things, you could be thinking about how to get to market quicker, howto provide that next decoration for your customers?

But what if you were to say, OK, aws, we wantto shift over to Google Cloud? How technically feasible is that in reality? Because on the surface it looks like many of these service's and cloud service is our similar ATT. Least in purpose is that kind of migration possible or or pragmatic or practical?

It is. The service is, or at least the three big service's are more similar than ever. You know they have a particular thing that they're that they're better act or that they target Maur. It's a lot of work because as your very dependent on scale, but as your application is, your service gets more and more complex. You become more and more dependent on the small operational details of how that particular provider works or how that particular service works. It's like, broadly, this queue service is the same as this. Q service is the same as this Q service, but the exact characteristics under load or under failure conditions are things that you end up building around. And so there is definitely cost doing that.

How do you weigh that? In terms of the volume of workload that you put on one single vendor?

The thing that the most concentrated on is developer velocity. So it's how, how quickly can people iterated on it? So whether that's for sometime, like G. C. P s a provider was far ahead in offering M. L. A. I like service is. So if I have a team that wants to build something around those technologies, then G. C. P is gonna be the way to do that at that particular point in time. And it's that that speed of decoration delivery that's more important than

anything else you're listening to geek wire and we'll be right back. If you speak to any disruptive force and technology, they'll tell you that inspiration from outside of their industry spark some of their groundbreaking at innovative ideas. That's what the Thinktank podcast is all about. Every episode pairs entrepreneurial minds from a variety of industries with an executive from the digital Innovation Group at Providence, which is a health system in Digital Leader, based in Seattle, Washington. Together, they take part in a supercharged brainstorm session that illuminates areas where digital technology can create meaningful disruption in healthcare, from simplifying the way you make appointments to better serving underserved customers to building personalization in the health care. The think tank explores how digital can change the way health care operates today. Check out the latest episodes of the think tank on any podcasting platform. The search for D. I G think tank in tune in each month for new episodes on the impact of digital transformation on health care consumers. Let's return now to our conversation with Cal Henderson, the co founder and CEO of Slack,

at the recent G Choir Cloud Summit. So let's talk about A and M L. Because it has been obviously a recurring theme, and I think it's perhaps the most common high level cloud service that a lot of people talk about, and it's becoming on and use an implement to what extent are you using artificial intelligence and more specifically, machine learning in the slack that those of us who use lack experience every

day? Yeah, I think the answer is but interesting and kind of boring and that you, you it's in many of the features that you use. But I think that what we have started to do and what more and more people are starting to do is use NL for personalization on a small scale. It's from making something a little bit more intelligent and a little bit better. It's every time there is a ranking of something, whether that's like ranking of search results or channel when you switch to wear tour the you know, person's name and auto complete. When you go to D M somebody. It's making sure that that is slightly personalized to you, based on your past behavior and a whole bunch of other signals that we record. And I think that the effect that that we're really are starting to see of ML application across a wide variety of products is making the small interactions a little bit better. So it's that kind of background magic that you don't necessarily. It's not like some big, splashy thing. It's everything getting a bit better.

Do you see that changing over time? In other words, could there be a massive breakthrough that would allow me to find that dang message that I sent three days ago? That was in the channel down here? Very like that's where I want to say on the M l.

I mean, you know, that's the kind of a I dream is, you know, your robot assistant that does that, like, is better than a human being and, uh, and does everything perfectly. We're not gonna get there incrementally, you know, it's not gonna be like a tiny bit better until suddenly it's like a human level intelligence. That's gonna be some weird step function at some point. But I think that the there is a lot of incremental gain that we could get along the way there of just making things a little bit better over time. One of our goals from product point of view is that the longer used the product on the more information that you put in it in the more signal we can gather, the better it can respond to you and understand. Like when you wake up in the morning.

This is the first person who's DMC always read, read from. That's probably somebody who is really important to you. That's how quickly you respond to them. These are the These are the topics that you talk about things like that so that we can personalize it to you. But I think that's gonna be a lot of incremental changes of

the time. All right, It's been interesting on the retail side, obviously away from enterprise collaboration, to see how Amazons retail competitors make cloud decisions based on their concerns about another sector of their business course. You're in an interesting situation because Microsoft has azure and then complete Competes was slack via teams and office. 3 65 Now Amazon has dabbled in collaboration outs, but they have not yet taken on slack directly. Would you reconsider your relationship with AWS if Jeff Bezos were to take out a full page ad taking slack on to get the reference?

You know, So we we use a bit of G, C, p and a bit of azure as well. So I think that we think about that pretty independently.

Are you confident enough in Amazon's business firewall to make that leap. If Amazon were to compete with you directly,

it's hard to imagine Amazon using AWS as leverage against competitors because it's a big, important business for them. And that would be a daring,

weird move. It's interesting you were hired by store Butterfield after breaking into the list serv for his video game companies. That apocryphal er is at

a breaking into is a strong term that just hadn't changed the default admin password. But but that's just super interested in this. In this original game here is working on on that was tryingto gain every bit of leverage record to find out more about company. Andi was It was fascinating at the time, was in a kind of era before before Webb AP eyes and was really interested in building some kind of data, visualization and tools around the game. So I wanted to understand how the internals works. I could build a public a P I on top of it, and getting into the internal mailing list was definitely the way to do that on. I wouldn't necessarily say that that's the greatest idea, but it at the time. It certainly got

the conversation going. That's great. I was gonna ask you if you would recommend that tactic toe jobseekers today. So, you

know, Well, I think I think the equivalent now, as as the industry has matured, a lot is like public bug bounty programs. And that's definitely how we've ended up meeting a lot of people in the light information security

space. Yeah, absolutely. When you're hiring for the slack engineering team, what are the key skills, expertise or, perhaps more importantly, mindset that you're looking for in the people that you're

hiring? That's a good question. I mean, I think that has changed a ton overtime. So we've gone from a four person company to 1500 plus people today. And so, you know, the people that you hire in in week one a very different to the people that we are in year 10 of the company. At this point, I think that there one of the things that we really focus around both because of the product and I think the way that we think about building software is like being collaborative as, ah, as like an attribute of candidates that we look for because, as work in general has become more and more complex, you know, both from a changing external pressure's off markets and technology moving faster than ever, and internal pressures of different expectations around people's relationship to the workplace. Maura Maura work has become teamwork,

you know, as more, more work has become knowledge. Work on other work has Bean automated away, especially in our industry, that the the kind of myth off the loan programmer who, like goes into the basement on hammers away at a keyboard for a month and comes out with some kind of perfect gem of software is like just so far from the reality off, large scale software development today. It's such a team sport that collaboration is really at the core

in terms of pure tech to three years out. Are there specific things that you bet on, or that you think about when you're doing those interviews and bring bring people on and building the product?

Yeah, I think that what's the rate of change has really been increasing over the kind of especially of the last five years, and technology that a lot off the standards of how people build today whether it's kind of any layer of the stack have really, like, completely changed over the last five years. So slacks, not Avery. Old company, for sure. But when we look at us, say, our main Web client that the majority of our customers use the technology that we would build that with today just didn't exist when we started building the company. And so we have. We have a big focus on making sure that we're using modern but not necessarily totally bleeding edge technology because that's hugely impactful. When we look at recruiting, it's like we're what is the skill set that the majority off people say in front and injuring rolls? What is the technology that I've worked with and what can they bring? What can I bring to the organization if we're If we're using totally unique things and totally unique ways of working and building that nobody's familiar with that just makes recruiting and on boarding so much harder. So what's We're definitely on the one hand, looking at where kind of technology trends are going very like focused on what is the what has been a largely adopted over the last couple years that we can we can adopt.

You know, of course, lack is also a platform. As you think about this, like a P I. What kinds of APS would you like to see built on slack in the future? And I'm thinking particularly about gaps that you'd like to see and things that developers in this audience might capitalize on.

Yeah, I think that the the when I think personally about how how I use like to get work done. I think that the best uses off the platform have definitely been around. How can you take a piece of software that you already use for some particular vertical for some particular task that you do and make it a bit better by using up the slack, make it a bit more efficient, making a bit more accurate, make you a bit more faster, make it feel better? So one that immediately comes to mind is the way that we use Google docks for a ton of stuff internally, you know, from sharing a spreadsheet or presentation or a document hits in Google dogs. And if you share a Google document by email, you paste into your L and somebody receives TRL, but whatever. If you paste it into slack will pull out the title and show you the first page in line. So you know what the contents of the document are. But far more importantly,

if I send you the u. R L to a Google doc, slack will tell me I haven't given you permission yet. Would you like me to fix it right now before you open it up? And I think that is probably collectively saved me about 500 hours over the last five years on DDE. That alone is like it just makes using Google docks more enjoyable, you know, Or we use Jiro for issue tracking. So every time a type of Jiro case number into slack, it's just being the case number. We blink into gear and pull out the type on the status, so it's thinking about the software that you use every day. How could it be made Maur efficient a little bit better in the context of the discussion when you're working with other people, So how can you enriched that usage of those

applications? It's interesting because that really gets back to Stuart's original vision and in your original vision when you launch the company was making slack the hub, and so bringing those capabilities into slack rather than leaving them to just simply operate independently on the app.

Yeah, I think it's really the context of bringing together all of the different applications that you use for getting a piece of work done on bringing them into one place.

One last question here and I were out of time, unfortunately, But you're very public about the fact that you're color blind and you talk about this on your site. I am cow dot com. Yes, and I imagine that must give you a really degree of empathy with technology users in general and the issue of accessibility in general. How has that influenced your life? Your career is an engineer, and what could you impart to this audience about that? That is, that

is a great question. So, like a huge number of people, especially men in the U. S. Colorblind like one in eight, has some form of colorblindness, says this weird like not really a disability cause so many people have it kind of thing, but I think the main outcome is everybody. I work with is sick of hearing me. Tell them I can't tell the difference doing two lines on the graph. But I think that it is that kind of realization that there's a whole bunch of extra things that go into designing software at scale for people to use to make it more accessible and especially with the product that we've built. Slight doesn't work unless everybody on your team can use it. So you know it doesn't work If you have somebody who's color blind and can't actually read any of the text or somebody with low vision or somebody with no vision, a tall in the East, use a screen reader or somebody using assistive devices or isn't a disability. But somebody uses Linux. So So I think it's important to, you know, think about a love those kind of aspects because we're building. We're building an application that has to work for everybody or it doesn't

work for anybody, right that 10 million needs to become exponentially Maurine the years. What would you like to get across to this crowd of business leaders, business decision makers and developers and engineers that we have not talked about is a concluding remark

here. I mean, I think going going back to the club piece that we talked about a little bit is that when you are like in the early days of making a software or product startup company, the most important thing to do is to optimize for that speed of inspiration and finding product market fit. First, it is no on. It's easy to be swayed by interesting technology at scale or interesting technology on the bleeding edge, or what it could be far in the future. But really optimizing for that. How can you get that it relatively quickly and leveraging the, you know, the providers and the technology that are available to help speed that up? I'm really is the thing that's gonna make a difference between you spending a long time on something that doesn't work out, as we've done a couple of times with video games and, you know, finding that product market fit and stunning that growth.

Tell Henderson, the co founder and CEO of Slack. Thank you very much for being here at the clouds. Cal Henderson is the co founder and CEO of Slack, the workplace chat and collaboration technology company that will go public later this week. On June 20th with a direct listing on the stock market, we'll talk more about what that means and the implications of slacks business for its future growth in a follow up episode later this week with a PITCHBOOK analyst who just completed a major report on the company. Until then, I'm require editor Todd Bishop. Thanks for listening, everybody. Don't forget to subscribe to the show in your favorite podcast app. Leave us a rating and a review, and we'll talk to you next time on choir.