Speaker 1: 0:23

Hello everyone, welcome to another episode of OpsCast brought to you by MarketingOpscom, powered by the MoPros out there. I'm your host, michael Hartman, joined today by my co-host, naomi Liu. Mike Rizzo is off at Inbound 2024 up in Boston. So, naomi, how are things up there? Where are you again? Somewhere in Canada?

Speaker 2: 0:44

Vancouver, vancouver.

Speaker 1: 0:45

Sunny Vancouver. I can't keep up with you these days. You're all over the place. I'm here, okay, good For this week. For this week, well. And this is a new situation for us, because Naomi actually has someone sitting with her. Our guest today, joining us today is Johnny Rogers. So Johnny was one of the original employees at what became Slack. During his time at Slack, from the beginning until post-acquisition, johnny wore several different hats. Earlier this year he and some other former early employees from Slack started sharing some of the stories about the early days and beyond of Slack and we thought it would be interesting to share with our audience. You can read and subscribe to those for notifications as posts go live. It's under the domain buildingslackcom and we'll share that in our show notes as well. Johnny, thanks for joining us today in your cozy little space there.

Speaker 3: 1:42

Thanks so much for having me, Michael. Thanks, David.

Speaker 2: 1:44

Yeah, no problem, michael and Johnny, I have to say that I'm super excited that johnny's on the podcast today. In the back of my mind, and he's someone that I wanted to bring on the show for a while, and I'm just glad that not only could he be on here today, but actually sitting next to me recording.

Speaker 1: 1:58

So yeah, I think I was saying, I think this is a first right. We actually have a guest in the room with one of us.

Speaker 3: 2:07

Well, despite, you know, going through COVID and having to do remote work like everybody else, I never made the jump to a good audio setup at home, so it's probably just as well I'm here with Naomi's professional microphone.

Speaker 1: 2:20

Well, you would be surprised at some of the scenarios we've had with guests. I think we had someone who was like in one of those like phone booth type setups in an office sharing place with no mic, no headphones, and it still worked out. So I think we'll be okay, no matter what. All right, well, I gave the two-second version of your career path, particularly just the Slack component of it, so I know it's not complete. Maybe if you could just do a quick overview of your career path and how you ended up at Slack and then we'll kind of pick up from there.

Speaker 3: 3:00

Yeah for sure it's funny. I was just chatting with a friend of mine yesterday how we were the lucky few who got the internet at home when we were, you know, young enough to have lots of time to spend kicking around on the internet mid nineties. Um. So yeah, when I was 12, we got a computer at home and it's connected to the internet and had a little bit of software and I spent a lot of time just kind of like messing around and I spent the last you know 25 years of my career pretty much doing the same, but the last 25 years of my career pretty much doing the same. So when I finished university, I started a web development studio just building sites for people.

Speaker 3: 3:41

This was around just after the dot-com boom and bust and I was kind of just a generalist doing a little of everything a bit of design, a bit of programming, figuring out how to deal with clients and did that for about seven or eight years, eventually went back to grad school, did my master's here at SFU and after grad school finished it was the end of the financial crisis and recession and jobs were scarce.

Speaker 3: 4:04

So I was looking around for jobs in software here in the city and my wife who's the primary teacher. She actually had been using this game Glitch in her classroom and she said this is made right here in Vancouver and it's the guys who used to make Flickr. And I had been a Flickr user. So I applied. I actually sort of cold called Stuart, went for coffee with them and my skill set was just kind of general web dev and a bit of design programming and they were looking for somebody to help out and so I joined TinySpec, as it was called then when they were working on the game Glitch, and I came in toward the latter end of that. I only worked on the game for about eight months before we eventually shut it down and pivoted to Slack.

Speaker 1: 4:49

Yeah, it's so interesting, it's funny. You mentioned two things that I almost at least I tried to forget about them, I guess which is the dot-com bubble and burst and the financial crisis in the early aughts, because those were like right in the middle of my career. So that's not fun. So, thanks for that. Appreciate it, johnny. You know opening old wounds, no, so, you know, when Naomi mentioned you as someone she knew and as a potential guest, it wasn't around that time, I think I happened to. I also listened to a lot of podcasts in addition to this. I heard a little bit of the origin story about Slack from the how I built this podcast, and so I don't remember all the details. But you mentioned right it started as a gaming company, so, like, was there anything else about that? I mean, it sounds like it was an opportunistic kind of thing as well, but what other things attracted you to the company? Was it that the Flickr former Flickr founders were part of it, or was there more to it?

Speaker 3: 5:58

Yeah, you know, there's actually kind of a few threads came together that really pushed me in the direction of wanting to work for the company, of wanting to work for the company. Like I said, I had used Flickr and loved what the team had done, you know, bringing photo sharing to the web and kind of this mix of like a sense of humor and, I don't know, I would say, like love that they brought to that. You know, it was just a very different time on the internet and it was so much fun being on Flickr with people commenting and leaving notes on photos and I don't know. It seemed like this very genuinely, um, delightful community that I really enjoyed. And it was also at the time, if you wanted to have a blog with photos on it, you posted them on Flickr. Um, you know, bloggercom would say go go, createa Flickr account and upload them there and then paste the links over here. Um, and so that's how I became a Flickr account and upload them there and then paste the links over here, and so that's how I became a Flickr user, because I was a blogger at the time, just like travel blog stuff. So I've had a lot of positive impressions of the company and the people behind it from what they had done with Flickr.

Speaker 3: 7:02

Beyond that, I had lived in New Zealand for a little while and had briefly met who became our CTO, cal Henderson, one of the founders there when he was giving a talk at WebStock, a great New Zealand web conference.

Speaker 3: 7:17

And then, finally, eric Costello was one of the 34 co-founders of Slack. Co-founders of Slack he had posted a lot of stuff online early about building websites HTML and CSS and JavaScript, you know, tutorials basically and he had always shared it sort of out of the goodness of his heart and his own kind of like passion and curiosity about the subject. Like he was never charging for that content or anything. That's kind of a different time again, and I can remember learning techniques for how to use css for different layouts from his website, and so, yeah, when I found out that it was that group of people um, here in vancouver, it just seemed obvious to me like I don't care what they're really working on, I want to work with those people, um, and in the end that ended up being, you know, sort of the key to the success, like I wasn't a gamer and, like I said, I didn't get to work on Glitch for very long, but working with active people turned out to be a really durable way to solve interesting software problems and build a business together.

Speaker 2: 8:21

I've been reading, I read some of the stuff that you posted on building Slack and when I actually jotted down a couple of notes, because one of Slack's evergreen goals you'd mentioned is software for work that people can love, and that's just something that, like I, it resonates with me because you know someone who is a lover of technology and the tools that I use in my day job.

Speaker 2: 8:43

You know there's obviously tools that I cannot stand and there's tools that I just love to use and it's just one of those things like it's so nice to utilize tools and software in your day to day, that where that premise is that backbone of that, right, and it's just, it's just nice, right, because you know you had also written something about you'll know it's working when you don't have to use email at work anymore and it's while obviously we still use email, it's just a different way of doing our jobs that allows us to communicate and stay connected and keep organized with all of the million other things that we're doing every day. And I just, I don't know. I just really appreciate that sentiment when it comes to building those tools for people like us.

Speaker 3: 9:27

Yeah, really, we always built the tool that we wanted and I think that ensured that we were building something that we love and that fit really well for the jobs we were trying to do.

Speaker 3: 9:40

We weren't trying to build for some imaginary person or team or customer out there, we were building for ourselves and thinking about how it might be useful in lots of different industries and so that kind of idea of like work software that people actually love.

Speaker 3: 9:57

We were very lucky to sort of hit court with folks and help them off of sort of the email hell of the time. I can remember Stuart early on when he was pitching it, like you know, we were using a tool like Slack internally that we had cobbled together and that was my first time being out of the job that did not email and it was great but it was still very rough. But he could really see where things were going and he would say to us Slack or something like it is inevitable. And I think now, 2024, 10, 12 years on, it's hard to imagine working without this kind of tool. And in the time since I left the company I've been doing some volunteering and working with some other groups and everybody has Slack, no matter what they're doing, and it's pretty amazing to see all the different nooks and crannies that it's found its way into since then.

Speaker 2: 10:50

I think one of the reasons that that kind of comment like really resonated with me software for works that people can love is because, you know, we as marketers we often are designing programs and building workflows and coming up with nurture programs for this group of unknown people in our minds, not realizing that and thinking like, hey, actually we are the target audience. How would we receive these types of campaigns? Do we want to be nurtured to? Every Monday at 12 pm, you know, with a hey, you know, sorry, I missed you type of email Like. I think it's easy to forget that we are our own consumers as well and that's just something that is an important reminder.

Speaker 3: 11:31

Yeah, it's cool because I think it's kind of two ways to think about it.

Speaker 3: 11:33

One is like the Silicon Valley startup advice, which is like scratch your own itch right, if you have a problem and you can solve it with a product and you can make it as good as you know how to make it solve that problem, good chance somebody else is going to have the same or similar problem. They're going to be interested in it. The flip side is like I don't know, it's like the golden rule treat your customers the way you'd like to be treated. And you know we've all used shitty software and we've all felt the funnel of like a growth team sled deck pushing emails and notifications at us to try and get us to do something. And you know we have. We always try to avoid that and we always try to address our customers as people and, thinking through you know how we could best make something that would help them solve their own problems rather than, you know, buy our product, I guess, which is tricky and it takes a lot of effort and decision-making at every step and over a long period of time.

Speaker 1: 13:31

Naomi, you hit on something that I think I've as a as a as a kind of a leader in marketing ops, and one of the roles I think we should all play is to be advocates for our customers, Right, and I think sometimes your ideas are thrown out of things we could do right To. You know, you both have sort of painted a little bit of a picture of what that might look like in. Our job should be to go like yeah, is this really what our customers want? Right, so I've nurtured a great example, Like I've sort of sour. I don't know that we don't necessarily need to do it, but I do not believe there's anybody out there who's going oh, I got this email from company X. I cannot wait till I get the next one, Right, Whether it's a day or a week or a couple of weeks, Like I. I just I don't know anybody who's doing that, Right, Everyone's busy.

Speaker 2: 14:19

Yeah, when I get an email from a rep, I try to figure out is this a nurture right or are they actually sending me a one-to-one email?

Speaker 1: 14:24

yeah, well, it's funny because, like I I don't know about you, naomi like I, almost never unsubscribed to anything because, part of that, I'm trying to see what are these companies doing. Yeah, I want to see what they're doing and see if there's a yeah, any commonality. And so, by the way, that's to our audience who might be in sales or something, that's not an invitation to start pushing emails to me, just like um, I do unsubscribe occasionally, but in general I try not to um, just because I think it's valuable to see. But I think that's that's really a good. You know, johnny made the point like I mean, we wanted the golden rule. I love that's, that's a great way of putting saying it. I mean, like we should treat our customers the way that we'd want to be treated. Do?

Speaker 3: 15:04

you? You want an email from an AI written out of the script to sell you some shit? No, definitely not. Do you want somebody to talk to you about your problems and try to help you solve them?

Speaker 1: 15:15

Yeah, I mean literally the last two days. We got a household product, you know kitchen appliance kind of thing, and it broke down. It was still under warranty. Contacting the company is lovely. They sent out a replacement. It didn't come with a return shipping label, so they got FedEx to send it to me. But dealing with trying to coordinate with FedEx has actually been a big problem. And this is not a knock against FedEx, I don't really have a thing about that. But it's like an example of like I actually just wanted to talk to somebody and I couldn't talk to somebody and it made it hard to do that. And I know they're all trying to manage costs. I understand why. But it's like if they put themselves in the customer's shoes, your mindset right. They're frustrated, they want help, like make it easy for them.

Speaker 3: 16:08

This is something that was essential, I think, to the DNA of the company and to the success of the company. So call it customer love or whatever, but from the get-go, from the top, you know, from Stuart, our CEO, and from Allie Rail, who I'm writing and building Slack with and who was our head of customer experience, and eventually we deal the same and then eventually, our CEO the sort of bottom line was like is this good for the people using the product and are we doing right by them? And if you contact Slack for support in 2013, when we were in our alpha and beta, or today, when millions of people are using it, it's an actual person at the other end of the line who reads your email, understands what's going on and will reply as a human. Now, of course, there's some scaling, like if there's a widespread issue, you might get a macro type response. But the core of people who work at Slack and have worked at Slack over the last decade hundreds of folks in customer support who take their job super seriously and are so empathetic and supportive of our customers and the way we talked about people who use their product internally was always with, I guess, a respect and sort of reverence for their time, and so we always kept that as like a sort of fundamental value of the company.

Speaker 3: 17:37

And when it comes to like how you're spending the dollars you have to allocate within a company, you know, having a bunch of humans full-time round the globe, round the clock, answering customer support tickets and doing so very quickly, that costs a lot, me.

Speaker 3: 17:45

You know, having a bunch of humans full-time round the globe, round the clock, answering customer support tickets and doing so very quickly, that costs a lot. It costs a lot more than not doing it, that's for sure, and it costs more than having a robot do it or understaffing that group of people, and, I think, even more than that. This is where Allie could speak to her experience. But you know she had a seat at the executive table from the get-go to represent the voice of the customer. It wasn't just another department you know like, oh, we've got engineering, we've got design, we've got customer support over here or we've got it overseas, or something like that. It was a core part of the business and the needs of that group and the voice of the customer was represented at the top level in the CTO staff. And I don't know if that's typical, I think from what I've seen from other companies and what I've experienced as a customer of other companies, it sure doesn't seem typical Try and email, google with the problem.

Speaker 1: 18:43

Yeah, it's interesting because what immediately goes to my head, because I'm in dallas, is southwest airlines and I don't know I don't know if this is still true at southwest airlines, but when it started right, one of the things that herb kelleher did was he made sure that people were empowered at the front line to delight customers right, whether that was on the plane, at the check-in, at you know all that stuff.

Speaker 1: 19:05

So they, they had the freedom to do what they thought was right to solve a problem. I don't think that ever meant, like you know, doing something that they didn't think was right just because the customer said it right. So that, yeah, just like customers always right is, you know, not what they believe, but they did want to have a delightful experience and it's a big part of, in my mind with how they grew so fast, so quickly, right. So, yes, there's a cost to that. At the same time, I think there's what's hard is that there's not, there's not always that easily quantifiable return in the short run. That's right, it's seen as a cost center in the short term.

Speaker 3: 19:43

Um, but yeah, we all have examples of companies that we feel trust for and we feel are actually taking care of us when we deal with them, that have gone out of their way to make this a priority, and it does add up in the long run. I should have just said before what I really like and, as an example of this, slack took off really quickly in the first few years and grew beyond what we had anticipated. An example of this you know Slack took off really quickly in the first few years and grew beyond what we had anticipated as being probably a good tool for people in tech and media, and then it grew outside of those industries and many, many others. And as the companies using Slack got bigger, you know, from hundreds of thousands, tens of thousands of people. You know there's an overhead to that kind of communication at large organizations and one of the primary pieces of feedback during those first couple years was we need threaded conversations. We need to be able to reply to messages. We can't just have a single layer in channels, which is what we had at the time. So for those who use Slack at the time, you know conversation in a channel would get really busy and you wanted to respond to Michael's message, but since then Naomi and Dave have been having a different conversation. So how do you sort of segment that?

Speaker 3: 20:50

And people were desperate for a better way to do that and we eventually released threads. And the reason I bring it up is because after we released threads, after a couple of years of thousands of people sharing their feedback about the need for this, our customer support team went back and replied to every single one of those people, even if it was from like two years prior. You know old tweets, old Zendesk tickets, and they went through and they said we heard you, we listened. It took us a while, but we think we've got it right. You know it's out now. Please let us know if you think we still want to make it better. And people were so, I guess, surprised by that that we kept track and actually followed up with them, but then delighted and engaged to actually make it better.

Speaker 3: 21:35

So it took something that was a hugely disruptive change to the product, that was not without its growing pains and bumps, and, instead of having customers angry that it was wrong or that it changed things, it gave us an opportunity to keep having a conversation with them and say this is what we think is best. Here's where we're going with it. What do you think? And the million ways that they came back to us with feedback and ideas made the product better and it deepened that kind of trust and sort of mutual appreciation for one another and just trying to make the best thing. That we knew how. And I think you know that's one example. There were many others over the years and I think it's, like I said, essential to what the company was and for why people talked about this piece of software and wanted to use this piece of software and took it to other places their next workplace or whatever. In a way that's not true with a lot of software that you use at work which you're often happy to see the backup.

Speaker 2: 22:30

I think one of my takeaways from that is that, you know, in our line of work, something that can be a challenge and super important is technology adoption, finding internal advocates and how do we get our stakeholders and business partners on board with some of the changes that we want to bring a company through right, Some of the digital transformations that we are trying to enact within an organization. And just kind of hearing some of your anecdotes about how you treated customers and how you listened to their pain points and then took action to find solutions for that is something that I think a lot of our listeners can have a takeaway from right. And just listening to the people that we're supporting and what are the things that are keeping them up at night, how do we help them meet their business goals, their revenue goals, and what are the tools or education gaps that we can, as marketing ops folks, help to fill.

Speaker 1: 23:29

Yeah, I agree, we can, as marketing ops folks, help to fill. Yeah, I agree, I think I had the same basic sentiment, naomi, or free thought process is that I think it's easy for folks in marketing ops to get sort of defensive when they get feedback that is negative about something they've done right or solution they come up with. And my, my view all along is as long as it doesn't get personal, it's like, take all that in right, I want that feedback, I want as much of that as I want it doesn't mean you have to go do everything, but the more you do that, the more you listen, I think, the more likely you are to be able to support the team broadly. You'll help with prioritization, all those kinds of things. So I think that would be my takeaway is be open to getting that feedback, whether it's positive or not.

Speaker 3: 24:13

Yeah, and we would always foster that. We were really active on Twitter at the time, similarly, sort of replying to every message, and people would have all sorts of ideas. Like you said, it's not like we were going to just go and implement whatever people asked for, but we would hear every day about little paper cuts that people were having with the product. And the fact that we actually listened and would fix those and turn around and say, hey, it's fixed, it's better now, meant that, A we would get more feedback from that same person again because they knew we were listening, and B, it would make it better for everybody else who had that same feedback but hadn't heard it right.

Speaker 3: 24:51

And so there's the big hard problems that you're trying to solve that take months or years and you're not just going to be able to get around in a day. But there's also tons of little low-hanging fruit that you can address pretty quickly at pretty low cost and actually adds up to a dramatically better product experience and a much happier group of customers. I'm not involved in, you know, wrong-lifes software organizations, the way you guys are talking about, but it seems like the same kind of thing can be true. You know, see what's causing trouble for people and what's turning them off and what you're trying to achieve together and bring them in almost more as like a part of it than as like see, I know if mike was here he'd be going like see, here's.

Speaker 1: 25:35

Here's my point about saying that marketing ops should be like product management. So, um, all right. So I'm curious. It's funny that you didn't have any. Like you're not a gamer, or you weren't at the time, right, but you end up at a gaming company. But what? Um, I heard a little bit about again from that that you built a, built something internally that you needed as a team while you're working on. Was it glitch? Is that the name that was at the? Yeah, so what? Like, like, how did that even start? Like, what was the? Was it because you were all tired of email threads and like you didn't want to use a wiki?

Speaker 3: 26:11

I think wikis were around then, maybe um, so this predates me, um, but you know, I experienced it when I joined the company. They had the founders and early employees at glitch. They had sort of cobbled together IRC, which is a long-lived internet relay chat which kind of looks like Slack if you squint at it, but it was sort of a simpler earlier chat protocol from the web. The biggest downfalls of it was that you only got the messages if you were online, so there's no archive to scroll back to if you weren't connected.

Speaker 3: 26:47

It didn't have native file sharing. It didn't have search capability. It had, you know, pretty basic profiles like to handle. So it was like amazing chat from the 90s and they had taken that for you know, real-time communication with the team and then they had added all those missing bits and the additions were very clunky. Search was a web page you could go to which essentially just formulated a SQL query and pulled stuff out of the database. For you, file sharing was just an FTP file server that would post links into the chat and click through to the archive, which is done by stuffing, you know, stepping stuff into a database.

Speaker 2: 27:29

I haven't heard that for a while. Ftp.

Speaker 1: 27:31

Uh-huh oh.

Speaker 2: 27:35

Some people, anyone on the call is googling what FTP is, or really throw them off.

Speaker 1: 27:41

SFTP, right yeah.

Speaker 3: 27:44

Yeah, I thought that was pretty good, just the way that I put files on that. This is before we talked about the content. Oh my God.

Speaker 1: 27:52

Yeah.

Speaker 3: 27:54

Anyway, you know they had taken IRC and they plugged in the bits that made it more useful and everything happened there. When I joined Glitch I got an email address but it was like I I don't know. I think I maybe got expense report receipts there and that's about it, but they again would be in slack. But we never used email for something in vacation. It was all on IRC. And the other thing that was lousy about IRC at the time was like the mobile clients were were pretty terrible for it. So the idea was there to have all your communication in one place and be able to search over this archive. That would, you know, add value over time, because a new person wouldn't be starting from scratch in an empty inbox. They would have all this stuff to look back into. Um, which was definitely true when I was, you know, sort of getting my hands on the job, but it was was pretty clunky for sure, and it was not the focus of the team at all. Nobody was responsible for it. It was just like some engineers adding stuff as we needed it If something got too frustrating, and Stuart has talked about how it was kind of the best way to sort of accidentally make the great use of software is to spend as little time on it as possible and only fix something when it's done and created, because everybody's trying to make a great game and make the game a success.

Speaker 3: 29:12

So you know he has spoken about this in print and on podcasts before. But when he and the other founders realized that the game just was not going to be penable economically, you know it was creatively very successful and the people who played it absolutely loved it. It's kind of like an animal crossing type of casual social gaming. It's really fun, really sweet. But when they realized that, you know it's just going to cost too much to make for the number of people who are going to pay to play it.

Speaker 3: 29:43

You know, luke's a creative guy and I think he kicked around a handful of ideas, one of which was you know, I think this thing that we built for our own internal use could actually be a real product. And that's what he eventually pitched to our company's season board and said we can keep going with the game, but we're going to crash in them and we're going to run out of runway. So why don't we take the money that we've got left and make this product? And he fixed it as potentially a $100 million business and grew to much, much beyond that eventually.

Speaker 3: 30:21

But it was this ambitious idea and this was at a time when companies were really running on email and things like HipChat and Campfire were used in some dev and tech teams but hadn't sort of like penetrated broadly beyond that. So, yeah, he anticipated that, as I said, slack or something like that was going to be inevitable, because email just was not suitable to how we were using it really and I wanted to build a product around it.

Speaker 1: 30:52

So, like I know, there are people out there, I'm married to one who gets frustrated by Slack because it's just yet another challenge, because email has not gone away, nor has text messages. There's all these different ways of communicating at the organization, um, and I've seen that myself too. Right that you know picking which one you use at the time. You know when you, when you guys were rolling it out with you know, maybe initially or over time, right, did you start to find best? I hate to use the term best practices, but things like setting. Are there certain things you should do if you want to adopt Slack as it relates to like? Being very deliberate about this is when we use Slack, this is when we use email, this is when we use text message or whatever other channels.

Speaker 3: 31:44

It was something we spent a lot of time on and I think on the the one hand we got really lucky because a lot of teams who were really truly early adopters in that first year or two were a lot like us, were software teams or media teams where the real-time nature plus async just kind of made sense to them and they're really comfortable in the tool and so having them move everything over was relatively pain-free. As we started to expand outside of those teams and, like you know, the newsroom or the tech edge team or something like that, into other roles and other industries that had more overhead for things like father naming and compliance and on the record communications or didn't sort of embrace the kind of sync, async fluidity of organizational communication, then we had to start telling a bit of a different story about it and giving different kinds of techniques. So we would ask people in the early days try and move your whole team over to it for a week. No email, no, nothing else for a week. And if it's still working for you on Friday, you should keep doing that. And if it was just one more thing in the mix, it died. It would just be kind of like well, I'm here but the accounting team's not here and I can't ask this person a question, and it just became one more place and would sort of die on the vine at those teams, whereas those who came over and went all in, even for a relatively short period of time, they stuck. And those are the ones that we saw sort of just grow and grow and grow in seat count, which was how we charged for the product over time.

Speaker 3: 33:29

We would also give tips about, as you say, being deliberate about how to use it. Um, so when you start a new team or workspace as a call now, um, you end up with two channels general and random, and even that is like it's pretty vague about what you're supposed to do. Um, you know, general is for a little bit of everything, and random you know sort of recognizing that people bullshit a lot at work was for joking around. You know sharing links and posting. You know gifts and stuff now, um, but that didn't give you much structure, right, and we had to teach people. Okay, a channel is a good bucket for a topic, and that topic might be a project that you're working on or a client that you have a relationship with, or a department in your company on, or a client that you have a relationship with, or a department in your company like accounting, as an example, or an event like next month's offsite or something like that. And when we started to show examples of that kind of thing to people and show how channels kind of have their own life cycle, that's when it would click for people.

Speaker 3: 34:31

And what we also found, which I think, is I think there's some you know clever name for this, but it's the same thing on wikipedia. Most of us never contribute to wikipedia but we all get benefit from it, right. But there's this small percentage of it's like sub one percent, right of people who spend a lot of time editing it and making it good for everybody else and applying norms and stuff. And we found the same thing happened with slack. There's some people who take it upon themselves, either because of their role like they're a you know, a chief of staff or a project manager or something like that or just because of their natural affinity for organization and helping people communicate. Would take on the job of making sure that channels you know had a good name were not duplicates of others, would encourage people to have public conversations and public channels instead of you know, often people would kind of conversations and public channels instead of, you know, often people would kind of get a little scared of defaults and DMs or private channels. So all these kinds of like good, good practices or best practices, as you said, would sort of percolate that from these folks and we tried to provide resources and like coaching to those people, the videos via, like you know, pdfs.

Speaker 3: 35:35

Honestly, at the time it's like here you're going to throw that back, here's like five things to track. And then the biggest thing I think that worked was, you know, giving demos to customers and saying, like this is how we've got things organized. And you can immediately sort of see the light bulb in their head, go on and say, oh well, I can create a channel for my department or my project or whatever, and understand, oh well, I could create a channel for my department or my project or whatever. Uh, and understand that if you start doing that and start putting the right content in the right channels, it sort of self-organizes in a way that is pretty legible to the next person that you add to slack. So there's some things that we worked on over the first couple years.

Speaker 3: 36:07

That said, it's like far from a solved problem. Um, you know you said your wife's frustrated with slack as one more thing to check. I see that all the time. Um, I joined the slack last year for the local environmental group and you know there's some people who are on it all day because I think they also use it at work and it's very easy for them to flip over and check out what we're talking about. And there's folks for whom it's like oh, I got to remember to check slack like once a week, which is definitely not how we decided to be used, and so that is tricky. And you know I do feel the pain of folks for whom it's one more channel, and was that a WhatsApp message or an email, or was it on the forum or was it on Slack? And you know we didn't solve that problem.

Speaker 1: 36:49

I would say Now, naomi, I don't know about you, but like my thought there again, like lesson learned, right, those getting when you talk about adoption of technology, or most of our listeners would be dealing with right getting getting one or two people who will be the the early adopters and advocates for it seems to be a really important piece of this. Like, do you see that too, really?

Speaker 2: 37:16

yeah, especially when you're dealing with groups of people where there may be differing, uh, levels of technical aptitude, right, and I think that you know, if you don't want to spend your entire day, week, month, quarter, um, just trying to enable users and kind of defaulting to a bit of like a help desk IT situation, finding internal advocates and those who have a higher technical aptitude who can help their teams and also kind of be that resource and help them help others too, I think is super important, especially in larger organizations, because otherwise it just you end up being kind of a ticket desk for the same questions over and over or having like really good documentation.

Speaker 2: 38:00

We use Vidyard internally to create, you know, self-help videos that I've done over the years to answer questions that I know I will often get, especially for folks who are onboarding or new to an organization, and I've always found that that should be super helpful as well. But technology adoption is always going to be something I think that you know. If you're not in the tool and even for myself, right, there's certain tools that we have that I'm not in it every day, that I'm like, how did I do this again, right, so you know I can feel that thing for sure- we ended up formalizing this program as what we call Slack Champions and it was kind of like a loose network of folks at our different customers who play this role that you're talking about as internal advocates and enable enablement.

Speaker 3: 38:47

And you know, we would invite them to events and we would give them swag and we would give them sessions and access to our folks who could help answer their questions.

Speaker 3: 38:56

And then later on, when we got to the point where you know we were big enough and had big enough customers that we had to sort of like preview upcoming changes with their admins and with you know people internally so we didn't surprise them with a big change that Slack Champion Network turned into this incredible group of people who would give us early feedback on either prototype or upcoming releases.

Speaker 3: 39:22

And so this would be a handful of people at a giant company of hundreds of thousands and we'd be able to turn on a set of new features for them and give them a real taste of what was coming and we'd get feedback from them over months that would often end up shaping the product or shape the documentation, shape the story that we were telling about it. Why is this change happening? Why do we think it's important and what's the best way to adapt to it. To that end, we also had internally in the product and design and engineering org for big, big changes, like a big interface change or a new feature or something like that, we would have an internal document called Change is Hard and we would basically, from the customer's perspective, either things that we were anticipating or things that others had told us, or the champions had told us all the things that were going to be hard about this.

Speaker 1: 40:15

I'm stealing that change is hard I was smiling because, like, that was actually what was going through my head at the time when you just said that.

Speaker 2: 40:23

So yep, done, I'm stealing it.

Speaker 3: 40:25

There's no point in sugarcoating it, right? I mean, when have you ever opened a piece of software that you're used to using and it's changed? And you've'd be like, yes, it's changed, it's like it's awful, it's like, well, the button's different and labeled, and like nothing works the way I expect. And so you gotta meet the person where they are and anticipate that this is probably not going to be something they're welcoming. And it's twofold One, you have to recognize and anticipate the issues and try to address them as best you can and provide them with pathways to get back to a place where they feel like they're in control of the tool. And you have to do a good job telling the story of why you've made the change, because I think the most frustrating is when software that you're used to using changes and you don't really know why it's different. It's either just different for difference sake or it's different because of some business model change.

Speaker 2: 41:22

I'm looking at you instagram, it's like, it's like, it's like why exactly? And I have two accounts, and then like one of the accounts it's you know, the button here, and the other one it's somewhere else, like it doesn't make any sense no, no, no, no.

Speaker 1: 41:29

It's funny because I'm working with a client right now, um big global client, and what I'm helping with a client right now a big global client and what I'm helping with is some transformational stuff and onboarding and I used to work there, so I was on the other side of it and I've been coaching the team that's trying to foster adoption of this technology and part of what I'm doing is building out out some new, new templates for them to kind of do change management, adoption, rollout, and in that process I did some research.

Speaker 1: 42:00

I found this article I think it was Harvard business review or something like that that was originally written in the sixties or seventies, maybe the eighties, and what struck me was everything I talked about about why change is hard and why there's resistance.

Speaker 1: 42:15

Resistance is absolutely true today because it's human nature and you know, you fast forward to today and I actually think it's more acute because people are so busy that even if a change that they have been told, or even if they believe is going to be beneficial, it's still a disruption right and that transition time is hard because now you're going like I used to do this this way, now I can do it this other way and maybe the outcome will be better. But I have to learn this new way and it's, you know it won't. It's not intuitive yet because I haven't gone through it right. So, like you said, meet them where they are, and I totally believe that If you've got a team that you're trying to get through adoption of a technology, you've got to be realistic about they're either resistant, they're excited, they're ready, they're not ready. All those things should be a factor in how you approach it. You can't just go and do it exactly the same to every team in every scenario.

Speaker 3: 43:16

That's right To steal. Another sort of way that Stuart used to talk about it we'd say nobody sits down at their computer to use software.

Speaker 3: 43:27

They're sitting down at their computer because they need to show new thoughts or they need to reach out to somebody or they need to, you know, design a piece of equipment in autocad or whatever they're they're trying to do. They have some end in mind. They're not trying to use your software and so much software is so self-important and how it presents things like change. You know the software that I use infrequently infrequently enough that every time I open it it's different, and every time I open it it's different. And every time I open it it gives me some marketing carousel.

Speaker 3: 44:00

Here's a learning features and AI, this, and click on that and take a tour, and you can't get past it and it's like no, I'm just trying to like get my file or whatever it is I'm trying to do, and I think like it's very easy to fall into that trap. Okay Again, stuart, I. And I think like it's very easy to fall into that trap. Okay again, stuart. I just steal all his stories because he talks about this stuff so long so long he calls this the owner's dilemma or, sorry, owner's delusion, pardon me.

Speaker 3: 44:27

And the best example is you open a website for a restaurant and what you want is the hours and their phone number. Maybe they're making, maybe probably their location.

Speaker 1: 44:38

Make a reservation now.

Speaker 3: 44:40

Yeah, but what do you get? You get a video with music and a fancy slideshow of like pictures of a wine glass and you can't figure out where anything is. And that person, who you know asked for that website to be made, had this idea of, like how they wanted to present themselves, basically, instead of thinking about what the person using that website actually did. And I think if you apply that over tens of thousands of product decisions for the software that you use, you end up in a pretty bad place, and you know we always try to avoid that. I'm not saying we were perfect by any means, but I think it's an important way of sort of staying humble and making sure that you're always trying to, as I said before, make the software that you want to use and treat the customer the way that you would want to be treated as a as a user of software.

Speaker 1: 45:30

The only thing I could say about those restaurant websites is at least I think there's like three templates that they all use so I can quickly figure out where. That's funny. Um, yeah, I mean this has been. I think it's funny.

Speaker 1: 45:45

I'm sure our listeners when they started this, if they got this far right, they're like how is the story about slack gonna have it help us?

Speaker 1: 45:51

And I think, like all these things about and again, again I'll go with Mike like he would have said, right, he's been pushing that marketing ops should be we should think of ourselves as product managers and I'm sort of on the fence about it. I think this is a story that tells us like you need to listen to and understand what your audience, in this case, if you call them customers I hate calling them, like your internal folks, customers, but that's the analogy, it's true, right, I mean you should be trying to help them be able to do the work they want to accomplish, not use the software, like that's a really good distinction, and you should be listening to their feedback and like all those things I think apply and then how you get them to adopt it. Like we talked through all these different things, you meet them where they are and understand the change is hard and they're going to be going through that. How about you, naomi? What are some key things you picked up from this conversation?

Speaker 2: 46:51

Well, I'm switching the name of my QBRs. To Change is Hard Right.

Speaker 2: 46:55

And that's the first thing picked up from this conversation. Well, I'm, I'm, I'm switching the name of my QBRs to change his heart Right. And that's the first. That's the first thing, no, but, um, in all seriousness, I, I really do think that it is important to get that feedback and I think that uh says marketing, ops, people, professionals, we are very good at telling what should be done, how things should be done and what we think should be done.

Speaker 2: 47:20

But if we just take a bit of a step back and I think you know I'm not saying run an NPS survey to our internal business partners, but I think it is important to talk to them and just say hey, you know what's working for you and what's not working for you. What are some of the challenges that you do have? Are you not? Are you getting the support that you need? You know they say it takes seven times to hear something before you. It really sticks Right when you're trying to learn something new.

Speaker 2: 47:45

You know, do you need this X, y, z training from us seven times? You know not watching a recording seven times, but do you need us to repeat it to you and show it to you? And you know help, you do it, templatize things. I think that's just really important and not just assuming that everybody is, you know, on the exact same knowledge path, that we assume that they are. And I think, if we can be open to listening to what they're struggling with, I just I honestly think that it will help the entire organization when it comes to enacting programs and what we all want generating leads and pipeline new business, open opportunities, things like that.

Speaker 3: 48:26

Something that's common in user research and product development that might be useful is that you don't necessarily have to talk to everybody, right? You can get a ton of information if you just talk to a handful of people and like with a product. If you put a product in front of five to eight people, you're probably going to pick up like 95% of the issues Like you might miss something, but you're going to get the majority of it in terms of like. Does this solve the problem? Is this useful? What did they trip over? And you know, often with our product prototypes that's what we would do.

Speaker 3: 49:00

We would put it in front of a handful of people, get a wave of feedback, do it again, do it again, rinse and repeat until the point where we weren't learning anything from the small groups of people and then we started rolling it up to larger groups of people and then we would find different types of issues at scale. But I imagine the same kind of thing might hold if you're rolling something out to a large organization. You don't want to put it up to everybody and ask feedback. You want to put it up to maybe a handful of people who you have a relationship with or who have been able to provide feedback in the past or who you can foster that relationship with, and if you get five or ten of them to talk to you about what they're seeing and what you might've missed, you're probably going to avoid exposing that issue to the thousands of the company.

Speaker 3: 49:43

Yeah.

Speaker 2: 49:43

Yeah, I do, I like that.

Speaker 1: 49:46

Yeah, I think. Yeah, I remember many years ago in my career I was responsible for some website stuff and one of the things I think similar to what you're talking about, johnny, is when we, when we were rolling out new things or, you know, trying to traveling out new designs or something like that for set parts of the site with our sort of internal teams, a lot of times I would just go and have them, like here's the website, you know, do what you need to do here and see how it goes, and the hardest part for me was not talking right, not guiding them Right. I really think that's so hard.

Speaker 3: 50:27

But yeah, it's the software that you've made. It's like it's a circle of hell.

Speaker 2: 50:32

It is. It's like no, just do it.

Speaker 1: 50:36

Yeah, it's really hard to do that, Johnny. This has been great. I think I even picked up stuff from here that maybe reinforced some things that I believe that hadn't really been at surface for a while. So thank you for that. I know you're working on the storytelling about the early days of Slack, but is there anything else that you want to share with our audience that you're doing or how they can keep up with that?

Speaker 3: 51:04

Yeah, well for sure. Thanks so much for having me on. It's really a pleasure.

Speaker 3: 51:08

Ali Rayl and I who's also very early along with me at Slack have been at State for a long time.

Speaker 3: 51:14

We've been writing this blog, buildingslackcom, which is shared sort of from the origin story of shutting down Glitch and starting Slack up to sort of when we started to really experience hypergrowth. We took a little lull over the summer. Here we're about doing some other things, but we've got some exciting stuff queued up for the fall, sort of talking through some of the challenges we experienced when we, you know, went from a tiny team of eight to a team of hundreds of thousands and from, you know, billing for a million customers to billing for tens of millions of customers and everything in between that led up to our our IPO in 2019. So we're into sort of the meat of the story and I hope that you'll tune in and follow along.

Speaker 3: 51:52

We don't post super regularly, you know, but you might get one or two newsletter emails a month. We'd love to see you there and also hear your feedback. Those are kind of the most fun. Actually, we've been doing a series called you Asked, and it's when people read something in the newsletter and they have a question and they share it with us and then we use that as sort of the emphasis for another post answering that question.

Speaker 1: 52:18

So those have been some of the best ones. Love that. Love that like real-time feedback. All right, well, naomi, thanks for hosting johnny uh in your home studio there, and be a part of this.

Speaker 2: 52:27

I'm about to go feed him lunch too now.

Speaker 1: 52:30

Good for you, well, jenny. Again thanks both of you, thanks to all of our audience out there for continuing. Good for you, well, again thanks to both of you, thanks to all of our audience out there for continuing to support us. Hope you learned something from this episode. If you have suggestions for guests or topics or ideas for that, or if you want to be a guest or have a topic you want to bring on to the show, feel free to reach out to Naomi, mike or me, through Slack, of course, or through whatever platform you can get to us, on LinkedIn or whatever. Until next time everyone. Bye now. Bye everyone.