An Interview with Cal Henderson

Introduction

JR: Thanks for doing this Cal. You've been so helpful as we've been writing all the stories for the newsletter and checking our work and fact-checking us and we really appreciate you taking the time for this interview. 

Cal: There's nothing I enjoy more than correcting people. So very happy to be part of it.

JR: All right, you left Slack about 18 months ago. Is that right? 

Cal: Yeah, yeah. Man, time flies.

JR: How many Lego models have you completed in that time? 

Cal: Oh God, a ludicrous number actually. 

I spent the summer up in Canada where I spent a good portion of all that time building Lego. But right now, I'm building a 64,000 piece model of Notre Dame Cathedral, which I'm about 40 hours into and still have about 10 hours remaining. So that has actually filled a large portion of the last 18 months, and that does explain it. 

JR: Now, is that an official model, or is this one of these aftermarket ones?

Cal: No, that's an after market one. Their biggest official model’s like 10,000 pieces. So 64,000 is a pretty significant, you know, deviation from that. 

JR: And you've said and I've heard that you're just like an incredibly quick Lego maker. 

Cal: I mean, I'm not trying to brag, but yeah, like I'm a focused person and I like, you know, put on an audiobook on 2.5, 3 times speed and just like go at it and get it done. 

But this supermodel – supersized model – is, you know, pushing the boundaries of I can only do about ten hours at a time before I start to get back pain because I'm old now. 

JR: Ten hours at a time? 

Cal: Yeah.

JR: …and use this to unwind? 

Cal: Yeah, yeah, I guess so. There's not that much stress in my life. I don't work at Slack anymore, so there you have it folks. 

JR: Cal Henderson – just a regular normal human playing lego over 10 hours while listening to 3x audiobooks. 

Have you read or listened to any great sci-fi lately? 

Cal: Oh, yes, I have. 

Because I've listened to so many books, I do like 100 to 150 books a year. I have to go back and look at my list to know what I read more than a week ago. But I very recently finished Shroud by Adrian Tchaikovsky and I think that came out this year. 

That's really good. I generally like almost everything he's done. And that's his sci-fi especially. 

JR: Yeah, his “Children of” series has been fantastic.

Cal: People love the Children of Time, children of whatever series, but all of his other standalone books are great and strong recommend to read anything else he's written. 

Early Days

JR: I want to start by going way back to when you initially started working with Stewart and Serguei and Eric. It's actually not a time that I know much about other than…

Cal: It's pretty much before you were born.

JR: Aren’t we the same age? 

Cal: I mean, probably. 

JR: Anyway, it's been over 20 years since then, and you guys stuck together for four major projects: Game Neverending, Flickr, Glitch and Slack. 

That seems like a pretty uniquely long and fruitful streak for a founding team. What is it about this group of people that made you stick together for so long through so many ups and downs and different projects? 

Cal: It's a good question. 

I think we like each other, which is helpful. We have complementary sets of skills. We mostly lived in different cities throughout all that time. I'm not sure that was actually particularly helpful to it. 

But yeah, we just like working with each other and like the combination. I think all of our different sets of skills was really useful. And that we were all just driven to make things and the joy and the motivation was in creating stuff and seeing people use it. You know, if there was a passion for any particular area, it was games, maybe not Serguei. But it was games and so it wasn't like photos or online community or workplace communication, you know, that was just the products that we found that worked and the drive and the motivation was just making stuff that we use every day. 

JR: What were the really early days of working together like? You were quite young at the time. 

Cal: Yeah, I'm still quite young, thanks. 

Yeah, no, it was. I'm the youngest of the four, not by a huge amount, I don't think, but we were also all well. When I first started Serguei wasn't there yet, but Serguei had worked with Stewart previously at a different company. And so he was like he came in not that long after. 

But Stewart was in Vancouver. Eric was in New York and I was in London and so we were all, you know, just working together remotely, which was not such a big thing at the time because this was, you know, 2003 and I worked with Stewart quite a while before I met him in person. I met him and Eric at the same time at a conference in San Diego, which we flew to do the launch of Flickr. 

But before that I'd just spoken to on Skype, or, you know, in messenger. 

JR: Oh no way. So the whole time that you were working on Game Neverending, you never met in person? 

Cal: Yeah, and the Flickr prototype we built and it was the public launch of it where we met for the first time or the day before, probably. 

JR: Isn't that cool? Was that at that point did you move to the US or to Vancouver? 

Cal: Shortly after. Vancouver shortly after. And the idea was we did that launch in San Diego at what was the emerging technology conference. 

O'Reilly used to put on this conference for new and exciting technology, which the web was at the time. And we met up there, did the launch, then went back to our respective cities and countries.And then I was going to come out to Vancouver for like three weeks, along with Eric and we were going to just like intensely work on V2 of Flickr for three weeks. 

And I got out to Vancouver and I realized this place is really nice. I could just live here. I should just move here and I had recently split up with my girlfriend in the UK, and at the time you could fax the Canadian government and they would fax you back a visa, a work visa, and so I did that and then I just got to stay in Vancouver. 

JR: Oh, is that the first time that you lived abroad? 

Cal: Yeah, yeah, yeah. And it's the first time I'd ever been to Canada as well. 

JR: Yeah. And then you stayed and lived and worked in Vancouver for a couple years?

Cal: Like a year and a half before because Flickr was very, you know, it was a very short period of time between when we built it and when it was acquired by Yahoo. 

And then with the Yahoo acquisition, we moved down to San Francisco. 

JR: Got it. So back to working with the founders. How did your working relationship change over time from those early days prototyping something like Flickr all the way through to, I guess a couple of years ago when everybody was working together? 

Cal: Yeah, I mean less about the relationship between us and more just how the role evolved in general. When we were doing Flickr, you know, Flickr was four or five people. At the time we were acquired by Yahoo, we were eight of us, but it was like a very small core team and everybody just, I think the biggest difference is everybody just did stuff. There were no managers, there was no coordination. 

It was just everybody, you know, executing, delivering work themselves. And that was the biggest change as Slack grew, really. As Glitch grew as well, you know, because you were there at the tail end of Glitch when we were 50-ish people. 

But certainly Slack when it got into thousands of people. At some point I stopped writing code. Stewart stopped doing product design directly. And that was the kind of the biggest change that Serguei and Eric continued to be individual contributors and spent time, you know, writing code. 

Eric, you know, probably I think was the biggest committer for a really long time, even years after he left. And so he was just like a prolific engineer. Serguei was as well. And so that was different that they kind of kept on the same path they were on and, you know, and I switched over to pure management as had Stewart some time before. So that I think that's the biggest change, but the, you know, the dynamic didn't change that much, really. 

I think we saw less and less of each other because instead of being on a call for hours, all of us every day, it was, you know, periodically getting to see people as the work became more complex. 

Glitch

JR: So skipping over Flickr and the early days of Glitch, can you share your recollection of when you decided to shut down Glitch as a team? 

Cal: Yeah. It'd been something we'd been talking about for at least a year is, you know, we had periodic leadership calls or I just talked with Stewart, you know, every week and see how, you know, we are keeping a very close eye on the metrics and how things were growing and as we kind of did the unlaunch and relaunch of Glitch and tried to find that product-market fit. It's, you know, at the time we shut the game down we had a core of really passionate users who loved the game, but that was not nearly enough to kind of sustain it as a business. 

But we're in that kind of awful situation, if you like, of if it had been a success, that would have been great. And if it had been a failure, that would have been sad but clear, but we were stuck in this kind of middle, almost-success phase for a couple of years, really, with Glitch, where it was plausible, if not likely, that a change to the kind of like onboarding, new user experience, core game loop, a little change could bend the curve, you know, that the angle of of growth enough that it would be successful. But we weren't over the course of like the last two years, you know, of a four year project, the last two years, we weren't quite able to bend it enough. But we could see continuing improvement and up to the point we shut it down, the game was getting better and better. 

It was getting more and more fun. And people were it was stickier for new people coming into the game. But we just weren't able to get there quick enough. And I think that if we had got to the point we got to at four years after three years, then we probably would have continued doing it. 

But it had just taken too much time, which really means too much money to get to the point that we were at. And so this was a discussion we've been having every week of what are the metrics we need to hit to make this continue to make sense because we were kind of running down the clock on having to raise more money. 

And it would have been raising more money without the momentum that we needed to show that it was a viable business. And we already spent like $16 million or something developing the game and getting it to this point. And we had a tiny amount of revenue, but it wasn't substantial. And we, you know, it was we'd been talking about we're on the cusp of it for quite a few weeks, and then it was just, you know, we’ve got to call this now before we run out of money. 

So it was before we run out of money so that we can afford to lay people off and give them severance. and not like just totally run dry and we knew we weren't going to be able to go raise money. To raise a round to continue the game. So that's where what was that? November of ‘13? 

JR: Yeah. Yeah, that's right. Or no November of 2012. 

Cal: I believe you. That sounds plausible. 

JR: Yeah because we launched Slack in Feb 2014 and it was a full sixteen months later. 

Cal: Is that right? I really feel like we started the company in 2009. 

JR: I'll send you this interview and you can fact check it afterwards. 

Cal: Yeah, thank you. 

JR: What was your feeling when you made that decision? Were you relieved? Were you disappointed? 

Cal: Oh, I was mostly disappointed because, you know, Glitch was the reboot of Game Neverending, you know, or the continuation of that desire to build this particular kind of game and community and experience. And there are a lot of things going against us the first time with Game Neverending, you know, it was we were making online games which weren't a category at that time. 

We were in Canada, which isn't like a real country. It was hard for us to raise money. You know, there were a lot less people on the Internet, you know, and it needed people being on the Internet. 

And then the second time around we had a lot more going for us, like online games had started to take off. It was the era of Farmville, you know, there were people playing social games online. It was the era of the Nintendo Wii, which was introducing a lot more people to more casual group gaming. 

There are a lot more people on the internet. We had had success with Flickr, so we were able to raise money at like pretty pretty good terms. So a lot of things had aligned. The biggest pressure in the opposite direction was the technology that we chose at the time for the game was Flash, which made a lot of sense in the first year that we were building it and made less sense by year three when Steve Jobs made the like change in direction announcement to not let Flash on to the iPhone. 

And to, you know, open up the App Store instead. So the original strategy on the iPhone had been it's going to be Web apps, you know, running in the browser and then it was going to be, maybe there'll also have an App Store and then it was just App Store. And so the rise of people playing games on their phones, which didn't start until after we started Glitch, the rise of that combined with the, you know, the technology platform we had chosen meant we couldn't pivot to be an online game. Also, online like MMOs, don't really happen on mobile. 

The style of mobile games that have since been successful is a very different kind of idiosyncratic kind of game and it's a very different kind of experience. And so we built the wrong game for mobile and the wrong game for where the technology platform at the time was going. 

JR: And you felt like you would have run out of time and money to rebuild it for…

Cal: It would have been such a big reset and would have taken years. It's kind of interesting looking back or looking at what's happened with Glitch since, because when we shut the game down, we kind of public domained all of the assets, a lot of the code, and there were a couple of projects to try and reboot the game and build it, you know, kind of on a modern tech stack. 

They have all, well, the first two just failed and the third one is kind of limping along. It turns out it's really difficult to do. And the kind of post Flash world for games in the browser, it's actually much harder to make games. 

There's not, you know, Flash was such an amazing tool for making games in the browser that wasn't really replaced by HTML5 and Javascript.

JR: The other native tools are not really for the same types of interaction. 

Cal: And it's such a you know, you can do amazing things like Figma, obviously incredible piece of software that came out of that new set of tools, but it's, you know, it's just not the same thing. It's how quickly you could build an interactive experience in Flash. And, you know, people still haven't really done those kind of games since successfully in the browser. 

Starting Slack

JR: I've heard Stewart's version of deciding that we could make a product out of the sort of proto-Slack internal tools. What's your recollection of it? Deciding to work on something like that? 

Cal: So the process of deciding, we realized that when we shut the game down, we wanted to keep working together. The founders, whatever we did next, we'd want to keep working together. 

And so we were trying to come up with ideas of what we'd want to work on. You know, one of the favorites for a while was a bank because Stewart’s wanted to start a bank for a long time. I think he's gone off that now, but you know, we'll see. And we realized that whatever we did next together we'd want to continue to communicate and kind of work in the same style that we've been working on Glitch. 

And a lot of that was the messaging system that we had developed through the years working on Glitch. And I assume it was Stewart, but it might not have been, suggested, you know, what if we turn that into a product? Because other people would like working like that if they had a set of tools. 

And so that's why it became a contender. And I think there was a strong belief amongst the founders that at least some other businesses would want to work like that, mostly other small software teams like us, other, you know, kind of tech teams would benefit from having that channel-based messenger. Really, you know, IRC is good if it's usable by normal humans. 

And if you, you know, you add on some file sharing capability, and other teams would like to work that way. So there's just a belief. Now, you know, we didn't believe that it could ever be as big as it became. That wasn't part of the vision, really, but it was idea if it works for us, it must also work for some other people. 

And it's partially there's a product in the business we can build here and also partially, we think this is a really good way to work and we want to, you know, push that agenda on other people. 

JR: Can you remember any other serious contenders for what you might work on? 

Cal: I can't, but I know we had a few. And they're probably documented somewhere because we, you know, well, I don't have access to them now, but we imported all of the old Glitch IRC logs into our Slack instance at some point, and so the messages must be there somewhere and all of our, you know, old Google drives files and whatnot. 

JR: Did you ever consider taking a break rather than pivoting straight into something else? 

Cal: No, it never even came up as an option. I have until I like retired a year and a half ago I'd never taken, you know, more than a weekend between roles and I didn't even consider doing that because I just like making software. And so it was like, oh, well, you know, uh, what do we do while we're shutting the game down? 

It wasn't even, we'll wrap up Glitch and then move over. It was, all right, let's while we're shutting the game down and dealing with doing player refunds and, you know, building the legacy asset site and stuff like that. We should start something new at the same time. 

So there was never really any suggestion of taking a break.

JR: Yeah, I can remember building the Glitch the game stuff in the morning and then prototyping Slack stuff in the afternoon for like two months.

Cal: Yeah. That's totally normal. Yeah. 

JR: So you had a big success during the early days of Web 2.0 with Flickr. As you say, it was at a different scale at that time, but it was nevertheless a big success. Huge impactful product that a lot of people loved. 

As Slack started to catch on, was there a moment when you knew that it would be a success? 

Cal: I tend to describe that period as like boiling a frog, like, you know, it's gradually getting warmer and then, you know, it just seems like a nice warm bath and then eventually you die. So it's not the right metaphor because it wasn't, you know, it's kind of the opposite.

But it was all very gradual. There wasn't when you look at the kind of growth curve, it's a smooth curve that gradually accelerates. There wasn't some big jump-up point. 

I think the only really, you know, the only real kind of milestone that you can pull out is when we did the sign up for beta and got thousands of companies signing up for a beta. But also that doesn't really mean anything. A lot of people can sign up for intent and they won't necessarily, you know, adopt anything or start using it or be willing to pay or anything like that. 

And then when we did start the beta or, then when we started charging, it was all pretty gradual. So there wasn't some massive spike. We were like, whoa, this is a success. 

It was, you know, it was just building on itself for a long time. And so it was very clear at some point that it was going to be a success. And at first, it was going to be a success as much as we hoped it ever would and then over time it's going to be an even bigger success and it's going to be huge. 

But it was all very gradual. There's no sudden moment.

Leadership

JR: You alluded to this earlier, but at some point in, by my recollection, sort of 2015, maybe early 2016, as your responsibilities as CTO continued to grow and the company was growing so quickly, you stopped contributing code to slack. Was that like a purposeful decision, I'm going to do this or is it something that just kind of happened organically? 

Cal: I think it was a mix of, like the organic thing was I just spent less and less of my time coding because I had a lot of other responsibilities, you know, there was a period around that time when I spent about a third of all of my time on recruiting. 

So there was that one of those years where we grew like engineering grew 3X or something in a year and that was nearly all of my time spent on recruiting. And so I just didn't have as much time. But at the same time, during that period, the other trend was that we started doing like a 100% code review, we started doing more test coverage. 

It was more work to shepherd things out to production as things got more complicated and the team got bigger. And so both I had less and less time and the amount of time needed to get, you know, a feature built or a change out just required more time in a cycle. And so I started contributing less and less. 

And then when I just wasn't contributing much, I, you know, made a conscious decision to like, this just isn't a valuable use of my time anymore. My time is better spent as a multiplier on other people's time. So doing architecture review or helping people out with feature design or recruiting or strategy or, you know, management or whatever it was. 

But it was a realization that I love writing code. I still do it a lot, you know, do a lot of personal projects, but it was not the most useful use of my time for overall impact at the company.

JR: Who did you look to for advice as your role and the company became more high visibility and your responsibilities sort of grew to encompass thousands of people and billions in revenue and everything that Slack became? 

Cal: It's a good question. I think one of the most impactful things and we just talked about this earlier was hiring Michael Lopp, who came in as first VP of Engineering. 

And at the time when I had known Lopp for a little while, and at the time when he came in, my intention was he was going to be VP of engineering, I would be CTO and be more on technical strategy and pure engineering side and he'd take over all the organizational management pieces. It kind of went like that for probably six months to a year and then I realized that I really like value doing the organizational stuff as well. And I learnt a huge amount from him because he's like a much more seasoned leader than I am and really good, you know, real expert on the people management side, you know. I've read all of his books. 

It's funny like when somebody writes books about engineering management and then they are an engineering manager at your company ,and then you're like, “Huh, do you believe everything in your books?” But I think he actually does. I think it really is like he puts it into practice. But any time you're in a meeting with him, you're like “Hmm, is he testing something out for one of his books?”

Which is a funny experience. But I learnt a huge amount from him. I think the, you know, the challenge of being, you know, an engineering leader or an executive leader at a company like that is that your peers, the people that you're going to learn from are at other companies. 

And so you don't really see what they're doing day to day. And there's a good, you know, I'm in San Francisco, so there's a good network of tech, CTOs of bigger, smaller, you know, similarly-sized companies and we get together for dinner and lament whatever's happening at the time. And that's really helpful, I think, making sure you have that peer community was really helpful for mostly just having a dispassionate, like third party who has the same experiences as you, but is not so invested in the day-to-day struggles of your particular company. 

JR: Right. So Lopp was one of the early hires as you sort of built out your team of VPs and directors and then also adding Keith Adams as Chief Architect. Can you talk a little bit more about how you decide which parts of your work to focus on and which ones to delegate to those team members? 

Cal: Oh, it's a good question. And I don't know It was it was maybe less about what to delegate and more for where we needed more capacity, because I don't think, you know, you want to give people an area in which they operate that they own, but ultimately I was still responsible for everything and I'm on the hook for everything. And also they both knew lots of things that I didn't and I could learn lots of things from them. 

And they have very different work styles from each other and from me. And so it was like it's a negotiation of seeing what they want to do, seeing what they're good at, filling in the gaps. And I think I don't know if anybody else would characterize it this way, but when I look back at working with Eric and Serguei for many years it's clear kind of what Eric and Serguei both do. 

Eric's like front end person Serguei does services back end. And I always did the bits in between, fill the bits in between us and engineer like I'll take all the you know, I'll take all the middleware pieces, but also build systems and internal bug tracking and source control and whatever it is, you know, like everything that's left. And I feel like I was doing that a little bit also with Lopp and Keith of like figure out the things that they're really good at, they can go do it, and I'll do the other things that are left or take up, you know, provide more capacity for the things that they might be good at, but don't have enough time to do all of. 

So it's like, oh, spend a bunch of time on recruiting because that's where effort’s needed. I'll spend time on, you know, like, organizational values and goals or goal setting for the org or whatever it is, or external PR, you know, filling in the gaps. You know, when we were a very small company during Glitch, or maybe you weren't there during the smaller times of it, I guess? 

JR: I think I joined at like maybe 35 people.

Cal: It's still fairly small. It's just like at the beginning, I also bought the groceries for the San Francisco office and dealt with the internet provider and, you know, all of that kind of shit. Built the furniture. And it's just what you do when you're a small startup, you do whatever's necessary, right? 

And I think the same thing applies just at a different scale as the company grows. It's like somebody needs to fill in those gaps and, you know, eventually you hire people into roles as it becomes obvious you need somebody to focus on that thing, you know, and over time, a lot of the things that I did in the midyears, Ross, my chief of staff, took over, but it was like see where there's gaps and there's no job too small or dumb for me to do. But get the most out of other people's strengths and make sure that they're, you know, thriving. 

JR: I can remember both in the Glitch days and then in the early Slack days, you know, we would have our, I think weekly meeting where you had your mega spreadsheet. 

And you were delegating tasks at the granular level. You know, we had our columns for each person. You'd fill it in each week and check in. 

By the end, you were leading managers of managers of managers in some cases, you know, several tiers of that hierarchy. Any lessons that you internalized from that about what worked well when trying to lead at that scale across so many different tiers?

Cal: Yeah. It's interesting. So even at the time I left, we had done a weekly production meeting kind of forever. It changed in what we talked about and at what level. 

But the – was it called the Monday meeting? It was still called the Monday meeting, right? Yeah. 

At the time I left we were reviewing OKRs and we reviewed every OKR every week, talked about whether it was on track for that quarter, what the blockers were, whether we need more resources or to move them around. And I still stayed kind of very in the weeds up till the time I left. I knew every major project that was happening, what the status of it was, you know, because a lot of my job was kind of resource allocation. For reprioritizing things. 

And I think there's some scale beyond which you don't know almost everything that's happening in the company, you know, and I still tried to stay very in the weeds on everything we were building. Because it's the part of the value that I think I could provide was making sure that we were doing things we were learning in one part of the organization, we were then applying elsewhere as well and that there weren't projects that just went off down a rabbit hole wasting a huge amount of time for a long time. That at least every area where we were spending a reasonable amount of resources had some oversight that it was heading in the right direction. It was aligned with everything else we were doing. 

And I think that was probably frustrating for some of my engineering leaders that I was, you know, like in the weeds with what they were doing. But at the same time, I don't want somebody to go off for nine and twelve months and just waste a ton of time doing something that is not aligned with where we're going as a company because they weren't receiving any feedback. 

JR: Right. Sort of the forest for the trees oversight perspective that you could bring. 

Cal: Yes. I think so. 

But also, like, I'm still just very, I still have a huge amount of history with the product and know lots of things we've tried and where there are kind of tar pits and make sure that we're not doing the same thing twice in two different areas of the company, which does like happen a fair amount. 

JR: In addition to your organizational leadership team that you built out, you chose to remain directly responsible for the group of principal engineers at the company. Not that we were all reporting to you, as maybe a handful of us were, but you were overseeing a lot of our work and we were meeting weekly as a group of engineers versus as an organizational team.

How did you think about leading a group of senior ICs like that? 

Cal: I feel like it's interesting because both they're probably all better engineers than I am, because they spend all of their time doing engineering. And I think it was good for me. 

You know, as an organization grows, you never actually hear what's going on at all. You know, you only get the rosy optimistic version of it from product managers, engineering managers. And I think the group of principal ICs are more likely to give the super pessimistic version of things and it was a blend of like perspectives and also gives me the opportunity with both groups to steer them more towards each other and to try and help facilitate some of those relationships. 

But also the group of principal ICs, small group of engineers should be and were the most impactful engineers to have on any projects, and it was really useful to be able to repoint people towards where they could do the most impact and have the most impact. And, you know, the principals moved around quite a bit between things so that they were doing hopefully the highest leverage work at any given time. And having that pulse on both how both of those groups, you know, the directors, senior directors, VPs, and the principal engineers, I think was really helpful. 

JR: You saying we didn't give you a rosy view in that meeting every week? 

Cal: You know, you are probably one of the more optimistic principal engineers. You've met the rest of them.

Culture 

JR: All right. So we spent a lot of time nurturing a unique and resilient company culture. I've heard from many ex-Slack folks that that's what they missed the most since leaving. They've found great jobs on great teams, but it's not quite the same. I think Slack engineering had its own flavor of that culture, specific to our department. How would you characterize the culture that you were trying to foster within eng? 

Cal: Oh, it's a good question. 

I think ultimately, the company and the engineering org, our goal at the beginning, because when we started really talking about it, which was during the Glitch days and then we spent spent more time talking about it early Slack days, was we wanted to create the kind of company that if it grew to be big and successful would still be the kind of company we wanted to work at. And most of that was a reaction to like joining Yahoo in 2005, where the company was just a shit show in a whole bunch of different ways. We were like, well, we don't want to ever create that. That would be really sad. 

So what, you know, what would it be like to have a large successful company that was still felt really good to work at, that you could be creative and fulfilled and produce great work, but also enjoy doing it. But not feel like people weren't striving to produce great work that they weren't, you know, being pushed that they weren't growing. 

And also, it's like it's not a family. It's work, it's a job. And you want to be able to disconnect from that at the end of the day. 

Now, as like a founder and exec, I never disconnected from it at the end of the day, but you want a lot of, you know, you want most people at the company to be able to do that. And, you know, no company should be this isn't the 50s, no company is a life sentence, you know, nobody's going to work at Slack for the whole of the rest of their career. And so when people leave, I think the best thing the best marker that we did a good job would be that people go on to have great careers and start their own companies and want to take some of how they worked at Slack forward with them wherever they go so that they go on to, you know, kind of spread the word. 

And, you know, you have like the PayPal mafia, you know, I'd like the equivalent of that to be like Slack people go on to like create great culture elsewhere and great places to work. And maybe successful companies too. That would be great. 

JR:

I think of it as the Slack diaspora. 

Cal: There you go, yeah. 

JR: Are there aspects of our culture that you were the most proud of? 

Cal: I think the focus on craft of like being really proud of making great products that are well built. And the we talked about this a lot, that one of the greatest motivators for me is shame of like our work should be better. You know, I see I go to the coffee shop on the corner here and see people using Slack and I'm like, “oh God, they're using it wrong.” And it's because we did a bad job and we should feel bad. It's “Slack is a horrible piece of shit.” But that doesn't motivate everybody. And so that doesn't work. It works very well for the founders. It works less well for most other employees. 

But I think the care which we try to take over bits of the product and the bits the product that matter is that without killing people, you know, like that it's a place that you could work at for years doing that, not for like a year and then you burn out and you feel you did good work, but also it like destroyed your life when your marriage and whatever and your health. 

JR: Were there any aspects of our culture that you wished you could change and weren't able to, or that you tried to change unsuccessfully? 

Cal:
I think it tends to be the dark sides of our values. So, you know, we had a thing written on the wall somewhere of “Work hard and go home”, which the idea of which is like you need to be able to disconnect at the end of the day. So work really hard while you're there and then don't worry about it after you leave. 

And some people really just took the second half of the value of just like go home. And not work very hard or you know we had empathy as a value, but there was quite a bit of ruinous empathy of like never giving anybody negative feedback that would make them feel bad. That's definitely not what we mean. So it was just it was more where there were cultural problems it tended to be where people just took a different meaning of the value for themselves and drove that. 

And I think because we were like a very welcoming and inclusive and friendly culture, we did end up with some of the most difficult people to work with at times who were just, you know, we I'm sure you know some of the people I'm talking about who whatever benefits we provide, they complained about how they should be better. You know, the selection of sodas that we provide is not what they were hoping. 

Product

JR: After all your time at Slack, were there any major technical or product efforts you felt we didn't get to that you wished that we had? Like, speaking personally, we always had aspirations to doing like a full offline mode in the clients, and we never quite got there. We got pieces of it. A lot of people did a lot of great work. It got better, but we didn't really deliver that. It always just felt just below the line. And I've always regretted that. Like as a user I wish we had done it. Anything like that for you? 

Cal: Offline mode, yeah. 

You know, I wasn't a big believer in doing a native desktop client, so I don't believe that one. I feel like what we did with god, what's it called canvas, like was something we've been trying to do for a long time? And I think canvas gets part of the way there, but I wish we'd been able to kind of achieve the original vision of that from the original posts. 

I feel like we mostly got most of the way or most of the things that we wanted to do, honestly. There were still projects that were kind of in flight and not done when I left that I wish got finished while I was still there. Think rethinking identity and sign in, but then the route that we ended up with where we are now is not too bad, you know, the way sign in once by email kind of shenanigans. 

And every kind of every major tech piece of software has fucking horrible sign in and account management, you know, where like being able to have more than one account is just tough, but also necessary. 

Acquisitions

JR: We made maybe seven acquisitions, six or seven, maybe half of them for product, half of them for teams, give or take, some of them blurry in the middle.

Cal: That sounds about right. 

JR: When you think back over you know, our acquisition strategy to the extent that existed, what do you make of that? Were they mostly opportunistic? Was it about filling in gaps? What was the approach there? 

Cal: It was a mix, although mostly opportunistic, I would say the, you know, was I don't know there was any acquisitions where we were like, we need a company in this space and go out and look at a bunch of them. 

We did that a few times and then didn't make acquisitions. And there are I don't know that we regretted any of the acquisitions, but I would also say that none of them worked out as well as we hoped they would on the product side. I say actually the like pure talent acquisition ones – one of them I don't want to name names because then all the other ones would be sad, but there was one talent acquisition that just went out great. Like it was really good. 

I think we were always overly optimistic about the product piece I’d say in two ways. Always massively over optimistic about how quickly we could integrate something and overly optimistic about then how useful that product would be as, you know, a piece, you know, adjacent as an extra feature, as a product we could sell alongside. It's just like acquisitions are really difficult. Whatever scale you're at, whatever scale they are at is just really tough. They're all beneficial, but they all probably took at least twice as long as we initially predicted they would to bear any kind of fruit. 

And it's having been both acquired and done the acquiring is just like it's tough. The incentives are never perfectly aligned even when they're quite aligned. Plans change and things are difficult. 

JR: It's a bit of a tangent, but you know, acquisitions do offer so many folks here in SF and doing startups, an off ramp. 

How – this is an unformed question because I didn’t have it written down – but how do you think about that? I know there's been sort of like different waves of thought about the desirability of getting acquired and you've just talked about it as the acquirer. You’ve invested in a bunch of companies. How are you thinking about like the current, sort of acquisition ecosystem? 

Cal:
Yeah, I mean, it goes in waves of like crazy valuations tends to mean not that many acquisitions and then valuation comes down. People do a lot of acquiring. And then there's you know, is it like a firesale acquisition or is it a company that's on a growth curve and somebody else wants to use that to accelerate? 

So there's just it can be for a whole bunch of different reasons. and I think that if you're in a situation as a founder where you're like tired and don't want to lead a company anymore, then that's a good idea to go get acquired. And it can be a good idea for both sides at that point, because it will be, you know, your job will change immeasurably as a like if you're a CEO and you're being acquired, your job is going to change really significantly. And maybe you will go and stay on at the acquired company and definitely or maybe you won't. 

But if you're not like if you're done with that, then that's a great time to like go do that. But no, there's just so many different reasons for it to happen. And there are some acquisitions are incredibly successful, you know, like incredibly impactful for the companies that acquire them. You know, you look at like Instagram or WhatsApp or YouTube. You know, or LinkedIn but and then there's a lot that are just like whatever. I don't know. There's not really a formed opinion or anything. 

AI

JR: It's all right. Do you remember the master plan Stewart had? You know the four step, encompassed sort of platform, enterprise, share channels, and then the fourth one was “Do magic AI stuff”, which was always a fun Stewart-ism. In the wake of the sort of generative AI boom in the last couple of years, Slack on salesforce has been integrating features like summarization, generative search results, and the integration of Salesforce agents. 

If you think back to 2017, how well does this future match the magic AI stuff that you maybe imagined? 

Cal: Well, I definitely imagined, you know, like Salesforce AI agents. That was definitely part of it. 

And it's funny, and I hadn't really thought about this. But I was always pretty skeptical of the “do magic AI stuff” because it just seems like “part four, whatever happens with computers” capitalize on that. But it actually came really true. And I think the, you know what the features that Slack is building right now make a ton of sense, like improving search, like massively improving search. So there's a general problem with search for small data sets, is it's really hard, you know, it's not like Google search at all. 

It's not like web because, you know, even the largest Slack customer has billions of messages, not trillions and not much linking between them yet. And there's not much signal for any given search for any given result. There's just not there's barely any click stream on it. 

So you have to use different ways to make search good. And the LLM search is just much better. As well as being able to ask kind of natural language questions and get a comp, you know, a comprehended answer, because you're not necessarily searching for a message. You're asking what the status of a project is or, you know, something like that. So I think that's been really good. And then summarization also makes a ton of sense for, especially for larger companies and it does just work. It is pretty good. 

The kind of the current trend towards agents is interesting because Slack provides, as with kind of any work technology trend provides a good interface for it, a good place to put it. You know, back when it was everything is going to be conversational a couple of years ago, like's a good place for that too, if that turned out to be, you know, like a useful mode of, you know, everybody wants to talk to the Pepsi bot on the Facebook messenger, which was the trend from six years ago. You know, I think that Slack is continually well positioned to be an interface to whatever else you're doing with software in the workplace. 

JR: Yeah, that was, you know, where I wanted to go with the next question around. We were early with conversational interfaces in a way. It was trendy at the time, but this was before LLM's made that kind of natural language interface really possible. 

We ended up building a lot of chatbots that felt more sort of transactional, like, filing an expense report or whatever. 

Cal: You remember the onboarding that got like profiled on one of those like on boarding websites and got all the best possible on boarding experience? Turns out it's not actually good, but it just looked flashy in a demo. 

JR:
And it was unique.

Cal: It was unique, you asked questions, but like you had to stick to the script or just like it was a terrible experience. I guess we could have done the same thing with LLMs later and it would have been useful, but it was much more that it was unique and interesting at the time and that's why it was a good experience rather than because typing out full questions to computers is a useful way to work. 

JR: Yeah, that's right.  And so now we have the technology we were missing at the time of LLMs to power a true conversational interface that, as you say, comprehends the intent of a question and can do something useful. I was listening the other day to one of the leads on the latest Alexa version and the difficulties they've been having in converting that natural language comprehension into the kinds of transactional tasks and behaviors that you actually want your, you know, in their case, desktop speaker to do, or in our case, your chatbot to do. Do you think it's just a matter of time until we sort of build the pipes to make all that work well, or is there something else going on there that makes it uniquely difficult? 

Cal:
I think it's probably a matter of time because right now there's, you know, kind of transactional tasks that you want to do with filling in a form makes a ton of sense because you want to understand that it's been done exactly as you want it. And with very tight parameters and then there's the vague LLM conversation stuff where you want kind of the same experience as talking to a human where you don't know that you'll get exactly the same thing every time and it requires a lot of interpretation and context. And tasks tend to fit into one or the other category. 

Now, as, you know, LLMs get better in those two things capabilities get closer and closer together, you know, you'd imagine Alexa would, you know, be able to perform its primary function, which is setting a timer. And like reliably via conversation as opposed to via like a whole bunch of regular expressions, which is how Alexa, you know, worked historically.

So I think it is probably just a technology and capability gap there. But like I don't do, I think, spreadsheets will be replaced with conversational prompts? I don't think so because I think, you know, you just want often want deterministic answers to things and completely repeatable processes for things. 

But, you know, I think the use cases where we move to like conversational free form type things will continue to increase. As will kind of, bespoke runtime generated UIs for things, probably. 

Open source

JR:
So switching gears, you mentioned this earlier. You've supported open source software over the decades. With your own code and repositories that are quite successful, as well as various forms of direct and indirect support. We obviously used open source software heavily to build and run pretty much every aspect of Slack. 

You know, I used to spend a lot of time thinking about how open source fit into the world and have been doing less of that recently. What's your perspective on the state of open source today? 

Cal: I think I haven't really thought about open source and the kind of like LLM driven contributions to it, which is interesting. 

But I think it's still you know, 20, 25 years ago when we're starting Flickr, it was there wasn't a huge amount of open source that you could use for building things on the web because it's just early days and a lot of the companies that were doing big stuff at the time, you know, like Yahoo and Microsoft and Google were keeping it kind of secret how they did things. And then there was a kind of just an explosion of everybody doing it in open source and creating open source versions and things. And now it's just the norm, like I don't think it's really a question anymore. 

It's like, yeah, of course, like in almost every, you know, server on the web is running Linux and is built on all open source things. And there's occasionally, you know, important close source tools, but it's mostly open source and that just seems the default now going forward, at least for a long time.

JR: Yeah, it sort of just seems like a settled debate in some ways. 

Cal: Yeah, it's just won. Are there any projects – open source projects – that you've been paying attention to or getting involved in? Not really. 

And I do need to update my repose. I know I have some PRs that people have sent in in the last few weeks so I need to get on that. Apologies if you're one of the people who relies on that.

Silicon Valley

JR: You've talked about how the environment for startups is uniquely good in the US or at least in San Francisco and California, and uniquely bad back in the UK. I've seen some of the same in Canada in terms of few opportunities and just sort of a closed mindset and a more risk averse approach to things. 

Are you surprised after all these years that the success bred in San Francisco hasn't been replicated elsewhere? 

Cal: I'm not hugely surprised because I think all everywhere else, you know, for some value of everywhere has improved. It's just so has the Bay Area at the same time. 

And it takes generations of companies to be able to improve it for the next generation. You know, one of the big advantages that the there are a bunch of bunches the Bay Area has one of the big ones is that there's a history of so many companies here that have been successful and so the people who funded or founded or worked at those companies go on and mentor and invest and help the next generation of companies. And so it's a cycle that builds on all of these kind of layers of, you know, of companies that come before them. 

So you get this huge advantage. So then you got the talent and the money for those reasons and the California attitude. But I think it's the history that helps. And until you have that history, you can't build on top of it. And so, you know, it's going to be slower elsewhere and it's easier than ever to do a tech startup in the UK and Europe, but it's still way easier to do it here. And, you know, there are other structural advantages as well. 

Like if you're doing anything B2B in the fullness of time, most of your customers will be in America. And so if you start in America, that's easier. You have one giant market that you can sell into in one language with, well, like 50 something sets of tax code, but relatively speaking, you know, it's much more straightforward to sell into just the US than it is to every country in Europe. 

JR:
You mentioned the California attitude. What do you mean by that? 

Cal: So because the weather here is nice, all of the time, people have a very positive attitude and anything. 

Also like to start a startup, it is helpful to be deludedly optimistic, to like have a belief in yourself that is unreasonable because, you know, chances are you're going to fail. So why would you go do it? And the British attitude towards that is, yeah, why would you go do it? Don't do it.

And the California attitude is just give it a try. You'll probably be successful. You'll definitely be successful! And then when you're not, you'll definitely be successful next time. And I think that, you know, like that attitude of optimism is hugely helpful. 

And I think that drives a lot of, you know, people to strive. But there's also not really the tall poppy syndrome here that you get in a lot of other places of, you know, people who are successful are celebrated rather than cut down.

Alternative paths

JR: So going back again to your early career, you've been in computing since you were quite young.and have spent your whole career in tech.
Have you ever thought about, like an alternative universe where you went into something else? What would that have been? 

Cal: Not really, like when I was I was interested in studying physics at one point when I was a teenager, I was like, oh, I could do high energy physics if I didn't do computer science. 

But like, no, I wanted to do software indefinitely. And so I can't really imagine myself doing anything else for a job. At this point, it's hard for me to imagine ever wanting to work for anybody else. You know, I'm too difficult. So I kind of have to work for myself and all I would really want to do is software. 

You know, I have hobbies, but I wouldn't want to turn those into a job, you know. I don't want to be a professional Lego builder. It might take the fun out of it. Don't want to, you know, professionally bake things or make cocktails. That’s a miserable job, but a really fun hobby. 

JR: Yeah, I've heard that characterized as the trend of people in tech who work on big scale all the time. They choose hobbies that by sort of their nature can't scale. 

Cal: Yeah, I wonder if that's on purpose a trend or it's just most things can't scale. And, you know, like tech is somewhat uniquely big in that way. Like one person can go build something that impacts millions of people that's very hard to do with anything else. 

Salesforce

JR: You mentioned you wouldn't want to work for anybody else. And yet, at the end of Slack, you did work for somebody else for a couple of years. Can you talk us through the series of events that led to the Salesforce acquisition? 

Cal: Yeah, it was you know, I think the story's been told a few times, but we were fans of Quip, which was, you know, Bret's company that had sold to Salesforce in whatever year it was, and we'd been following it for a long time. It was interesting tech. 

And we were interested in acquiring it. And that's how the conversation started like, you know, are you interested in selling Quip to us? And the conversation with Bret got turned around and be like, are you interested in selling Slack to us? 

We were you know, we'd been a public company at the time for a couple of years and so once that started becoming a serious discussion, then it follows a process. And, you know, you have a responsibility to your shareholders as well, because we, you know, we were a public company and they were offering a lot of money for us. And so then it became a whole process and once those wheels start turning, they don't stop turning. 

And, you know, it's always hard to know what would happen if you didn't, you know, if you took any other route, like, you know, there's been a lot of boom bust cycles since in software. But there were and at the time we were we did the acquisition, we had been discussing for like at least a couple of years that well, we could never be acquired because nobody who would possibly acquire us has enough money, you know, the few companies that are kind of aligned to what we're doing, typically don't make big acquisitions. And so we will just remain independent forever. You know, modulo like merging with another similarly sized company, which is, you know, something we discussed a few times as well. 

And so it's kind of a surprise that somebody had, you know, like the desire and the pockets deep enough to make that happen. 

JR: Once the acquisition did close, what was your experience of the integration? You know, you had a pretty unique perspective as CTO. 

Cal:
Extremely painful. But I mean, as painful as we predicted, I don't know if it was any worse. You know, from a technology point of view, we were a company started in whatever year we started in relatively recently, Salesforce started in the 90s, was on a much older technology base. You know, the core of their products was old, but also very different kind of product. 

We worked in very different ways. You know, they were the pioneers of the cloud, but they do a few releases a year. We are, you know, like constant iteration continuous. What do they call it?

JR: Continuous integration and deployment.

Cal: Deployment, yeah. Like those terms didn't exist when we started doing them, so. We had a very different working style. And, you know, we were very kind of metrics driven at the product level, like strong instrumentation. 

We were a Freemium model. We were used by SMBs. They were large Enterprise only. 

They didn't really track any usage metrics. All sales driven. We had a big portion of our business still as self-service for SMBs. It's just a very different business. 

And as expected that was a difficult integration period. I know that at the same time, you know, when we were acquired, it was the rise of Bret as, you know, co-CEO and then, you know, sometime in Bret left and that was a big change in direction. 

JR: Yeah, do you imagine things would have gone differently if he had stayed in that role? 

Cal: Yes, I'm sure they would have gone differently. I don't know how differently, you know, like still would have been a big focus on AI and, you know, Salesforce would have continued doing its Salesforce kind of thing. But I think Bret had been a, you know, a tempering force of bringing some of our kind of values of how we develop and think about products and bring them to market. 

He'd already been doing that a little bit with, you know, the APM internally, it was like a way of looking at the products through metrics that hadn't, you know, that he brought in, a weekly meeting of understanding how all the different products were performing. And, you know, just an orientation towards thinking about product building in. He's a product person. And so that was a good influence and we liked the direction things were going and then uh, you know, and then he left unfortunately. 

JR:
Recently when we were hanging out, you said something along lines of you didn't at any longer feel an attachment to Slack the product and you were you were happy to kind of be able to pass it on. Can you talk a little bit more about that? 

Cal: I had spent, you know, however many years thinking about Slack constantly and, you know, especially being paged in the middle of the night and being on top of everything that goes wrong and every impact to our customers. 

And then pretty much the day after I left, I was like, “I don't need to care about this anymore at all.” I didn't, you know, I didn't think it would be like that, but pretty much the first day not working it's like, oh, yeah, no, that's not my responsibility at all anymore. And there are competent people who are in charge and I'm just not going to worry about it at all. It's like I still use Slack, but I don't have to be on it every second of every day. 

And so it was a kind of unexpected but very different experience to step away from it and feel like it just didn't matter. Like it was being taken care of, you know, and I care about the team and the leadership team that I left behind, but I just wasn't worried about it and didn't feel like it was my responsibility anymore. I’d spent a decade plus working on it. 

JR: Yeah, I had a similar experience. It's like you can garbage collect this giant array of information that you've been keeping in your head for a decade and thinking about it all the time, whether you're at work or not, suddenly you don't have to anymore. 

Cal: Exactly. Yeah. It was very very freeing. So that was good. 

Subscriber questions

JR: Okay, now we're gonna move on to some subscriber questions. So thanks to everybody who sent them in. We won't be able to get to all of them, but I have tried to pick a representative sample. 

First off, we have 10 questions from everyone's favorite engineer, Jamie Scheinblum. 

Cal: Oh, I’m having dinner with Jamie tonight!

JR: Question number one from Jamie for Cal. Was PHP a mistake? 

Cal: Uh, no, I don't think so. I don't think it was because any other technology choice we made at the time, we wouldn't have been able to build on or iterate as quickly on. You know, I think there's a reasonable reasonable question of was it a mistake for us to switch to Hack when we did. 

And I think if we had all the information that we now have, then maybe the answer was no we would have stuck with PHP and gone to PHP8 when it eventually came out, but I don't think PHP8 would have happened without Hack existing. And so, you know, we made all the right decisions at the time with the information that we had. And the advantages that we got when we switched to Hack of like, you know, same as switching to Typescript as, you know, like full – incremental but full typing, which fixed so many issues that had been kind of endemic and longstanding. 

So, no, no regrets on that. Sorry, Jamie. 

JR: Who was your favorite hire and why was it Jamie? 

Cal: Yeah, Jamie Rosenfield? Yeah, yeah, yeah. She was great. Aw man, I liked working with so many people over the years at Slack. We had so many great engineers, product managers, designers, you know, people in all parts of the business. And Jamie's okay too. 

JR: We had a shared mobile code base for a few years as we built LibSlack. Do you regret not sticking with it? 

Cal: I don't regret not sticking with it. So I think, you know, we tried to do shared code between clients in a bunch of different ways.

And I think fundamentally unless you do single codebase for apps, you know, you do like a Flutter type thing, then it just doesn't work. And we saw a bunch of our peer organizations try the same things and you can either have a cross-platform shitty app or you can have good apps and you basically end up sharing nothing at all. And I think that was, you know, we learned enough that it was too difficult to do it that way. 

The benefits did not outweigh the costs. I'm glad that we tried several times ourselves and expended quite a lot of resources on it because otherwise we would have always thought we could do this and it would be valuable. But I think we proved – we had real smart people working on it every time and it just wasn't possible to make it happen that way. 

JR:
What was the worst outage you remember?

Cal: You know, the ones that are the worst internally tend to be pretty different than the ones that are worst externally, you know, and almost certainly the ones that are like the longest things externally would have been in the real early days when it could be down for hours and it wouldn't be a huge deal to our customers because we didn't have many and they weren't nearly as reliant on us. You know, where some of the most impactful to customer ones would have been later and very brief, just when we had an awful lot of customers or it happened at a bad time. 

There was one that impacted Intuit on tax week, you know, in the US. That was really like it was very brief, but it was really impactful for them. So, you know, it's probably the most externally impactful. 

But one of the worst ones I remember internally was when we had some kind of Kafka outage,and we had we lost all of the job queues for like several. We lost several hours worth of queued jobs, so just like fucked up a whole bunch of things. I'm not going to explain in enough detail why this matters externally, but I remember the infrastructure team was in the Fremont office at the time, if you ever went to that weird 31st floor in the other building. And it was just like we lost all of the guarantees that we were using Kafka for and we weren't set up for what if we lose all of these jobs and can we replay them out of order? And that was just like a horrible, like day and night of figuring out how we can recover from this. 

And we just ended up, you know, like with a lot of messages and files and indexing jobs in a fucked up state, you know, that would have been very gradually repaired over years afterwards. 

JR: Right. Thankfully that's not what most of our outages looked like. Truly horrible. 

Do you feel vindicated that the world has readopted monorepos? 

Cal: Man, it feels like one of those things where if we've done it from the beginning, you know, from the beginning then it would have been good and that it was just too hard for us to switch to later, you know, because we ended up, we had a whole bunch of different repos. Some of them were on github.com, some of them were on GitHub Enterprise. 

You know, we weren't even on git when we started the company because GitHub was still fairly young and you know, and then GitHub Enterprise didn't have a bunch of features, so that's why we had things on github.com. And then later, I don't know, if we're even still on Enterprise these days, we, they, whatever, I don't know. There's a lot of disadvantages to it too, because when you look at, you need much more complex build systems, you can't do a full checkout, you know, like there needed to be features added to git later to make it reasonable. 

And there were like tens of thousands of repos in our Enterprise instance, and a lot of them were just like people messing about and garbage and it's like it is good that those things are separated out. It does mean that you can do it does make code sharing much more plausible across things, but you still have all of the kind of update order dependency issues that you get everywhere. So, I don't know. 

Everything's difficult. I'm glad I don't work on a mega code base with tens of millions of lines anymore and tightly integrated components. 

JR: For my job, the one big Webapp codebase where I could make a PHP change and a JavaScript change simultaneously was just wonderful to work on. 

Cal: It's wonderful, but you still had to really think about it when doing release, right? 

Because, you know, anytime you release the back end, it hits first in stages because it might take 20 minutes to roll out, but then also people are running old clients from two days ago. And you have to really think about sequencing there. So that's just complicated. 

JR: When was your favorite time Slack was mentioned in a TV show or a movie? 

Cal:
Oh, you know, I think it's it's not answering the question, but it was when it started to show up in news articles, but not about Slack and not even mentioning Slack. And it would just be like, you know, some internal company memo has leaked and it's just screenshots of their Slack chat. It's like, oh, this you don't even need to explain that this is Slack anymore. 

It's just this is messaging inside companies. You know, and it tended to always be bad news for whoever's being leaked from, but it's like, oh, yeah, that's just this just is the way people communicate now. Yeah, it's still cool when it shows up in movies and TV shows, you know, or still cool when I see people using it in coffee shop or on the bus or whatever. 

JR: Yeah, driving into SF yesterday, I saw a billboard for some app platform, whatever. And yeah, same thing. It's just screenshots of Slack and how you would use their tool within Slack. But it didn't mention Slack. 

Cal: Like of course it's just the substrate. That's what's cool is that it just became it's not like it became a verb like to Google something, but it just becomes a piece of like assumed infrastructure and that's cool. 

JR: Does the knockbrush sound cause you PTSD? 

Cal: It did for a while, but I think I was so used to hearing it. I mean, my phone's been on silent for, you know, a decade, but I was so used to hearing it constantly at work that like the sound just washes over me. I still have my notification sounds on for the house Slack that we use and it drives my wife mad that I have the sounds on. She's like it’s just making noise all the time. 

I don't know, it just washes over me. It's just the environment I was raised in, you know and you merely adopted it. 

JR: And an add-on to that Jamie asked, how about the hummus sound? Were you ever a hummus user? 

Cal: I never had hummus, but I see Anna, the originator of hummus fairly often and so, you know, it's just like having Anna talk to me. It's pretty normal. 

JR: Okay, last one from Jamie, which Slack channel from our Tiny Speck Slack do you miss the most since leaving? 

Cal: You know, there's a few that I miss. Like #devel-random, you know, having a good place to post things. #hennig.

JR: Explain #hennig.

Cal: It's unexplainable. It's just like a weird I don't understand why it was named what it was. It's just a weird channel that people posted weird things in. Yeah. Can you explain it? 

JR: No, it's completely absurd. A lot of teeth. 

Cal:
Yeah. There’s a lot of good channels, you know, I miss like the #princicals, which was me plus the principal engineers snark channel, but you know, what was the really terrible one? #devel-ics? [Editor’s note: #eng-ics] Yeah, the truly terrible channel.Yeah, you know, I even miss that kind of thing. 

JR: Okay, Andy Pflaum asks, with 2020 hindsight, are there any significant things you'd have done differently in the first few years of Slack? 

Cal: I think about that quite a lot and the obvious one is when we made the change to not bring like a fully hydrated client model, you know, like the state pushing the whole state to clients at boot, which we had to really change.

And then the other one would be the sharding strategy of data that we needed to really change. Now, they were only the wrong choice in retrospect after not even in retrospect, just when our audience started to change. You know, when we started to get bigger and bigger customers. And if we'd done it differently from the beginning, it would have been a lot more work to build it at the beginning, and then maybe we wouldn't have seen the success that we had. 

So, you know, there are things which I both wish we had done differently architecturally at the beginning, but also maybe we wouldn't have been successful if we did. So it's like a little bit, you know, kind of butterfly effect, do I really want to change that? And it ended up fine.

There's, you know, probably projects that we wasted time on, but like you said, with LibSlack, the cross-platform mobile library is if we hadn't learnt the lessons from that, we'd just have done it later at a different time, that might have been a worse time to do it at. 

You know, the more obvious ones is like people who didn't work out, who like, you know, you constantly say this to everybody, but never take my own advice. Like when you hire somebody and they're not working out, you know that you should get rid of them immediately and it's really hard to fire people. But then eventually when you do, you never regret it. So always like, you know, fire people faster. and that's something I would have gone back and done in a few instances. 

But also, I say that, but it's hard to fire people. So probably not. 

JR: This is a question from Myles Grant. How do you feel about optimal team size given the growth from eight of us to eighty to 800 to I think there's 80,000 at Salesforce? 

Cal: It depends, I think, is the answer. 

Like you you couldn't operate Slack the business, you know, or Slack the product at all on ten people today, you know, could you, you know, the minimum number of people that you could operate it on is a lot smaller than the team is, but also then you can build new things and push forward and support the current customers that you have. 

That said, you know, I thought it was going to be a slightly different question and the answer is about 10, which is that, you know, you need to be split up into teams of 10 to actually get things done, you know, like a PM, a designer, you know, eight engineers across various disciplines, depending like that's, you know, the kind of the pizza team, you know, a team that you can feed with one or two pizzas. Is that an Amazon term? And that's about right. It's, you know, a team where everybody can know everyone really well and you can know, you know, you can be coherent as a team at that scale. And so, you know, whether your company has one of those or a hundred of those, you know, like that's the right operating unit. 

The most fun at a company scale is like, you know, between five and twenty where everybody knows what everyone's doing and everybody knows everything that's going on. You can just – there's the communication overhead is just so much lower. 

The coordination overhead is so much lower. That said you just can't do nearly as much. So it's fun, but it's also just a very different stage of a company. And if you're you won't be able to, you know, there are some small teams that accomplish a huge amount. But on the whole, if you're successful, you're going to get bigger because there's more to do at the same time and more opportunity that you don't want to leave on the table. 

JR: Jacob Bijani wants to know, did Cal actually want to build any of the pivots more or less than the original products that they spun out of, going from a game to a photo sharing site and then from a game to a workplace chat app, both seemed like pretty big swings in terms of your day-to-day thinking and challenges. Related, did Cal ever actually want to build a game specifically, and does he still want to? 

Cal: Oh, yeah, no, I would much rather the games had been successful, you know, and successful in the same way, the same impact, the same outcomes, but the games were what I was most passionate about. So, you know, I’m really glad that both of the pivots worked out amazingly, but I wish the games had been successful in the same way. That was the thing I really wanted to work on. 

I have like a near infinite number of half-finished personal projects and many of them are games. So I'd love to be able to make a successful multiplayer online game thing. JR we should talk about one of my ideas. But I love what we ended up doing, but the games were the thing I was really passionate about.

JR: Aish Dahal asks, I'm curious if Cal still writes any code.
If so, what does a development environment look like? Is he still in windows? What does he think about vibe coding and as a bonus? Well, let's leave the bonus for a second.

Cal: I still use Windows everyday. My environment I feel like it gets worse over time. I mostly write code in an SSH terminal using nano, which has been my editor for a while. I don't even do it on my own desktop anymore. And I mostly write code in, you know, JavaScript or PHP as I kind of always have. And I have a lot of personal projects all kind of ongoing at the same time. 

Yeah, and I'm also trying to make some games with my eldest kid and we've been learning GD script in godot and building games in godot, which is pretty fun as well. 

JR: Cool. Part of the question there was what do you think about or have you done any vibe coding? 

Cal: I've I really like the coding side of coding, like doing it myself. I've done some vibe coding stuff as well, but it's you know it doesn't give me the same kind of same return on investment. That feels too clinical. It's not as fun. It's not as rewarding I find. But, you know, give it a try. 

JR: As a bonus, if you were building in 2025, what tools would he use, or would it again be a humble PPP application? I think he means if you were to do Slack again in 2025. 

Cal: Humble application, probably. I probably pick more or less the same text stack, sort of like Linux, MySQL. 

It depends if like if I was doing this myself, I'd probably pick a lot more high-level AWS services rather than, you know, when we started AWS was in its infancy and we basically just used S3 and EC2. And nowadays, you know, like go use RDS or whatever, or Aurora or something like that, not worry so much about the day to day scaling side of things and you know, use more kind of cloud native services.that exist for queues and things that we gradually move to over time. 

But at the core technology, like Linux, MySQL-ish, PHP, Typescript on the front end. Same kind of things that we did before. Native apps for mobile. That's definitely the way to go. 

JR: Erica Engle asks, is Cal still a big sneakerhead? What's in rotation? 

Cal: No, not so much. That was really interesting. It's a – really interesting is strong, sorry – interesting to me. During the pandemic, you know, I stopped leaving the house and stopped wearing different sneakers every day, and I just never really picked it up. So, you know, I haven't that's really fallen off, you know. That's one of the channels I miss is #fresh-kicks, which was, you know, one of our social channels and the only social channel that didn't get moved to the social workspace for reasons I don't understand. It was still in global when we did our re-architecture. So it was a unique channel. 

JR: Siddhant Mehta asks, what were Slack's biggest engineering mistakes early on that took a long time to entangle.
You've sort of talked a little bit about that already. 

Cal: Yeah, it was sharding strategy, sharding by team because we didn't think teams would individually get very big. And then pushing the whole state to clients at boot, which worked great for small teams, worked terrible for large teams. And they were both things that we kind of undid over time. 

And then I guess the second tier of things would be not having tight safety on the back end. That was also just like not a choice at the time we, you know, wasn't an option at the time we did it and having the front end be so entangled with like HTML generation versus logic. But again, you know, we solved those things later with technologies that didn't exist when we started. 

JR: Again from Sidd, what are some opportunities Slack the company missed out on early in its journey? 

Cal: It's a good question. I think the obvious one is doing more of the kind of community use cases that got eventually taken over by Discord. 

At the same time, that was also all of the crypto crime got taken over by Discord, which was great for us. And Discord is a great product. Like I use it and they learnt because they came shortly after us and was like, you know, what if you made Slack but also had Ventrilo built in? 

And they were able to learn a lot of things from us and sidestep some of the architectural blunders that we made. So I guess that is an opportunity that we missed. However, it's one that we consciously missed and we like, you know, foreclosed on that to go after a different area. And so I don't think we did the wrong thing there, but it's just an area that we could have gone after that we didn't. 

You know, similarly like a lot of the open source communities that, you know, like use cases that moved there, we could have captured more of. I think we did the right thing ultimately, though. 

JR: Vijayasks, looking back at your career, what were some mental models of decision-making that you found yourself revisiting repeatedly across different situations as you brought people together to tackle big, hairy audacious goals?

Cal: It's a good question. I think the technique that I have used a lot is asking seemingly dumb questions. And having people explain things to me as if I'm stupid. And sometimes it's cause I'm stupid. 

But I think it's useful to have people try and explain things from kind of like their first principles. And making sure I ask the obvious questions and that, you know, have people then explain things to each other, not just to me. And I think that's useful and understanding a lot of, you know, very smart people can disagree on things because they're not coming from shared context and they're, you know, like they're missing something that one of them is solving for. They're talking past each other. 

And so, you know, a lot of facilitation is just trying to get people on the same page so that they're arguing about the same thing and that they understand why people have different approaches. Now, sometimes people are just wrong. Like they have a missing some piece of information or they're lacking some piece of experience, but often it's that they're solving for different things. 

And so I think that's a, you know, like I am never embarrassed to ask dumb questions or seemingly dumb questions and have people explain things to me or, you know, maybe I'm lacking context or they're answering for a different reason. And I think that's useful is, you know, I think it's often the case unless you're a leader, you don't want to be seen doing that. And so that's a useful role that I can play. 

Rapid Fire Questions

JR: Alright. How about we wrap up with some rapid fire questions. Will you be upgrading to a 2025 iPhone and which one? 

Cal: Yes. I have the blue one coming shortly today, hopefully. I should have got the orange in retrospect. 

I realized I haven't had a phone without a case, you know, since iPhone started having cases. And so I don't even know what color my current phone is, but I got the blue one. Should have got the orange, should have been more daring.  I will regret this for the next year. 

JR: So that's the 17 pro. You get the big big one, right? 

Cal: No, I got the small one. I have dainty hands and my thumbs cannot reach across a Pro. Neither can I lift it with my weak engineer arms. So I have the regular Pro, not the Max. 

JR: What was the most recent app you downloaded to your phone that actually stuck? 

Cal: Oh, it's a good question. I feel like I've been in a kind of era of not really installing new apps. Probably the one that's relatively recent for me on my phone is Obsidian, which I've been using for notes on the desktop for a while, but now have it on on my phone as well and that's just useful having synced notes between all of my computers and my phone. 

JR: What was the most recent piece of hardware you bought? 

Cal:
I mean, I'm not going to count the phone that's coming. I don't know if this counts, but it was my my elder son's birthday recently and we got him a 3D printer and so we've been 3D printing lots of like knick-knacks, which is mostly like just making new junk for the house. But it's it's kind of cool. We've been learning. 

JR: Which LLMs are you using the most? 

Cal: ChatGPT. Yeah, because I'm not professionally coding, so it's not like I'm using cursor every day and the Claude stuff. So, you know, mostly chat. 

JR: What was the last video game you completed? 

Cal: Does one ever really complete a video game? You know, I play with my kids, I play a lot of Minecraft. We've been playing Satisfactory again this week. That game is so good. Really fun. But also my favorite game, if you can call it that on iOS is one of the Sudoku ones from the guys that do Cracking the Cryptic, which is a good video series that started out in cryptic crosswords and now it’s weird Sudoku. 

And they just released a new expansion pack last night, so I stayed up till midnight working on those. And that's what I'll be doing immediately after this interview, continuing to work on those. 

JR: What was your favorite Slack feature? 

Cal: That's a weird question because my favorite feature is probably channels, but that's like a boring answer to it. Actually, I'm going to say emoji and custom emoji. I think it was in some ways one of the most impactful things that we did for kind of workplace communication. 

The channels are really important, but the emoji meant that like it was a much less formal way of communicating than email, which I think was an important impact. And then the custom emoji meant people made it their own, made things their own. 

JR: Most hated Slack feature or bug? 

Cal: Most hated bug is anything to do with offline syncing mobile and, you know, like am I seeing the messages that have been sent or not? Yes, it's probably that. 

JR: Do you have any top hidden gem recommendations here in SF that you want to share? 

Cal: Hidden gem? Go for lunch at Cotogna. So fucking good. 

JR: How about in Tokyo? 

Cal:
Oh, so many cocktail recommendations. I need to remember the name of this one bar that I've now been to. I discovered with a friend of mine and then took my wife there this year that basically just does whiskey highballs. Seats like 10 people. 

It's super dark and only plays Tom Waits. And then every time the singular bartender makes a drink, he turns on a spotlight on the bar and makes it in the spotlight so it's a real performance thing, but it's also super depressing. And you can only go there for about one drink before you want to kill yourself. I love this bar. [Editor’s note: This is the Apollo Bar]

JR: Speaking of cocktails, do you have a current cocktail obsession or preference? 

Cal: You know, I'm hosting a school cocktail party tomorrow night, so I'm making batch cocktails right now and last night I made honey butter and then used it to fat wash a bunch of bourbon for making honey black Manhattans. And I'm very excited to be drinking that tomorrow. 

JR: Sounds incredible. What is your favorite Taylor Swift album? 

Cal: Probably Reputation, which I know like isn't everybody's favorite, but is a very different era for her. But like Reputation is solid. Was that a question from Mark? 

JR: That was one of mine. That should have been from Mark. That one’s for you buddy. 

And final question, will we get a new Radiohead album in 2026? 

Cal: Here's hoping, you know, like every year should be a new Radiohead album year, I feel.

JR: That seems like a perfect place to end it. Thanks Cal. 

Cal: Thanks, man. Good to see ya.