Trending: They choose to avoid the moon: Anti-space event in Seattle urges Bezos and others to focus on Earth
Cal Henderson - GeekWire Cloud Summit 2019
Cal Henderson, co-founder and CTO of Slack, speaks at the 2019 GeekWire Cloud Summit. (GeekWire Photos / Kevin Lisota)

Workplace chat and collaboration technology company Slack is set to become a public company on Thursday, with implications for a wide variety of companies in the Seattle region and beyond. Microsoft is Slack’s primary competitor with its Teams service, and Slack is a big Amazon Web Services customer. And many companies that sell technologies to businesses will be watching Slack’s stock market debut closely to assess their own potential in the public markets.

So how does Slack work behind the scenes? On this episode of the GeekWire Podcast, we’re featuring a conversation with a co-founder of Slack, Cal Henderson, the company’s chief technology officer, recorded during the recent GeekWire Cloud Summit.

Henderson was previously with the Flickr engineering team as its chief software architect, authored the bestselling O’Reilly Media book “Building Scalable Websites,” and was an early pioneer in the use of web APIs. Due to regulatory rules, he wasn’t able to directly address the company’s pending debut as a public company, but he provided a behind-the-scenes look at Slack’s technical infrastructure and its approach to engineering, in addition to its broader culture and its ambitions to rid the world of email.

Listen to the conversation above, continue reading for an edited transcript, and watch the video below.

Todd Bishop: Cal, the elephant in the room in this entire discussion is going to be June 20, which is the date of Slack’s IPO, to use the colloquial term, but the direct filing that Slack will be doing, becoming a public company. 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 do have to say, “No comment,” well, I don’t know, I’ll just keep pushing on it.

So you have been through some fascinating pivots with Stewart Butterfield and team. You’ve made multiple video games and then gone into other products. Tell us about your journey from the beginning, pre-Flickr, to Slack today.

Cal Henderson: I’ve been working with the same set of people and co-founders for a couple of decades now, and what we’ve been doing, and the kind of environment that we’ve been working in has changed significantly over that time, but there’s definitely a couple of common patterns. Starting way back in 2001, we started a company to make video games on the internet, which was a terrible time to make video games on the internet because there weren’t such things at that point. Nobody had plugged those two together, and we totally failed to do that at the time, but that turned into Flickr, which at the time, was fairly successful.

Then fast-forward a little bit after the acquisition by Yahoo in 2005, and we wanted to get back and try to do the same thing again. The internet had changed a huge amount in the five, six years before that: there were so many more people on the web, there was the rise of social networks, and people were used to interacting with each other online. Around that time as well was the rise of Zynga, and for a brief moment in time, it seemed like online games was going to be a real source of revenue as well, so it was easy to raise capital at that time to make games.

We had this grand plan. We were finally going to be able to bring to market this vision that we’d had years before and been unable to realize at the time. This time around, we had everything going for us: we were able to raise funding, technology had moved a long way, there were a lot more people on the internet, and people were willing to pay money for things over the internet. We totally failed to execute on it with everything going for us. I think we’re just quite bad at making video games, it turns out.

But what we did luck into was another pivot into something else. Slack came to be because as we were working on the game project, which was called Glitch at the time and probably nobody here played Glitch — it’s also why it doesn’t exist anymore — when we were trying to make the game, we were split between San Francisco and Vancouver. 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, to customer support, we built it all into this tool we were building ourselves.

It was a great way to work together, and we didn’t really think about it as, like, we were building a product; it’s just we want to get our work done and we’re developers so we use software to do that. When we shut the game down and we were trying to think about what we wanted to do next, we realized that whatever it was we did next, we wanted to keep working together in the same way. It wasn’t just the tool set; it was the way in which we were working together. It made us a lot more productive, it made work feel different as a team of people spread across different offices around the world, and we thought if we like that as a team company of 40, 50 people at the time, maybe other companies doing similar things would find that tool useful as well.

That’s where Slack came from.

TB: You had used this for so long internally, you almost had this very extended private beta test, you were so stable in terms of even the user interface in many ways.

Henderson: We had the model almost 10 years ago now of that way of communicating. I think there’s two core concepts at the heart of the product that we stumbled upon. And neither of them, in isolation, was an entirely new thing. The first one was using channels instead of using email. That is, instead of one-to-one communication by default, organizing communication, discussion, and work around topic, whether that’s topic or project or team, and it’s a very straightforward idea, but I think the thing that it shifts is this idea of 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. It’s a one-to-one communication medium by default; you address the people you’re sending to and it’s a very push model. We switched to more of a pull model with channels where you choose to 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. If you leave that organization or that team, the information that is locked up in your inbox just dies. As work has become increasingly more complex, and more collaborative, and people join projects or teams and leave them over time, that ability to have a record that’s preserved independent of the people involved, I think, is huge.

Then on the other side is the applications and platform aspect. I think one of the most interesting trends, which is very tied to cloud-related topics, which I’m sure we’ll talk about has been the real explosion of software used in the workplace over the last 10 years. In a Netskope study, which is now even 2-years-old, the average mid- to large-size company is using more than 1,000 applications. That’s just an insane number of different bits of software. I’m not sure I could name 1,000 different bits of software, and that’s the average for a mid-size company.

That’s such a big change from a decade or two decades ago. What’s enabled that, I’m sure we’ll talk about, but where enterprises are using more and more software, where work happens has become more and 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. 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 layer.

TB: Absolutely. And Slack now has more than 10 million average daily users, so clearly, you’ve struck a nerve, and as we mentioned, you’re 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 learn from them?

Henderson: One is that when we started the company, I don’t think we had any vision of how large it could be, of how generally applicable it could be because when we were building it for ourselves, we knew that we’d built a product that worked well for teams exactly like us of somewhere between five and 100 people and initially of engineering teams building software. We knew that worked well for us and we thought that worked well for that use case. I think it became very quickly apparent to us that it worked across all different job functions and sizes of company as well.

So I was saying, to begin with, we definitely didn’t build it thinking that we’d have more than 10 million daily active users or beyond. 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. It’s not about if this goes perfectly on every possible axis, what is the total addressable market we’ll see over the next 20 years, and build to that, because the first thing you build is not going to be the right thing. The very first version that we put in people’s hands was definitely not the right thing. We needed to be able to iterate on that really quickly.

The focus definitely for the first couple of years was on finding what would translate from what we had built and worked for us to what would work for more people. So iterating quickly, understanding how other teams worked, and what the frustrations would be, and really honing in on that product market fit.

I’m an engineer, I’m very excited by new and interesting and exciting technologies, and I’m definitely interested on the large scale distributed system side. I think it can be super addicting to go and build something for massive scale, which you will then never see, and finding that balance is really tough. You don’t want to paint yourself into a corner and be able to build something which you will never be able to deliver at scale if you are successful, but it’s that iteration at the beginning that’s key.

TB: So you are on the cloud now. In fact, we know that you’re primarily on Amazon Web Services. Would you have been able to scale to the extent you have and efficiently as you have without those cloud technologies?

Henderson: It would have been much, much harder. Back when we started the first company and built Flickr, we had our own physical data center, and 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 install Linux from a CD, and then realize we didn’t have enough network cables, so then go down to the shop and buy network cables. That was a quarter to a third of all of our time was just useless undifferentiated work that we had to do.

The move from having your own physical servers at the small scale to moving to infrastructure as a service or platform as a service was an incredible time savings. It has really been the thing that has driven the ability for this explosion in software categories, because niche SaaS businesses that just could not of existed a decade ago without AWS, Google Cloud Platform, 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 product market fit.

TB: If you were launching something like 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?

Henderson: I think on the first one, sure, we made lots of product mistakes and now we have a lot more data. I think we wouldn’t make any of the mistakes we made. But I think the cloud side is more interesting and that is that we’ve moved a lot more from the infrastructure as a service 10 years ago to more of the platform as a service, and moving further up the stack, and being more hosted services as opposed to just, “We’ll provide you with virtual machines very quickly.”

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?” Now we use Kubernetes, and we use more high-level hosted AWS services, for instance. And it just lets us spend more time on the things that are unique to us as a service or a company.

TB: I know that circa 2015, there was an AWS case study, and you were relying heavily on EC2 at AWS. Is that still a core part of your infrastructure?

Henderson: Oh, it’s definitely still a core part of our infrastructure. I was definitely historically skeptical of higher level services. We’ve just started to adopt them more and more over time. Whether that’s on the data warehouse side, I think that was probably where we made a big shift first quite some time ago into more hosted services, but more across the board, we’re moving further up the stack. That’s the same from all the major cloud providers.

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

Henderson: We use a lot of different services and technology. I think Kubernetes and containers have been big for us in rethinking the way we make engineers effective and productive. It’s how much control of deployed services can we put in the hands of engineers?

The model of the past was you have an operations team, and that transitioned to everybody’s a bit DevOps, to more you don’t really think about it so much as operations. Part of building software is running it and deploying it now. I think lowering the technical barrier to being able to be dev-opsy by putting more tools in the hands of your developers, and that being the expectation of, “you build it, and you support that service,” has really changed how we think about building software.

TB: We know this from the S1, and I know you can’t comment on this, but we know that Slack spends a minimum of $50 million a year with AWS. 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 Slack’s operations?

Henderson: If you think about it from an efficiency point of view, engineer/developer time is actually super expensive. The idea that we will tune for the ability for fast iteration and for fast development cycles over anything else is probably what we’re concentrated on. That’s the real differentiator.

There are definitely very particular businesses where it might not make sense to use a cloud provider. You need a very particular resource at massive scale, or you need some kind of service or hardware that doesn’t exist in the cloud, but for nearly any kind of business of small to medium scale, it makes a ton of sense because your developer costs are high and your opportunity costs are 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, how to provide that next iteration for your customers.

TB: What if you were to say, “OK, AWS, we want to shift over to Google Cloud,” how technically feasible is that in reality? Because on the surface, it looks like many of these cloud services are similar, at least in purpose. Is that kind of migration possible or pragmatic or practical?

Henderson: The services, or at least the three big services, are more similar than ever, and they each have a particular thing that they’re better at or that they target more. It’s a lot of work and very dependent on scale, but as your application, as 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 queue service is the same as this queue service, but the exact characteristics under load or under failure conditions are things that you end up building around. So, there is definitely cost to do that.

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

Henderson: The thing that I’m most concentrated on is developer velocity. It’s how quickly can people iterate on it? For some time, like GCP as a provider were as far ahead in offering ML, AL-like services. So if I have a team that wants to build something around those technologies, then GCP is going to be the way to do that at that particular point in time. It’s that speed of iteration delivery that’s more important than anything else.

TB: Let’s talk about AI and ML 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 use, and implement. To what extent are you using artificial intelligence, and more specifically, machine learning in the Slack that those of us who use Slack experience every day?

Henderson: I think the answer is both interesting and kind of boring in that 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 ML for personalization on a small scale. It’s for making something a little bit more intelligent and a little bit better. It’s every time there is ranking of something, whether that’s ranking of search results, or a channel when you switch to it, or the person’s name in auto-complete when you go to DM somebody, it’s making sure that is slightly personalized to you based on your past behavior and a whole bunch of other signals that we record.

I think the effect that we really are starting to see of ML application across a wide variety of products is making the small interactions a little bit better. 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.

TB: 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 buried? That’s where I want the AI and the ML.

Henderson: I mean, that’s the kind of AI dream is your robot assistant that is better than a human being, and does everything perfectly. I don’t think we’re not going to get there incrementally. It’s not going to be a tiny bit better until suddenly it’s like a human level intelligence. That’s going to be some weird step function at some point, but I think there is a lot of incremental gain that we can 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 you use the product, and the more information that you put in it, and 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 whose DMs you always read from. That’s probably somebody who’s really important to you, that’s how quickly you respond to them, these are the topics that you talk about, things like that, so that we can personalize it to you. But I think that’s going to be a lot of incremental changes over time.

TB: It’s been interesting on the retail side, obviously away from enterprise collaboration, to see how Amazon’s retail competitors make cloud decisions based on their concerns about another sector of their business. Of course, you’re in an interesting situation because Microsoft has Azure and then competes with Slack via Teams and Office 365. Now, Amazon has dabbled in collaboration apps, 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?

Henderson: You know, we use a bit of GCP and a bit of Azure as well. I think that we think about that pretty independently.

TB: Are you confident enough in Amazon’s business firewall, as it were, to basically make that leap if Amazon were to compete with you directly?

Henderson: You know, I think that 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.

TB: You were hired by Stewart Butterfield after breaking into the listserv for his video game company. Is that a apocryphal or is that a true company?

Henderson: I mean, “breaking into” is a strong term. They just hadn’t changed the default admin password. But I was just super interested in this original game he was working on and was trying to gain every bit of leverage I could to find out more about the company. It was fascinating at the time, was in a kind of era before web APIs, and I was really interested in building some kind of data visualization and tools around the game. I wanted to understand how the internals worked so I could build a public API on top of it. Getting into the internal mailing list was definitely the way to do that. I wouldn’t necessarily say that that’s the greatest idea, but at the time, it certainly got that conversation going.

TB: That’s great. I was going to ask you if you would recommend that tactic to job seekers today.

Henderson: You know, well, I think the equivalent now, as the industry has matured a lot, is public bug bounty programs, and that’s definitely how we’ve ended up meeting a lot of people in the information security space.

TB: 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?

Henderson: Oh, that’s a good question. I think that has changed a ton over time because we’ve gone from a four-person company to 1,500 plus people today, and so the people that you hire in week one are very different to the people that we hire in year 10 of the company at this point.

One of the things that we really focus around, both because of the product and I think the way we that we think about building software, is being collaborative as an attribute of candidates that we look for. Because as work in general has become more and more complex, both from a changing external pressures of markets and technology moving faster than ever, and internal pressures of different expectations around people’s relationship to the workplace, more and more work has become teamwork. As more and more workers become knowledge work, and other work has been automated away, especially in our industry, the myth of the lone programmer who goes into the basement, and hammers away for a keyboard for a month, and comes out with some kind of perfect gem of software, is just so far from the reality of large scale development today. It’s such a team sport that collaboration is really at the core.

TB: In terms of pure tech two, three years out, are there specific things that you bet on or that you think about when you’re doing those interviews, and bringing people on, and building the product?

Henderson: Yeah. I think that the rate of change has really been increasing, especially over the last five years, in technology. A lot of the standards of how people build today, whether it’s any layer of the stack, have completely changed over the last five years. Slack’s not a very old company, for sure, but when we look at, 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.

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 what is the skillset that the majority of people, say, in front end engineer roles, what is the technology that they’ve worked with and what can they bring to the organization? If we’re using totally unique things in totally unique ways of working and building that nobody’s familiar with, that just makes recruiting and onboarding so much harder.

So whilst we’re definitely, on the one hand, looking at where technology trends are going, we’re very focused on what has been largely adopted over the last couple of years that we can adopt, too.

TB: Now, of course Slack is also a platform. As you think about the Slack API, what kinds of apps 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.

Henderson: Yeah. When I think personally about how I use Slack to get work done, I think that the best uses of 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 it with Slack, make it a bit more efficient, make it a bit more accurate, make you a bit more faster, make it feel better.

One that immediately comes to mind is the way that we use Google Docs for a ton of stuff internally. If I’m sharing a spreadsheet, or a presentation, or a document, it’s in Google Docs. If you share a Google document via email, you paste in a URL and somebody receives the URL. Whatever. If you paste it into Slack, we’ll 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 URL 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? I think that has probably collectively saved me about 500 hours over the last five years, and that alone, it just makes using Google Docs more enjoyable.

Henderson: Or we use JIRA for issue tracking. Every time I type a JIRA case number into Slack, instead of just being the case number, we blink it to JIRA and pull out the title and the status. It’s thinking about the software that you use every day, how could it be made more efficient, a little bit better, in the context of the discussion when you’re working with other people. How can you enrich that usage of those applications?

TB: It’s interesting because that really gets back to Stewart’s original vision and your original vision when you launched the company, making Slack the hub, so bringing those capabilities into Slack rather than leaving them to just simply operate independently in another app.

Henderson: 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, and bringing them into one place.

TB: Yep. One last question here and we’re out of time, unfortunately, but you’re very public about the fact that you’re colorblind. And you talk about this on your site, IAmCal.com. I imagine that must give you a real degree of empathy with technology users in general and the issue of accessibility in general. How has that influenced your life, your career as an engineer, and what could you impart to this audience about that?

Henderson: That is a great question. A huge number of people, especially men in the U.S., are colorblind, like one in eight has some form of colorblindness, so it’s this weird not really a disability because 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 between two lines on a 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, Slack doesn’t work unless everybody on your team can use it. It doesn’t work if you have somebody who’s colorblind and can’t actually read any of the text, or somebody with low vision, or somebody with no vision at all and needs to use a screen reader, or somebody using assistive devices, or this isn’t a disability, but somebody uses Linux. I think it’s important to think about all of those kind of aspects because we’re building an application that has to work for everybody or it doesn’t work for anybody.

TB: Right. That 10 million needs to become exponentially more in the years to come.

TB: What would you like to get across to this crowd of business leaders, business decision makers, and developers, and engineers that we have not yet talked about, as a concluding remark here, Cal?

Henderson: I think going back to the cloud piece that we talked about a little bit is that when you are in the early days of making software or product startup company, the most important thing to do is to optimize for that speed of iteration and finding product market fit first. 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 iterative loop quickly, and leveraging the providers and the technology that are available to help speed that up is the thing that’s going to make the 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 finding that product market fit and starting that growth.

Like what you're reading? Subscribe to GeekWire's free newsletters to catch every headline

Comments

Job Listings on GeekWork

Find more jobs on GeekWork. Employers, post a job here.