Elevate Conference — Chris Slowe, Reddit's CTO — "Managing During Growth & Change"

Hey, everybody, just want to say thanks for being invited to being effectively the opening band for this event. I kind of hope that as the opening band, you all find me ultimately interesting but unremarkable and forgettable in exchange for the following act, which is going to be where that real meat comes. So, you know, wrote this talk about the brief history of managing at Reddit, and as I was writing it, I realized that a better title would have been A Brief History of Managing at Reddit. It's been a long 14 years and so quick thing about me, I'm actually, I'm also Reddit's first employee. I started off my career in science doing physics, have basically done my entire career in startups and enjoying that, did a tour of duty through the travel space at Hipmunk and so really kind of bookmarking my career at Reddit. It's been a fun experience. I'm just kind of curious how many people here actually use Reddit. Okay, it's a technical crowd. I'll skip through the next couple slides. Not important. I'd say that one thing to think about us is that we're kind of a big deal. We get a fair amount of traffic. I like to think of us as kind of the biggest little site that no one's ever heard of. I think this is a very technically focused group and so we're probably pretty common among you all. But this talks more about how do we get here. And kind of going back to the early days, the thing that's been most interesting about Reddit is that discovering retrospectively that Reddit is this case of a magical product market fit before people called it a product market fit. And we had in the early days a very small team and we were consistently doubling. So we were doubling every three months. I was the first guy doing traffic analytics. And it was actually really harrowing to be able to see in the week over week graphs, you could see the actual slope in the trend. And you know, so we kind of spent most of those years just kind of keeping the wheels on. And unlike most companies, we actually are, we're post acquired, post spun back out. And so we got acquired early on in 2006 when we were still a startup of only 18 months old. We didn't raise our Series A until 2012. So the effect of this on us is that our employee growth was a little bit different from most companies in that we up until about 2011, we only had about four engineers on the entire team. And actually the funny thing about this graph is that the Axis actually should go all the way to the edge. It starts in 2008 when we started keeping a tally. So if you map this in terms of the amount of traffic each engineer has to deal with, it looks like this, which is a kind of a rather terrifying runaway curve. That kind of explains a little bit of our initial way to operate, which is that, you know, when you only have about five engineers and you're constantly kind of fighting fires. Managers, what's a manager for? I know what to do. The site's down, I have to go fix it. And another thing, PMs. Like, somebody's going to come in and tell you what to do. We know what to do. We got to keep the site running. And I think the last little bit is that there's been a lot of lore written about the mythos of the 10x engineer. Here's a picture of a 10x engineer. They stop bullets. I think the 100x engineer repels the bullets back. And you know, the thing with FedEx engineers is that they're really compatible with working in a startup, right? This person who's self driven, they don't need to be pointed. They will go and get things done. And they are also, you know, generally, in my experience, unmanageable and amanageable, or at least you have to kind of figure out the right kind of niche for them. So, you know, the side effect of all this is, you know, the first thing we ended up with is in a land without PMs, this is what our product looked like and it actually works. I mean, I really have a lot of affinity. It's like a baby picture of my child. But we kind of think we could do much better. And then so following 2010, we had kind of an interregnum, or another way to describe it would be an interfoundarum. We all kind of disappeared and went off and did other startups and then kind of came back in 16. And the company size from 16 on has actually been the thing that's been up onto the right. We've been doubling pretty consistently for the last couple of years. We're up to about a 500 employee base right now. You know, pre2010, the employee org structure looked like a box, which is we had a couple engineers doing things. Shortly thereafter we had enough people who could actually say like, oh yeah, you specialize in front end, you specialize in back end and we'll kind of work it out. And that works for a while until you actually start getting more people in and your org Chart starts to look like this, right? So here is like the. This is an extreme case of the layer cake and candles model, if you're familiar with it. You know, deciding on vertical versus horizontal teams. Why not both? And, you know, this is where you actually have teams that have to coordinate and you have people who have ideas of what they should be doing, which might be different from what they are supposed to be doing. And that's where one of the first things we had to kind of settle up on is what is the role of a CTO versus a VP of eng? And I think that everyone has a slightly different take on this. And that's fine. Companies have to decide kind of what the roles are. But the way that we've kind of divvied it up is that both of them have to be technical. VP of Engineering is in the name, so you should be an engineer. But the VP of Engine focuses mostly on the execution side, whereas the CTO is more on the architecture side. A crasser way to say it is. VP of Eng also has to really, really heavily be a manager. It has to be in charge of running directors, running teams. I am dressed in my official CTO hoodie today, so I'm choosing that role. But, you know, I think that the other thing though is that at a certain scale, both jobs are about people, right? I love to write code. I don't get a chance to write code. It's really inefficient for me to write code. I cause more problems than I'm worth writing code. I am mostly working on getting myself out of the stack. And so I think, to some extent, you know, the important thing about managers is that you should think of yourself as being basically meta engineers, which I think makes me like a meta to the end engineer, which is a terrifying thought. And one of my running jokes is that the T in CTO actually stands for therapy, which really is probably more of what I spend my time on. So it's a couple lessons, you know, kind of in no particular order, this is one that I have stolen from Alex Ley, our VP of Product, which has just become really important over the years, which is process becomes culture. And so what I mean, what do I mean by that? Well, so it doesn't just mean that by repeating the same thing over and over again, you will achieve change. It's kind of like the, you know, the brave new world repeating to become a fact. This is more about making sure that as you set up processes that are straightforward and that are consistent, they will just become the way people operate. And so you will affect change over time because it's just the way things are done. And once you've gotten to the point where it's the way things are done, you've affected the culture. And so really about setting up with setting up processes, we think about it as trying to set up what's the minimum viable process you can set up to actually affect the change you want and to accept the fact that any process you're going to put in place is going to be imperfect and to iterate it. And so as you're kind of tweaking the process, you're kind of massaging the culture. And there's a long time for that to kind of set in. Another thing that's really, I think a big deal is the importance of values. Now, the hard part about writing this talk is that I had to get a little bit, like kind of nostalgic and retrospective. And so I got a chance to think about what I would have thought said if I had seen this slide as myself in 2008. And my thought was values, like, oh, it's gonna be like a management wonk talk. Great, actually, like really super important. Like, this is probably one of the most important things as a leader that you can work on. And, you know, treat this as like a meta lesson from a meta engineer that, you know, kind of in the mythical man month notion, like, part of the purpose of management is that you are connectors and you're cutting down on the number of hops between people. So you're basically making this N squared communication problem simpler. And so distillation of values is like another version of effectively how to convert important bits of information into what amount to being memes. Like short circuits for conversations of we don't do X because we have this value. And, you know, another way to think about it is to some extent, a company itself is just a giant legal construct and laws are just ideas. Not just ideas. They're enforceable ideas, but they're ideas. And so having the hearts and minds of your employees is really about having them think about values as a way to enable the company to be and to be coherent. I should have opened this talk with a disclaimer, of course, though, which is that beware of physicist pedaling in metaphysics. So getting a little weighty here with the philosophy. So another bit about values is that in the same way that software is a living document, values should be treated as kind of a living document. And this doesn't mean that all values are necessarily going to be going to be changeable. But it does mean they fall into classes. And so if you think about it, you kind of have like three broad classes of values. There's the straightforward implicit values, which are the ones you don't have to say, right? We don't steal, we don't embezzle. We act generally in good faith. If those are a problem, those are like, you shouldn't be existing in society. There's the next stage, which is like the ones that are core to the company that you treat as immutable. And those are going to be somewhat tied to your mission, but also just kind of tied to what you really want to emphasize going forward forever. Like whether or not people are living it. People should be living these. And the ones we have actually are two big ones, which is, remember the human, which is a statement both of the employees and of the fact that we're a community site with a bunch of people and evolve, which is just to say, continue to change. Like, there's no stability, there's going to always be change. So just embrace it and just move on. Then there's the set of values, which really, I think are more like the kind of we need to effect some cultural shifts and cultural change that have to be heavily iterated. And so one we had for a very long time was actually one of my favorites was everyone does the dishes, which is just a statement of don't leave messes for other people to clean up. As you get bigger, sometimes you end up hiring somebody who does the dishes. I mean, it's kind of like where, you know, where things like having test engineers and QA comes into play. Or literally a person who does the dishes. Dishes because your office mates are like having a bunch of roommates who you see eight hours a day. So some other quick tidbits, and I'd say, like, a lot of these things work as well for software engineering as for management. That's mostly what keeps me alive, is that, okay, feel fast and iterate. I think everyone has seen this. I think the way that I've been saying it recently has been the better is the enemy of the good. And I think that's one of those phrases that tends to be misused. It's not saying don't seek the better, it's saying don't prematurely optimize. You don't necessarily know what better is yet. You just know that there's a good solution. You should just strive for it and get it done. I used to have the rules of engineering joke set of rules up on my wall, next to my desk. And one of the ones that really stuck with me is this notion of 80% solutions. Seek the 80% solution, because that last 20% is actually probably another 80%, and there's usually another 80% after it. And this is why things are always late. And so, you know, don't even get me started on the fourth 80%. So it's like you're always going to be trying to find the next thing to fix. And so you get this, like, kind of quality of time curve which is going to flatten off pretty rapidly. So kind of hit that knee is where I'm kind of going here. This works for processes as well. A process is like a program run on people, and people are really, really crappy Turing machines. They're going to, you know, this is why you have to distill things down into very simple, simple ideas. Especially the broader the audience, the simpler the idea. And so, you know, with processes, though, since you can think of it as software running on your company, a broken process is going to have huge implications for the way things operate and how quickly you can execute. And also, keep in mind, with processes, the optimization is very difficult, right? The iteration time is very long, the substrate is really poor, bunch of people, and. And you don't actually necessarily know where you're going. You just know there's a bunch of problems you're trying to deal with. So this kind of comes back to my point of minimum viable process, like try to find out what will solve the problem and move us forward. Should also kind of call it the fact that mentorship itself is a value that has to be kind of instilled. We always talk about mentorship, but until you actually make it a part of the process, you won't actually do it. I think in our case, what we try to call out is the fact that leadership mentorship is part of leadership. Staff Engineers, for us on our IC ladder are as much about leading as they are about writing code, right? They have to affect change through their actual work and through an example. And so I think even, like the phrase, IC is kind of a really unfair misnomer. No one's really an ic like an individual. Past a certain point in your career, you can drive really hard to being senior, but being staff and above, you have to kind of work with people. And really, just as we get bigger, mentorship is more important, right, because you have to actually put time into it. It's easier to get lost in the crowd. It's easy to not know what the outlet is for mentorship. And so making it part of the culture is the key point here. Time is money. So this one is an outcropping of actually meetings are very, very expensive. The bigger you get, the more you need to have meetings because you need to coordinate. However, you should think of a meeting as being a place where everyone in that room is not actually doing the work that they were hired for. They're paying costs for communication. So clearly stating the purpose of the meeting you're having, clearly talking about why you're there. As a manager, it's useful to you to stay informed. But just remember, you're effectively taxing your people by having that method. And they're decidedly not for entertainment value. I've met people like this who like to be periodically entertained or like come in and amuse me for the next hour. It's not your job. And so last point here really is that values are about commitment and in the time is money thinking, values are about investment. So what you're trying to do is kind of short circuit ways to get the idea across. That is kind of like the cheapest and most efficient way. And so in our case, values need to be broadcast. Our main method for doing so is things like all hands. And all hands, by my previous rubric, are literally the most expensive things you can do as a company. You, you're pulling everyone into the same place, sometimes flying them out. And the reason why you spend that time doing kind of very big kumbayas and discussions is because that's your only opportunity to do that and to actually have everyone in the same place hearing the same things. And of course everyone's going to take their own piece of that away. And I'd say that remember also that with values, culture is kind of intrinsically self reinforcing for good or for bad. So if you do mess up your values, you have a chance to fix it, but there's going to be kind of a hangover period to get them in place. And I think the last thing is when it comes to mentorship, something that's not said enough is that teaching a topic improves the teacher as well as the student. Making mentorship a part of the culture is going to make your engineers and you better. So I think if the main takeaway I want to leave you all with is that stay strong managers, I believe in you. It's a tough road. And thanks for listening to me for these 15 minutes.