• johnnyrodgers.is
• buildingslack.com

Allen: Welcome to It Shipped That Way, where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Allen Pike, and today’s interview is with Johnny Rogers. Johnny was a founding employee and principal engineer at Slack where he worked for 11 years seeing the company from inception, to phenomenal success, to IPO and beyond. Welcome Johnny.

Johnny: Hi, Allen. Thanks so much for having me.

Allen: Thanks for making the time. I’ve been a huge fan of Slack as a product and as a company since the very early days. It’s long been an inspiration for how I think about startups, how I build startups. So I’m very keen to pull out some of the tactics and lessons that you built up over the years for my own purposes as well as our audience, of course.

Johnny: Great. Yeah, I’m excited to share whatever I can.

Allen: Awesome. So before we get into it, how do you like to sort of summarize your story so far in a kind of soundbite sort of way? The Johnny Rogers story.

Johnny: The really short version is I worked for myself doing sort of general web development through my twenties. Then I went to grad school, couldn’t get a job, cold-called Stewart, got a job working on Glitch at Tiny Speck, and sort of the rest is history. Like you said, I was an engineer at Slack from 2012 until last year when I left. And yeah, I’ve lived here in Vancouver since 2008. I live with my wife and two kids and we just got a new puppy, so that’s what’s keeping me busy these days.

Allen: I love that I can barely resist the urge to not click into that. Couldn’t get a job and cold-called Stuart, and next thing you know you’re building a generational company. I’ll just pause that for maybe a future conversation because today, the job is to understand building Slack. You’ve been doing a delightful job documenting those early days, or at least so far, the early days, over at the perfectly named blog slash newsletter, Building Slack. Buildingslack.com, at which I encourage everybody to read the archives so far. I’ve been voraciously, well, voraciously went through and then now I’m sort of eager for continuing chapters of it. But I want to use this opportunity to kind of go past what you’ve written so far and dig into some of the questions that came up and curiosities from what you’ve written there. But can you start off just for folks that don’t have the context, you don’t have to present it in the same way as on the blog. But can you give people who aren’t familiar with the story a little bit of context about the origin so then we can kind of build from there and fork off from there? There’s this day one scene, Stewart has an idea for a thing.

Johnny: Yeah, sure. So for those who maybe haven’t read the articles or followed the company over the years, sort of Stewart and the group that founded Flickr way back 20 years ago in Vancouver, they sort of famously pivoted from a game, an online game called Game Neverending, which didn’t take off. And then they pivoted to that to photo sharing before anyone else was doing photo sharing on the web and built Flickr, they sold that to Yahoo. They worked at Yahoo for a little while. I think they were happy to leave when that time came to an end. They came back to Vancouver and they wanted to do it all over again. So they started a game called Glitch, which was beautiful and creative and quirky and had a lot of love poured into it. And the people who played it loved it, but there just weren’t enough people playing it to make a business out of it. So that was sort of where I came into the story. Like I said, I asked for a job just as a sort of generalist software developer, was lucky to join and work on the game for about eight months, which was so much fun. But Stewart came in one day and let us all know that the business was not going to be viable and we were going to pivot the company to something else. And so some of us stuck around to work on that, and that’s what became Slack. So Stewart’s idea was take the tools that we had built for our own internal communication in place of email and turn those into a product, and that became Slack.

Allen: There’s this, and I know this is famous, but there’s this such a bizarre irony or it’s like it was written by a poet or something that Stewart tried to make a game and then that failed. So he made Flickr out of stuff that they had done for the game, and then so he tried again to make a game, and then that failed again. And so he made Slack out of… It feels like you could just, I’m sure he doesn’t need anyone’s money anymore, but a VC could just make an entire career funding Stewart to make games and then whatever he does after that.

Johnny: That’s right. The most successful failures you’ll ever hear about.

Allen: I know. But it always bolsters me and I think many other entrepreneurs that you’re always learning things when you’re building, even if you’re not learning the things you set out to learn sometimes.

Johnny: Yeah, that’s right. And I think Stewart has told this story eloquently before that one of the reasons that Slack from its inception felt just so highly useful to the teams that started using it was that we had only ever put as much effort into it as it needed to work well. And we hadn’t spent a lot of time waffling on expanded imagine feature sets or layers of polish or iteration. It was basically just like the most bare bones utility you could imagine for our own internal communication. And he sort of references the years that it kind of crystallized within Tiny Speck as being maybe the best sort of incidental way to create a product, which is we were totally focused on something else which was making the game successful and we just needed this as a tool set. And so it was just completely pragmatic, every decision about what kind of time we would invest in it. And what that resulted in was by the time we pivoted to actually turn it into a product that we could sell to other people, it already had a sense of fully formed-ness to it that I think is pretty unusual for when you’re starting a new product.

Allen: I love it. So reading that story of the Slack team building out something that you all had been using but then building to something that the general public could use and preview, as an observer reading the story, it feels like almost too good to be true. And some of it is what you just mentioned, which is that you already had something that worked and you were using. But something that I find kind of surreal was this story, or at least the way it condenses down is like, okay, you describe adding features that we all take for granted today as kind of a matter of course. Like, “Oh, and then we added an unread marker. And then we added URL unfurling.” And these things that are just core ways that we all communicate or almost everyone communicates in their work today. And so I’m curious, when you were building all this, did it feel obvious even back then? Or were any of those additions that either felt like a big epiphany? Or anything that you added at that time that you needed to then undo or walk back and kind of got lost in the sands of time?

Johnny: Yeah, I’ve reflected on this a lot because it’s still in hindsight, and even though I was there, feels a little bit miraculous. I mean, I would divert all credit basically to Stewart and the other founders foresight in some of these decisions. I think they had been through a lot of different types of software and had really good instincts around this stuff. I mean, a lot of it was based around what was missing from IRC. So there were hundreds of thousands or maybe millions of people familiar with the conventions of IRC, but the biggest deficits of it, lack of native file sharing, lack of coherent search, that if you weren’t online, you didn’t get the messages. So there was sort of an inconsistent archive. And that you couldn’t tell other than from your own memory what you had or hadn’t read. Those were the big gaps. And so a message-based system for keeping up with your team felt like the right vehicle for what we were doing. And then there were these obvious missing pieces and those were the ones that we added, and that’s what really formed the core of the app. And of course there’s a decade of accretion of features since then, but that core has remained the sort of stable foundation that everything else is built on. Yeah, all of that came about so quickly that it is hard to think about it as anything other than preordained thinking back to it. And this is this few months that it all came together. And then most of our effort was on making sure that we had something that could scale to the customers that we wanted to release into, and that we had all the other pieces around it that were necessary to make an actual product that people would feel was worth paying for.

Allen: Yeah. One of those pieces that I’m always fascinated about the feedback loops and mechanisms and how we’re learning from our customers and our users. And of course Slack had this, or from the early days, this slash feedback command and feedback mechanism that let people very easily in the tool send you feedback, which gave you a lot of oxygen for improving what you’re building. Was the team also spending time with other kind of user research like interviewing users or having support calls or anything like that? Or was it responding to that in-app feedback mechanism the vast majority of the time you’re using, learning about your customers and what they were needing?

Johnny: Yeah, the latter. We got a ton of volume of feedback directly through that slash feedback command. For people who maybe didn’t use Slack or don’t use slash commands, you could just type slash feedback into the message input and then write whatever you wanted, share file, whatever, and it would come out to us and then we would respond. So via that, via typical sort of customer support tickets, I think we had an early version of Zendesk that we were using. And then tweets and emails, it was all that kind of uncultivated direct feedback from early users. And actual users, not just people who were sort of contemplating it, right? That was 90 plus percent of our customer feedback diet. We did have an early person, James Jarrett, who’s based here in Vancouver, who was sort of sounding out some of the market from his perspective and I think he spoke to a lot of customers. But I think that was more sort of fact finding and not the kind of feedback that you’re talking about. That was and remains such a wonderful way to build a product. Do the best you can, put it in front of people, see where it breaks, see where it bugs them and rapidly iterate on the information they give you back. And I think it’s underestimated how important that is, and I still weigh that far more highly than any of the other more sort of codified research practices. It can be as simple as the paper cut that somebody gets from a rough edge that you haven’t sorted out yet. If you can fix that for them and get back to them promptly, and I’m talking hours or days at the time, first, you’re solving a real problem for a real human trying to use the tool that you’ve built. And that’s just the best feeling in software for both parties. You’re making the product better for everybody else who maybe has also experienced that paper cut but hasn’t said anything about it. I always sort of mentally magnify any customer feedback report is probably at least 10 or a hundred other people are feeling the same pain but not saying anything. So you’re making it better for everybody. And then for a new and growing company like we were at the time, the amount of trust and bonding that you’re doing with those early customers, I think it’s really hard to measure, but it’s very real. To have an actual human at a company reach out and say, “I’m sorry you hit this problem. I’m sorry it caused you difficulty. We’ve fixed it. Does it work for you better now?” And then genuinely maintaining that conversation forever. We still to this day respond to every customer feedback request with real people. And we cultivate that sort of ongoing conversation between the customers using the product and the people making it.

Allen: Yeah. And there’s something really magical that happens. This is a theme on the show. I pull this out whenever someone has mentioned doing this, like Dennis Pilarinos was talking about this same loop for what he’s been building is, if you respond rapidly to someone’s feedback and then resolve it, especially if you resolve it promptly, then you are creating a positive incentive for them to continue to give you useful feedback.

Johnny: Yes. Yeah, exactly. And it’s interesting because the kinds of things that I’m talking about at the time were relatively sort of, I don’t know, like shortwave feedback, like this button is broken or this file type is not rendering properly. That kind of simple software stuff that we were often able to fix very quickly, we just hadn’t bumped into that particular edge ourselves yet. And then of course as we grew and people came to expect more from the product and had more of an investment in it in their own usage, we got sort of what I think of as longer wave feedback which manifested in things like, we need threads. A single layer transcript in a channel is not enough. And that is of course not something you’re going to turn around in a day. That was two years of effort. But I think even with that, our customers really did know that we were listening and we were constantly talking to them and replying and giving them workarounds. And then when we did actually release it, one of the cool things that we did, or the customer support team did, was they went back and they found every single request that people had ever asked for threads. And they personally responded and said, “Hey, Alan. I know you wrote us 18 months ago about this, here’s what we’ve released. Here’s how you can learn more. We would love to know what you think of it.” And I think that’s what I mean by sort of cultivating that conversation. You’re showing a degree of respect and responsibility and humility about what you’re doing that I think people really respond to, and that most companies and most software certainly doesn’t provide. So I think that’s a real differentiator for us.

Allen: Yeah, I love that mentality too. It builds, it’s a good habit, but it’s also, I think it builds a good mentality about how we think about our customers. I would like to, if you’re up for it, take a left turn into this thing you just mentioned, which is threads, which was one of the most controversial things in any communication platform. Whether it’s a team chat or a forum or everything kind of in the history of communication, there’s some debate or struggle about the design and product consequences of how threading works or doesn’t work if it isn’t present. Can you tell me just at a high level a little bit what that path was like? Kind of realizing that it needed to be solved and then some of the challenges of building it, and then some of the trade-offs that kind of ended up coming together in building that?

Johnny: Yeah, for sure. First I’d say, how much time do you have?

Allen: I know. We can probably do an entire podcast on it.

Johnny: Yeah, no, it’s complicated. The other thing I would say on this and many other topics I’m sure we’ll touch on is of course, I was just one person there. There were dozens and then hundreds of people working on this, but threads were really fascinating from the inside. Slack is based around channels, and channels are topic-based or personnel-based, department-based, all sorts of other ways to organize them. And depending on the number of people in a channel, say up to 10 or something and depending on the types of things that you talk about, a single message stream, which is what we launched with, is perfectly sufficient. But you do get to some level of volume of people or sort of divergence of topics or specificity of topics within a channel where something like threading does become necessary. We had message sharing from the beginning where you could sort of like, the equivalent of a Slack quote tweet. You could pull that message into context and say, “Hey, Alan, in regards to this, X, Y, Z.” But that’s a fairly sophisticated behavior that not most people are going to do, and it’s a little clunky. It doesn’t really sort of unify that sub-conversation in the way that people wanted. And so we felt this ourselves. One of the sort of often told stories about Slack is Slack, the product always worked best for the size of Slack, the company that it was at the time. And we went from being eight and then 20 and then 50 and then hundreds of people. And as we grew and as we became departmentalized and that kind of stuff, we started to run into the limits of a single message layer in a channel ourselves. So we felt the pain and a lot of people who were asking for it as is typical, they were imagining something that they already experienced in another product and saying, “Why don’t you just do this? Just do Twitter threads”, which are an endless tree. You can thread off a thread off a thread. Or just do forum-style threads like Reddit does, which is slightly more sensible but still pretty complicated and certainly didn’t visually work within the context of Slack. So we tried both of those things and many variants thereof, and we actually lived on those variants internally. There were at least two or three major versions that we lived on for months at a time internally to try and really figure out if it was right, and then dozens of sub-variations within that. And that was an example of sort of the dogfooding that we constantly did. We were always living on the latest version of our features so that we could be sure that they were right. And we also understood that threads was really one of these one-way product doors that if we got the model wrong, we were going to live with the consequences of that for many years. It’d be very difficult to undo particularly because once you put people’s data into a structured format and you want to migrate something else, that’s going to be painful. That was all the context. What people were asking of us, somewhat of the faster horse type of idea, and what we were living on and trying to learn from internally. There was really active debate from everybody, from people internally who said, “No, we just shouldn’t do this. It complicates it too much.” All the way to people who had really strong conviction about specifically what it should look like. Anyway, after about 18 months or two years, what we eventually shipped has sort of maintained to this day. We haven’t changed the model of threads since then, but as you said, it was controversial. It introduced this very disruptive new set of somewhat unknown expectations into chat. And people who are active repliers and even if it’s the last message in a channel are going to use the reply button instead of just writing in the main channel. People who never reply on threads and so were constantly mixing up conversations. And of course, for us, it went from this somewhat novel but understandable model where it’s like, “Do I have unread messages in this channel or not? Am I up to date or not?” This little mental calculus that people do when they sit down and look at their notifications, to being quite a bit more complicated than that. You might have numerous unread threads across many channels even though you’re up-to-date in those channels. And it also introduced this sort of fear and anxiety in some folks who really wanted to make sure they were up-to-date on everything that they missed something, that they would scroll back in channels that were read to see if there was new replies on messages that they hadn’t subscribed to in the moment or hadn’t participated in that conversation in the moment. So it was something that we felt we couldn’t not do. The product had gotten complicated enough and people were using it so intensely that we had to support the necessary complexity of human conversation in channels. But we had to be as certain as we could be that we got it right, and finally, that we didn’t take so long that people would sour on what we were doing and feel so frustrated and move on. So yeah, that was a huge mountain for the company and for the teams working on that product. My personal perspective in hindsight is that we got it right, that the team sort of finally delivered something that balanced those concerns correctly and then rapidly iterated on the things that could be improved, but that the model was right. And that I think from when I was there last year, the data showed that people were actively using and making sense of.

Allen: Yeah, I appreciated that loop because I was one of the people who was very nervous about what it would do to user behavior. I think very much in terms of how’s my team communicating and where’s everyone’s attention going? And all norms and stuff. And I’ve seen various… It is fairly obvious the ways it could go wrong, like you say infinite nesting and all these sort of things. And when it very first launched I was a little bit skeptical, but then obviously as the years go by it’s like, “Well, of course this is the way threads work.” And everyone’s used to it and all the norms have developed around it. So I think it sounds very true to me that it proved right in the end, and I’m glad you all took the time to do it even though I’m sure it was a little bit painful. Speaking of features that have now seem, “Of course you have it”, but weren’t there at the beginning, one of Slack’s great gifts to the world was the concept of emoji reactions. The Reacji. How did that one come about? Was that just kind of someone just like, “Hey, let’s try this.” Or was it like, “Aha, we have it. Something amazing.”

Johnny: This is one of my favorite stories. It’s one of my favorite things about Slack. And whenever I see reactions in whatever weird product I’m using out in the wild, I always sort of smile. It’s nice to know that we had a little bit of an impact there. The story is really straightforward in a way. There were sort of two things going on. One was that, as I said, when we were getting bigger, we were sort of bumping into the limits of the volume of chat in the channel. And something that we had set up from the early days was this stats bot, which every hour or every time we broke a stats record, would post into our general channel, which is where most of our work happened, and say, “New connected users record, 50,000 simultaneously connected people.” Or whatever happened it to be, or some dollar threshold of recurring revenue or something like that. And on the big milestones, say a million simultaneously connected users, everybody would want to celebrate. And that was just before replies, or sorry, before threads. And so people would write in the main chat their message of congratulations or enthusiasm about it, which was basically noise, right? You’d have something and then dozens of messages below it, some variant of the “ta-da” emoji or a little “woo-hoo” or whatever. And so we recognized… So something Stewart said was, “Only the first five people can write something. If you miss the boat, please don’t fill up the channel with junk”, which of course was just a stopgap, but it was kind of funny. But it did create this initial idea, “Well, wouldn’t it be simpler if that was almost more like metadata on the original message?” Again, this is before threads, so we were sort of missing that piece of it. And I think it was one of our early product managers, Matt Mullen, and one of our early designers, Matt Kump, and finally one of our founders, Eric Costello. The three of them were sort of bullshitting about it and the joke was you could put a poop emoji on somebody’s message that you didn’t like. And there was sort of, I have a screenshot somewhere, they’re sort of riffing on this jokey idea, which of course rapidly became serious prototyping because it’s like, actually that would be awesome. And Eric, I recall, turned around the initial prototype in a day or so and it was the sort of seed of the idea. Like, what if you could react to a message with an emoji, and then you could sort of pile onto those, the way we all know now. The initial prototype essentially worked the way what we have now minus some nuance, and was so obviously good and interesting that we released it for everybody internally really quickly within that first day or two, and then quickly iterated to make it right. For example, we have emoji aliases. So plus one is thumbs up, that kind of stuff. And make sure to condense those down so you don’t get the proliferation of various variants on the reactions and stuff like that. So we ironed out those details pretty quickly. Yeah, it went from just an idea to a prototype to something that solved a real problem really quickly, because then those announcements posts, sure. Blast emoji reactions all over them and don’t fill up the chat with unnecessary things. And then of course, really quickly, I think even before we released it to customers, we started recognizing the traction that reactions have for actually moving work forward without having to talk about things. So for developers, the obvious check mark or a thumbs up on a PR review request, right? You don’t have to write anything and say, “Yeah, it looks good to me.” Obviously that’s over there in GitHub, you can just check it off. For a triage channel that a bunch of people are managing, you can start assigning reactions for the state of that item. Eyes that I’m looking on it, check mark that it’s done, red X like this isn’t a real request, or whatever it happens to be. We developed our own sort of system of reactions of white, blue and red circles for the severity of a triage request. And all of this kind of stuff just emerged spontaneously. I think a lot of people in the industry think that this stuff is all sort of imagined in this perfect product brief and there’s a slide deck and all the stuff that happens in sort of PM land. That was definitely not how we were operating at the time. It was an idea where all the pieces were sort of obvious and we just put them together, and then quickly iterated on what the actual UX and UI for that would be. And then people found their own uses for it super quickly. For jokes, for providing feedback, for polls. Where do you want to go for lunch? Sushi, pizza, burger, whatever it happens to be, and just add your choice. And so this seemingly simple fun little idea sort of grew into its own huge range of expression and actual work action that nobody set out to create in the beginning, but that emerged from how the feature worked. Yeah, that one, we got out pretty quickly thereafter after we started using it internally just because we saw how useful it was and how much fun it was. Especially when you combine that with Slack’s custom emoji, which we had from the very early days where people can create their own emojis. It just unleashed this incredible sort of reaction graffiti all over the place. In later years, it became sort of an interesting sub-problem of how to manage corporate communications at bigger companies because CEOs at big Fortune 500 companies don’t really like it when their employees blast negative emoji all over their announcements and messages, right? So that was a problem of our own creation that of course what the customer asked for is, “Turn off this feature.” And what we went back with was, “Here’s some ways to manage it and here’s some ways to minimize it”, so on. So yeah, no, it’s a fascinating sort of sub-thread of the Slack product story.

Allen: Something I love about that story is that this product gap that we talked about, which was there was a need eventually for threads, but the team kept the product as simple as you could as long as you could and tried to address it in other ways in the meantime. The Reacji it sounds like maybe might not have come about if threads had existed earlier, or maybe it would’ve taken longer for that idea to come together where everybody’s responding in a thread doing their little party popper emojis and things. Obviously hard to say how it would’ve built, but I love this idea or anytime I see this pattern where trying to keep the thing simple brings about interesting creative solutions rather than doing the heavyweight thing early.

Johnny: Yeah, I don’t think that had occurred to me before, but it may well be true. If we had had threads, perhaps we wouldn’t have landed on reactions in quite the same way. Hard to know. But I think your point is really that if you sort of embrace the constraints that you set for yourself, there are often creative and somewhat unexpected solutions to things. Whereas I think if you go in with this sort of galaxy brain idea of what you’re building and everything is all modeled out in your head, Stewart was very fond of reminding us in every kind of design review or product prototype review, none of us in the room is smart enough to imagine how people are going to use what we build. We might think we know, we might have a hunch, but when you talk about multiplayer network software, there’s just no way you’re going to anticipate how people are going to use things. And so the best thing to do is to build the smallest, simplest, most useful thing that you can imagine, especially if it’s something that you have high conviction about solving your own problems. Get it out there, see what happens, and then go on. Again, reactions is a great idea, a great example where the simple idea of emojis on messages was sort of the core of it. We got that out and everything that came afterward was just kind of wonderful deepening of it. I think it was, I don’t don’t know how much longer it was. A couple of years after that a group within the company had a Slack Day project, which was our internal sort of quarterly hack day type thing. And they noticed that on messages that had a bunch of different hand emoji with people who had selected different skin tones, so thumbs up from different people with different skin tones, those were all separated. And it created this unwanted sort of emphasis on the separation between people when they’re expressing their feedback, especially since reactions have counts beside each of them. And so they said, “That’s not the intention. That’s kind of just a weird byproduct of the emoji system and the skin tone system and reactions. Let’s fix that.” So they worked on unifying that so that somebody saying thumbs up means thumbs up. It doesn’t matter whether it’s a brown hand or a black hand or a yellow hand. That was just such a natural refinement of the idea that certainly we didn’t anticipate upfront. I think even when we created reactions, there weren’t the skin tone variants. I think that came slightly afterward, but that we were able to sort of revise in place and make it better and more humane and the number of people who responded to that positively was just awesome. And just a great example of how even though we had this simple system, we were able to refine over time with customer feedback and just make it better and better without trying to think that we had all the answers coming out of the gate.

Allen: Yeah, I love that mentality. And it sort of ties into a thread through all of this and through building Slack, what you’ve been writing and everything that I’ve learned about how Slack came to be, which is this mindset of really polishing something. And really thinking in a very user-centric way, raising the bar for user experience, all these themes. And it’s led me to think of Slack as an example of a startup that if you think about back to the origin of when you all started, the market that you were tackling was thought by many observers and people to be kind of played out. Like, “Oh yeah, team communication. There’s software that supports that and people kind of prefer email anyway, but there’s also HipChat and other stuff.” And what Slack did, and I love this strategy, is you came in and built something wonderful and incredibly successful by focusing intensely on raising the bar for what that could be and what the user experience and execution of that could be. And so I guess I have a two-part question. Part A is, is that how you think of it? Does it seem to you is that’s the strategy? Before I go to part B.

Johnny: Well, certainly raising the bar of customer experience quality and software quality was something that mattered kind of innately to the founding group, and to all the early folks that joined. I don’t think that was necessarily the strategy, it was just we didn’t know any other way to work. You know what I mean? We know that’s what we appreciated in tools and software that other companies made and we just couldn’t imagine doing otherwise. You point out that there were many alternative solutions, email being the most obvious, but many other sort of groupware and chat type solutions out there. I think Stewart made an inspired choice early on that we weren’t competing with any of them. It was not a better HipChat, and it was not real-time email or something like that. It was an entirely new thing. It was a better way of working. And that was always throughout his tenure his message. Slack offers a better way of working, and that in turn can enable organizational transformation and make us all better at our jobs and more productive and more happy at work. And I think starting from that basis rather than a craft orientation like quality software, performance software or something or from a competitive orientation of a better X, a better HipChat, opened the doors for I think a better go-to-market strategy and a more inspiring conversation to have with customers. And also a really inspiring kind of north star for all of us to follow. I can remember it was popular at the time on SaaS websites you would have your sort of competitive matrix. All the check marks are in your column. “Here’s why all the other tools are bad.” And we just always avoided that kind of thing. This is a new category and we own it, and I think that’s just such a great marketing position to be in for those early years. But probably more importantly, it set the frame for what we were doing in the sort of biggest, most opportunistic terms rather than worrying about features from another competitor or getting obsessed with some particular detail that maybe didn’t matter so much in the big picture.

Allen: Yeah, that makes a lot of sense to me from a marketing perspective. But it’s interesting, this mindset, and this kind of a little bit goes to the memo that you write about in Building Slack. This, “We don’t build saddles here”, memo from Stuart, which was I think in the lead up to the public launch, which I’ll link in the show notes for the podcast. But this mindset of instead of selling the thing that maybe people think we’re selling which is like, chat software, we’re selling this solution. We’re selling the experience of a better communication and being able to find the messages and all that. And I appreciate that framing and a bit of maybe a reframe rather than just thinking of it as, “Well, let’s just make a really high quality version of chat”, to, “Let’s make a better way to communicate.” Which maybe feels like a subtle distinction, but it’s not because you could totally imagine a team making a really, really, really polished thing that was kind of the same as what came before.

Johnny: Yeah. And it’s also hard to remember a decade ago, but having a job where you didn’t have to do email in 2013 was life-changing. Truly life-changing. I came from the academia and then I briefly worked at a larger software company where it’s all email, even things like PR reviews, which just seems completely inhumane now. And I came to Tiny Speck and there were no emails. Zero emails. Everything was on IRC at the time. And the impact that has on how you work, how you spend your time at work, how fast things can happen in a company, the record of decisions, the ability to keep track of things that are maybe a little bit farther away from your immediate purview, it can’t be overstated. And I think Stewart intuited and he would say that, “Slack or something like it is inevitable. We will not be using email the way we’ve been using it. It’s not what it was created for, and it’s a really inefficient way of keeping an organization running. There’s a better way, and we’re going to build it.” That is a fundamentally different proposition than, “We’re going to make a better piece of chat software.” I think the point you made about craft and quality, I mean, something we did really recognize and talked about was most… It’s still true, although it’s maybe a little less true now. Most enterprise software absolutely sucks. It’s just the worst. Every single one of us who’s ever filed an expense report in Concur or gone into a Microsoft, what’s their thing called? ShareDrive? SharePoint? SharePoint?

Allen: SharePoint, yeah.

Johnny: To try and get a file to share with your next boss or whatever, it’s just hell. That software is not built for people. It is built for enterprises. And it’s built for the people who pay for it and the people who administer it. And we fucking hated it. So we were not going to build a tool like that. We were going to build a tool for people. And if you work from the person who is at their desk trying to do their job, whatever that job happens to be, and then you work backwards to the system that could best support them in being able to communicate at work, you end up with something like Slack instead of something like SharePoint, just to get Microsoft again. And so that comes with a few considerations. I mean, it comes a deeply user-centered point of view in terms of how you make product design decisions and which features you emphasize and how you balance them. But it also led us to bringing consumer quality polish and UI design and visual language to an enterprise piece of software, which was very unusual at the time. And I think was one of the sort of dents that Slack made in the broader ecosystem. Look at something like Figma now. And that was everything from mobile apps that looked good and were fun to use, well-designed screens, as simple as that sounds. Forms that actually work instead of the forms that all that enterprise software always does, which seems to be trying to find a way to make sure you can’t submit it. And everything in between all the details that go into having a software experience that feels like it’s trying to serve the user rather than the person that owns the software. And it also led us to the kinds of consumer-y types of touches around things like emoji and reactions and theming, and all of the sort of delightful things that let people make it their own. And that people were familiar with from consumer messaging software like Messenger or any of the other apps that they were using on their phone at the time. And so I think that kind of stuff was a huge aspect of our early desirability for people because it felt like the tools they were used to using in their personal lives instead of the tools that they had sort of resigned themselves to using in their work lives.

Allen: Yeah, it was something people wanted to use. And I’m intensely interested in this as someone who comes at building software from a design and product and user experience lens rather than a “checking the enterprise check boxes” lens. But there’s all this momentum and I guess received wisdom that enterprises buy software by check boxes and by feature lists and by competitive analysis and not by, oh, this surprise and delight and the users that are actually using it. And in the end, this is how Concur, I’ve been going around talking to a lot of businesses about the software they have and asking them questions like, “Well, what are the biggest problems?” Or, “What are the experiences that you hate?” And people mentioned Concur and these other pieces of software that’s sold at the enterprise level. And so you have this strategy, and depending on how you want to frame it as a positioning thing versus a craft thing or whatever, but fundamentally, Slack is a great example of a team that has come into a space that you might from first principles think, oh, okay, well, the way you build that, a business that’s selling to these types of companies for this type of problem is to interview the CIO and ask them what check boxes they want, but instead thinking really deeply about how do we make a really great tool for these people. The thing that I’m always curious about and always thirsty to learn more about, this kind of people’s perspective, and obviously your perspective in this case, about the sort of repeatability and generalizability of that strategy. Like, how much in your mind, and of course we’re all speculating, but we’re going to maybe indulge some speculation. How much in your mind is that strategy applicable to just the exact moment that Slack happened to be in the right place, right time and luck that it was ready to be disrupted? Like, this change that Stuart saw at the right time? And how much do you imagine that there are just a whole bunch of disruptable tools, the Concurs or whatever they are, that there just hasn’t been a team that was really well-suited to coming at it from a first principles, “Make a better tool for the users.” And that each of those various things are going to get flipped at some point, and it’s kind of just waiting for the team rather than the moment that some external change in the way the industry is inevitably going to change comes at whenever it comes?

Johnny: Yeah, to get back to the first part of your question, we did go to market initially with sort of this bottoms-up strategy. And you got to remember that we didn’t have a labeled enterprise offering until 2017, 2018, at which point recognizing that those check boxes and those buyers actually did matter had to be part of the strategy, although we always did it in our own way. But for the first few years, we recognized that we could get in with teams and get in with companies from the bottom up in sort of a grassroots, word of mouth type of manner. A few people at Twitter start using it and they tell their friends and they tell the next department over, and suddenly we’ve got hundreds of people inside the company using it even though nobody top down ever decided, “Hey, we’re going to go buy this product.” And that happened at many large companies, especially in tech and media early on before we ever had any enterprise type of solution as they’re called. And so we went about it somewhat subversively I think, and I think it’s a model that I’m not sure if it’s generalizable per se, but it is a way for a smaller player to get a foot in the door, right? You don’t necessarily have to go get the CIO to buy something if everybody inside the company already wants to use it anyway. So I think that piece of it is something that probably bears thinking about as a business case. As for Slack and the overall strategy of how we sort of recognize this problem and market and developed a high quality solution for it, I don’t know. My instinct is that it’s not exactly generalizable. I think Stewart is a fairly unique CEO in his particular intuitions and philosophical perspective on some of these problems. So the biggest recommendation I can give to somebody in the industry or somebody getting into the industry is go find those people that are thinking about things differently and follow them. I think that’s a bit more durable than trying to solve all the problems yourself. Second, it’s been well documented that sort of the ZIRP era dating from the economic, or sorry, financial crisis in 2008 through till COVID essentially, is the longest bull run in market history and people were spending a ton of money on software, and it was much easier than now to raise money for these kinds of ventures. We were given just an incredible opportunity and the timing was right, and we had the right leader with the right idea sort of at the right time. So I think all of those things are very difficult to recreate, but I do think that people want better tools and people are willing to pay for better tools. And sometimes that can be on a sort of ROI basis, which is getting back more into how maybe CIOs think about this stuff, but it can also be on a user experience basis and a sort of productivity basis. So, I mean, Figma is a good, well-documented example of this. Seven or eight years ago, you either used the Adobe Suite or maybe you used Sketch. But Figma came along and said, “Well, we’re just way better than the Adobe Suite for these reasons. We’re multiplayer-first, so why would you even use Sketch or Envision?” And the product was just so much better that they have taken over the market. And Adobe tried to buy them for a billion dollars or billions of dollars. So they’re a good example that they have their entire own story that I don’t know that much about, but purely that they came after Slack and had some of the same characteristics I think of a great product moving in and taking over sort of an incumbent market so disruptively, I think shows that there is some degree of repeatability to the Slack story. I think Browser Company is a good example of this today. I should note I’m an investor in them, but I’m an investor because I believe these things, not because I want to pump it up. As I said, people want better tools. And they released their Windows browser yesterday, and they had their biggest signup day in history and they have now millions of people using this novel browser, where for the last 10 years, everybody on the planet was basically using one of three browsers from the three biggest companies in tech. So they’re another example where they came along and said, “From first principles, what’s the best user experience here? What’s the best product we can build?” They got that into people’s hands and now people are demanding it, and I think that is a playbook that is repeatable, that doesn’t necessarily require you to follow existing well-trod ideas about how you sell software to people.

Allen: Yeah, and that I think that pulls in, crystallizes something that’s maybe obvious but that sometimes people will forget is that the applicability of these sort of user-centric, UX-centric, that kind of go-to-market is amplified proportionate to what degree the users themselves are choosing the tool. Which may be obvious, but I chose to use Arc. You chose to use Arc, right? We’ve made that choice and a CIO did not have a say in it. And also our team here chose to use Figma, and our team here, individuals chose to use Slack. And so maybe a takeaway for that is if you want to start a product where you can really dig deep on thinking just focusing on the users, which obviously we’re always focusing on users, but go to the extreme of really just saying, “Let’s go from grassroots up”, then something that people are capable of choosing instead of, it’s very difficult for an individual to say, “You know what? Instead of using Concur, I’m going to choose my own expense reporting tool.”

Johnny: Yeah, for sure. There’s some things, especially stuff that have a lot of compliance around them where this could be a lot harder, no doubt. Or maybe not possible. Yeah, I mean it brings up an interesting thing. Like if you are in a company and in an environment where you have a degree of latitude around what you install on your computer, what you install on your phone and what you’re able to use, which typically means smaller companies, this isn’t always possible at big companies where there’s a lot more lockdown on that kind of stuff, then there is an opening there. People chose to come to Slack.com and download the app and then invite their colleagues, and we didn’t do any sort of outreach at that point, right? It was all sort of inbound curiosity. It does create this possibility for change that I think is a lot more available to startups than other types of go-to-market strategy.

Allen: I have 999 other questions I’d love to ask, but I’m aware of time. I have more curiosity than one podcast episode can fit. But I wanted to ask, zooming out a little or maybe give you an opportunity, there’s obviously a lot that you’ve learned building Slack and working for it with all these amazing people. Is there any sort of big lesson that you learned? Especially to the part of the business that we haven’t talked about too much which is like, as the scaling out has happened. Or in the early days, but it seems I assume that probably more of the surprises, more of the lessons, whereas you got from this core team of 10 to the bigger and bigger scale. Any lessons that you learned, either hard-won ones or just really valuable ones, that you think other founders and builders could maybe find helpful?

Johnny: Yeah, for sure. I think we’ve talked a lot about the company as a whole or the product as a thing. I think, I don’t pretend to big organizational lessons, but I certainly have my own lived experience of it. And I think the lessons that I’ve taken away were sort of from that direct experience of working within a fast-growing successful tech company. The reason Ali and I are writing Building Slack is because we want to share that picture from inside of this crazy run that Slack had. I think often tech stories are told in very broad strokes about the good guys and bad guys, and the winners and losers, and charismatic founders and CEOs, and that’s all part of it. There’s also the thousands and hundreds of thousands of people who work within these companies trying to make choices in complicated and uncertain environments and trying to make the right business decisions along the way. And those are ultimately the stories that we want to tell. I mean, right now we’re kind of giving that origin story an arc toward our initial release and sort of early hyper growth. We do want to also tell some of those other stories from the perspective of individuals within the company at different points of it. I think I was super lucky to be able to see it grow from the very beginning, and so I have sort of a unique perspective. Looking back on the 11 years that I spent there, there were times when I felt somewhat uncertain or some degree of imposter syndrome about where I found myself. Going from just a guy working on web stuff to suddenly being responsible for bigger teams and bigger very mission-critical type systems or projects. And when I was uncertain, it’s very easy to fill your time with low-value work that feels like work but isn’t actually moving things forward, and you sort of float around like a cork in the ocean. Especially when we were growing, we were doubling in head count every year and you spend a ton of time hiring and you’re just trying to keep your head above water. And when I look back, those are the times that I felt like the least effective or like I didn’t really understand what I was bringing to the table. And I think over time where I learned that my niche was, and that I think other people can maybe learn from, is that if you can identify and elevate the biggest opportunities and risks and focus on them and then you can bring in a work ethic to actually do something about them, then you’re going to provide so much from the front leadership. Not the executive leadership, but the kind of captain-level leadership, to actually provide value and make things better within the company and make things better in the product. And I think the sort of highlights of my time there were where I was able to help identify and recognize and sort of target those things, whether it was an opportunity like a feature or a technology migration that needed to happen or something like that, and really lead those. That’s where I felt the most sort of professional pride and empowerment to really lead, and where I think as an individual contributor you can have the greatest impact on how a fast-growing company actually succeeds or doesn’t. I think a lot of people get into tech because they’re excited about the products or they have a love of programming or great taste and skill in design, and those things or some combination of them will take you really far toward a satisfying career. But I think stepping beyond that and being able to zero in on and actually prioritize the things that your team needs to do to make the most consequential impact, I think that’s actually pretty rare. And like I said, takes sort of a strong work ethic and a constant kind of like, “Zoom in, zoom out.” Like, “What problem are we actually solving?” And trying to see it from the whole perspective. I see so many teams get sort of boxed into their little piece of the puzzle or their part of the spreadsheet or whatever, and often end up building the wrong thing or taking too long or wasting effort on something that won’t matter if we get this other part right or wrong. And so I guess my most hard-won lesson is if you find yourself in that kind of treading water mode, zoom out, see where the actual problems are and build the relationships so that you’ll actually be able to influence those things. And then put all your effort, put your shoulder to those hardest problems instead of, like I said, floating around. And recognize that you don’t necessarily have to be a manager or an executive or a director or whatever to make those changes. I think it’s misunderstood how big of an impact ICs with this kind of mentality can actually make within tech companies.

Allen: I love it. That’s a story I hear often in large organizations of the big successes have individuals, not just, “Okay, Stewart said so”, but individuals actually making it happen. So I love that. Thank you so much, Johnny, for your time and your stories. Where can people go to learn more about you and your work?

Johnny: Yeah, I would love for you to check out the newsletter that Ali Rayl and I are writing at BuildingSlack.com. It’s a newsletter and a website, so you can either check it out there or have it come to your inbox. We’re publishing sometimes a couple of times a week, other times, a couple of times a month, so it’s relatively infrequent. It’s always from the heart, it’s not AI generated, and we’ll continue writing it until we feel like we’ve told the story that we want to. And other than that, you can find me at my website at johnnyrodgers.is.

Allen: Awesome. Well, thank you so much for being on the show. It Shipped That Way is brought to you by Steamclock software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steamclock. That’s it for today. You can give us feedback, follow us social media, or rate the show by going to itshipped.fm/contact. Until next time, keep shipping.