Chris Slowe (CTO at Reddit) Fireside Chat at Startup World Cup Grand Finale 2023

Chris received his PhD in physics from Harvard and also spent time as the chief Scientist at Hipmunk before returning to Reddit. Joining him will be Zach Morimoto, who is a partner at Pegasus Tech Ventures, where he deploys his experience in business development. He is also a graduate from Stanford Graduate School of Business, specializing in entrepreneurship. So please help me in welcoming Chris and Zach. Come on guys, bigger round of applause than that. Thank you so much.

Okay.

Yep. Hi everybody. Also, we just finished some pitch contest of the final 10 finalists, so still excitement is here. But actually now we want to ask you a couple of questions about yourself, but because all of entrepreneurs dreaming of being some successful ctos entrepreneurs like you. So I'm going to start the fireside chat with a question about yourself.

Sure.

So please tell us about your early life and how you got started and how you got to where you are today.

Yeah, okay, so early life, I have a non traditional background for getting into startups, so I was actually a physics guy. And so I got into. Okay, so short version of my life story, at least from the startup side is early 2000. I was in grad school doing physics and through, I will jokingly say, no fault of my own, I actually got into the first Y Combinator batch with a friend on a startup idea. And so this is summer of 05 where we actually were working on at the time, this is going to sound silly, but we were working on desktop search as a startup idea. And long story short, at the end of the summer I had a failed startup, but two free bedrooms in my apartment. And so at the time, two of the other co founders in the batch were Steven Alexis from Reddit. And so I ended up the summer with two new roommates and then a couple months later had become the first employee, which was actually kind of a fun transition. But yeah, honestly the physics thing was mostly like experimental. And so I did actually spend a fair amount of time coding during the day, but I also spent a whole bunch of time machining during the day and fixing stuff. So I think the fixing stuff definitely fit really well with the startup mentality later.

Cool. So actually next question is about yourself, but actually you already answer the part of it. But next question is that your background is also non traditional since you are majored in physics and not computer science. And then do you feel like this has created any barriers throughout your careers?

So I would say that I think that a lot of software engineers tend to have really serious imposter syndrome and not being as computer scientist doesn't help with the imposter syndrome, in fact, actually probably makes it worse because it's like, why am I telling a bunch of software engineers what to do? And having to have that internal monologue of like, okay, you built the thing that they're fixing, so you probably have some experience and some reason to have something to be listened to. I mean, even to this day though, every once in a while I will kind of be shocked when something intelligent falls out of my mouth when I'm talking about software engineering. But no, I think that not starting off doing CS and not doing software engineering as initial career just meant I had to kind of learn it as I went, which also meant that I kind of learned it in the way that like, I learned it in the way that was most effective to use it. I also do think that like a lot of degrees, especially in the sciences, like part of the degree is actually the, like the important part is not the science, it's the critical thinking part. And that's like totally applicable to everything that we do in day to day. And so, you know, taking up, taking a big problem, breaking it down into small pieces and then fixing the pieces and kind of putting it all back together and then finding out that you're completely wrong, that's like kind of science. Or software engineering.

Yeah, that's a great lesson. Then probably your approach can be applied to many different aspects of business or maybe science and engineering in a broad field. Okay, great, thanks then. Next question is your career. Then you joined Reddit as the founding engineer and today you are the CEO of the company, large company. And what are some of the biggest challenges and opportunity does a company has evolved over 18 years?

Oh geez. Okay, so I would say lots of things. So you know, having seen the company from all the way from like four folks all the way up to 2,000, a lot of different epochs in there in terms of like the scale. I think one of the exciting parts is definitely on the hiring side of like learning, learning how to find good talent and learning how to hire and then learning how to basically like the job switches from hands on. I'm building a thing. Oh crap, the website is down. What are we going to do? Fix it. Iterate to the next thing to oh crap, I think we need a manager. And then kind of like having to work your way up past those things of like, oh, what does a manager do? What do PMs do? What do directors do? And then kind of like discovering along the way that like there's these, like, there's a reason why companies are Structured like they are. And I'd say definitely a place where this is a room full of startup folks. And so I'd say like, oh man. Finding a good mentor or set of mentors along the way is so valuable because they get a chance to at least. You're not always going to listen to their advice, but they're going to sometimes give you little nuggets that later on will be like, wait, at some point in the last six months somebody said, director, what did that mean? And you can actually go back and ask them and find out what you missed. I usually like to say this about to growing up in this career, I initially when I first became like a manager, like early on I remember like going and like doing the good student thing and getting a bunch of management books and trying to read them and be like, oh, I'm gonna learn about management. And like they're actually pretty useless before you've actually done the job. It's like learning about software engineering without touching a computer. Being able to like actually like kind of do it for a while, discover that you don't know things and then ask the questions has always been like the valuable learning part. And I think that applies like, hey, that applies for pretty much technology as much as it does for the people side. But yeah, I think the growing pains along the way have been the standard ones. How do you scale up a company with a product that has a whole bunch of users on it without having to take everything down for maintenance all the time? Our current thing is the fashionable thing of yeah, we have an 18 year old monolith which is lovely and charming and really annoying when you have 2000 people have to work on it, that we've been gradually, slowly decommissioning for the last like six or seven years, that kind of thing.

Great. Actually you already touched upon some kind of recruiting thing. But this is. Next question is about the recruiting, but actually what has it been like to recruit engineers? 18 years ago when he joined the Red Hat, but as a small company, I'm a small startup and today as a 2000 person global company, what is the difference between them and also what is a player? You just mentioned a player to you and then actually how have you identified those people who read it?

Yeah, so I think that the. I've definitely evolved over time on like what we've looked for and like to some extent the people you hire definitely have to fit the stage of the company that you're at. And what I mean by that is like in your first, if you Think about the first 50 people in your company or even the initial group. That group is not just the people who will get you to your series A and your series B. That's like the cultural seed. Like, that's the group of people who are going to kind of set the, set the course of how your culture is going to evolve and it'll have impact in ways you might not even notice until later. And so that initial group is like, you know, you need to, for the first even 10, you need to hire people who are going to be kind of true believers, who are going to be passionate about the product and about the, about the business and who are going to be fairly autonomous. Right? Like, you know, you can't spend a lot of time hand holding people in the first 10. You've got to actually be able to make sure that they're like, they're good at their thing and they're going to go off and do it. And then you can coordinate because, you know, a lot of coordination overhead becomes. Because as you get larger, you're limited by N squared, right? The number of relationships that you have in a group. And when N is small, you can actually have everyone coordinate and you can kind of keep a mental model of what everyone's working on. And once you get to a certain point, that gets prohibitive. So that initial seed really is like this autonomous group scale past 50. And now you're starting to talk about like, you probably have teams and you probably have managers and you probably even hired somebody for hr and you probably like are thinking about, you know, you're raising a round and you're thinking about the growth, the next half. And now you have to really think about more of the team dynamics. How do I get people who can actually integrate with the team, who can basically kind of do, I don't want to say just do what's asked of them, but to some extent, some of it just starts to turn into, there's a ticket that needs to be taken care of and handled, there's a code that needs to be written, there's a product that needs to be built. And so you want them to be passionate in their area. And the shift I think that happens is there's oftentimes a very, there's a bit of a shift in culture from the first 50 to the next 200. And that's because the first 50 is really like the founder group. And those are. They're going to really want to like they have a lot of opinions about everything inside and outside of their wheelhouse whereas that next 200 or you're going to be starting to hire specialists. And so that's where the shift happens on the hiring side. To get back to the question on the hiring side, you know there's always been this like in the valley especially this is Mythos of the 10x engineer of like this like these people who, you know, they don't write code, they think and it appears on the machine and they're able to just like, you know, generate all this great stuff. And like those people do exist and they're really valuable in that first 50 and they're really tough to fit in when you get larger than that. Because some of those folks like literally work by stealing Xs from people who are around them. Like they're just like they. The mindset of I'm going to go do this thing is very distinct from I'm going to work with a team and enable them to get this done. And so I wouldn't say that we shifted our hiring mentality but actually it's more like we realized at about that point that an important feature of an A player is actually humility. Like you want somebody who's going to come in and be curious and who's going to ask questions and who's actually going to want to work with others and help to make them better as much as making themselves better. And of course like you know, you do have to be able to write code. That's kind of part of the job with software engineering. But you know, as you get larger we started thinking about things like architecture's important, right? You need to have people who can enable large scale systems and like actually lead by example and also lead by, you know, it's like I'm going to run into this burning building and I want you all to come with me.

Yeah, I think it's building up the question to over that. You answer that actually the. Do you think it's a faster 50? Do you think it's a faster 50 of the company should be A A player to you or.

I mean look, the proper answer is hopefully because not all of your company is an A player at all times. But like you, you know, there's that old canard that I would like to invoke which is like A's higher A's and B's higher C's. Right? And so you've gotta make sure that you keep your hiring bar high at all times. And I think part of the initial scale up is learning. Like look, in your first 25 you're gonna hire somebody who isn't fit. Yeah, you know, that's like, that's like. It's like kind of a part of, part of the growing pains and like part of the growing pains of a startup is like learning how to be like, how to be able to let somebody go in a way where they don't feel like, where everyone feels okay about it.

Yeah. I'm asking because probably majority of a startup today is at the early stage of a company.

Yeah.

And they are so keen on, you know, learning about the hiring from you.

So they.

That's why I'm.

Oh, yeah. No, I think, I think it's like, well, it depends on what you need them for. So I think if you're talking about, like, look, it depends on the industry a lot. I'm coming at this always from the kind of the now traditional kind of like web stack startup where you have like a product and the product is actually the technology. But early on, like, I've done other startups, like I worked at a. I did a travel startup called Hipmunk and we actually had to early on hire customer service. And that was a fun experience. And like, for customer service, it's much more transactional. And so you want somebody who's gonna be good and understand the product, but you don't need to necessarily. It's a different setup.

So let's switch the gear toward your product and technology. So next question is, what technical decisions have you made at Reddit that made a notable impact on your organization? Such work?

I think that what if I made this actually an impact on the structure. Structure of the company? So I mean, at this point, one of the running jokes is, so I mentioned before that we are currently going through and decommissioning our monolith. It's a lovely thing to do. One of the things that happens as you grow up, as the company grows up, is that the technology choices you make in the past don't always apply well to the future. And in fact, I have a running joke that technical debt, or complaining about technical debt is the luxury of your company not failing. So when you get to the point where, like, you're talking about technical debt, it means you've actually hit some milestone of like, great, we are not in an existential crisis right now. We can actually deal with this debt that we took on. Because after all, debt is something you take on so you can move faster and then you have to go deal with it. I would say that some of the choices we made well, early on when we Were running small and lean. Having a single monolithic pile of code works really well because everyone's working on the same surface, there's very few of you you can coordinate. Much later on, you start to go through and break it into chunks and it's like it's better from a scaling standpoint to have chunks you can scale up independently. It's also good from an organizational standpoint because now you can say like, hey, team X, you're in charge of service Y, go to town and you have a nice separation there. It ends up becoming this game of just setting up contracts everywhere. Right? You have two teams that have to coordinate. They need to have a clean contract and their code has to have a clean contract. And figuring that out can. Figuring that out and disentangling it can be difficult. I do think also like that this is also part of the growing pains of scaling the company is you end up creating these like the stack will get split up. And so early on we had a team that handled all the infrastructure and we had a team that was in charge of mobile and we had a team that was in charge of web. And then at some point you have to make the decision of that works really well for the architecture. It doesn't really work well for the product because now the product all of a sudden has to coordinate across these three separate teams. And so making those changes and deciding on when to do the reorgs is actually an important component much later on.

Okay, so then, cool. How have you navigated the high stakes moments of doubt over failure? And what advice would you give when making your next big career move and then establishing an exec presence?

So it's taken me a while, even having done this job for a while of figuring out what exactly exact person presence is. And it's like one of those things where I think over time, I'm not dodging. I'll get back to this one. But you don't really learn about what a manager does until you manage. And then you have to figure out the job and then you have a chance to explain it. And I think the same is also true for directors. For directors, the job is. It's like a manager, but you're strategic too. So you have to be able to think not just about the immediate solve the problem. You have to be able to actually come up with a compelling strategy to move that part of the business forward. For the executive presence, like I often think a large part of it is just like you've seen so many terrible things over the years that you're just kind of like, oh, cool, that's on fire. What are we gonna do about that? And like actually having a framework to basically go in through and say. Or like you start talking in frameworks, which is always a little weird for me, but you actually have a model for. Yeah, okay. This is just like this other three times we've had some terrible disaster. Let's use what we learned from that and apply that. And that starts to come across different silos. Like, you know, when you start finding yourself applying. Like my background when I was actually doing software engineering was I was in infrastructure. So when I talk about fires, like, I'm the guy who for a very long time had like my phone page me and wake me up in the middle of the night and I would immediately wake up and like grab a computer. And to this day there's a ringtone on my phone. If it goes off, I want to grab a computer. And it just. Anyway, it's the same thing with the part of that is the clarity of like, I know exactly what the problem is right now. I'm gonna go deal with it. The executive presence part is really just like doing that, but with business problems. Like, here's a business problem, what are we gonna do about it? No one else can answer the question.

The more problem, the makes your grown ups in the. Yeah, thanks. Yeah. Okay, so let's talk a little bit about the future, your interest and what excites you about the future of Reddit and Internet.

Oh man. The future of the Internet. Okay, so one thing is that the Internet is an interesting thing insofar as the Internet, over the course of just my career has evolved from the open web being the model of how things work to. To everything being kind of somewhat siloed and app based. So to some extent, actually I forgot my starter point. Who here uses Reddit? Just want to double check that we know what we're talking about. Oh, there's more people here. Who here would admit to having seen Reddit? I got to wake you all up. This is terrible. So Reddit is a platform where we have a bunch of communities where users are allowed to talk about topics. It's kind of like an extension of the old 90s style forum model to make an extreme analogy where we center on topics. It's social media esque. And we have an engagement model involved with voting. And so the idea with Reddit has always been very much centered on the open web, which is that you go to Reddit to post content to talk about it. And that Posting is either via. You're either posting a link to something or you're posting an actual. Just like a wall of text and discussing things. And as the Internet's gotten more kind of siloed over time, like more of it is in walled gardens, it's been interesting to kind of watch it switch from, you know, everything is available at all times via link to a bunch of kind of hidden away silos of data. And so I mean, I think, like, look, the easy answer to the question is like, I'm really curious to see how generative AI affects the industry and affects the world to some extent. Like, you know, it switches from primary sources are important and links are important to, to there's some sort of like a machine overmind that'll give you an answer if you ask it a question. And all that is, is it's been like it's effectively all of human knowledge to spill down to a bunch of fantastic sound bites. I'm interested to see how that turns into a wonderful toolkit for us to build things more than anything else. Like, I don't think of it as, I think there's a lot of doom and gloom around it, like somewhere between extreme optimism or extreme pessimism. I'm kind of middle on this one. I'm just saying it'll be a neat tool. And, and I like to make the analogy, but it feels like it's like it's the same thing that Photoshop did to photography.

Yeah. Great. Yeah, thank you very much. We already, it's time to go. And actually, thank you very much for your conversation.

Yeah.

Chris Reddit, thank you very much for having.

Thank you so much, Chris. And Zach, we have some gifts to show our appreciation. A big round of applause. Thank you again so much for your time and your energy and all the insights that you shared with us.