How We Are Building External and Internal Communities at Reddit - Chris Slowe, CTO at Reddit

I always like to say in these situations with an intro like that, there's nowhere to go but down. So thanks. Thanks, Bonnie, for the intro. Nice to be here. It occurred to me when I was coming up here that I think one of the last talks I gave on like live was actually elevate in 2019. So, wow, the 20s have been wild. Thanks for coming. Let's see if it's working. Oh, it's working. Yeah. I already gave the intro on me. So founding a Reddit spent my career doing startups, so I have lots of opinions on the under 2000 phase, if anyone has any questions about that. But, you know, this is the no BS conference. This is my professional slide. This is the real slide. So I'm basically a stack of aphorisms and jokes in a trench coat. For the record. So having done most of my professional career at Reddit, I. Please heckle me. I'm more comfortable when I'm being heckled. I also can't take myself particularly seriously as a side effect. I mean, 18 years of Reddit, Internet radiation brain damage. I'm trying to give you a bunch of realistic situations that have come up over the years at Reddit and give you feedback at the same time. So I'm going to move this way slightly and then basically I like to build stuff. So the crux of this talk is about what we've built over the years. So really quickly, let's talk about Reddit. Reddit's mission is to bring community and belonging to everyone in the world. So we try to be values based, and that means that we're also values based, not just to the company, but also on the platform itself. So we want to make sure that we reflect the diversity and richness of real life on the platform and that our company has the same sort of internals, you know, art imitates life sort of thing. So I'm going to talk about both how we managed to get community on the platform and how we get community inside the company. So I'm going to focus on that part and it is interconnected with the belonging and empowerment. But honestly, our model is different enough that it's actually surprising how it came about. So I want to start off by talking about that. So some key points about Reddit. First off, this is one of the oldest jokes on the Internet. Literally on the Internet, nobody knows you're a dog. We have no social proof, we have no real id. In fact, we're kind of allergic to it. We don't think it's a good idea you can have as many alts as you like on Reddit, just don't be a jerk. Your words are your currency and we want to make sure that the words mean something only in the context of the community that's actually there. Okay, so let's jump into how we got here. Historical OLD MAN yells AT CLOUD okay, so Reddit's baby picture. This is, I think the most appropriate baby picture would be the first snapshot on the Internet archive. So this is what that is here. This is looking back into the deep past of July 2005. You can see we had a certain, we'll call it a clean aesthetic at that point. But I just want to remind everyone here, for those of you who may not have been around as long as I have at this point, this is the archetype of the time. So the original harkings of Reddit were actually delicious, popular and Slashdot, where the focus is really on link sharing. And you know, in the modern era, silly thing, sound check. At the time, Twitter and Facebook's news feed didn't come in 2006. So the idea of being able to find news and find interesting content was actually kind of hard. You basically went and either did like, you know, stumble upon, click a bookmarklet and just jump around on the Internet or you went to some one of these sites. So just to kind of like earliest possible feature we released was way back in December of that year. Or we turned on comments like originally it was nothing but links. There was no way to discuss it. We turned on comments and literally one of the first comments was, well, I guess this place is over now it's slash, dot, I'll see you all later. So the rest, as they say, is history. But the nice thing is the comments started to create these places where people could actually connect. And that's the initial starting point. So the arc here kind of a speedrun through the first five years. We originally had link sharing, we added comments, we started having increasing content. You get this nice flywheel of engagement and users. And then we discovered that actually, well, there's now so much content and there's only a single page at this point. There's no community model. This is the front page. That's it, that's Reddit. We decided, well, okay, let's start to break up this community into pieces. So let's just create topical areas like sections of a newspaper or channels in IRC. For the youngs in the crowd, IRC was what Slack was called 30 years ago. So as we created subreddits we had to actually start to come up with a way of, well, how do we now make sure we can actually moderate these spaces? Because initially the moderation was just us doing spam control. There wasn't really much to moderate. So as I mentioned on here, all of this curve is also followed up with lots of scaling servers, much cursing, generally discovering how databases work, the sort of early 21st century behavior of web stacks. So let's talk about moderators for a second. So, so, fun fact, the original way we got to subreddits was we decided to call the page sub.Reddit.com and it kind of stuck. Like I said, more content, more services, areas start to become topical. How do we actually start to keep things on topic? Right, because now it's like originally banning was like, you're banning it because it's spam, you're banning it because it's actually something that isn't really useful. Now it's like, well, this is off topic. How do you start to identify that there's a reliance on voting that's intrinsic to Reddit? Everything is voted on. We have a nice way to scale things that way. We still have to have a way to keep structure. And so the solution we had with moderators, so the idea here was we forked the admin toolkit. We had to be able to approve and remove and see reports. We started creating the notion of very simple permission system based on that. And again, the model here was IRC and we gave them access to a wiki. We said, just write about what you want your community to be about and just go to town, have fun. The neat thing about this is that's kind of all we needed. These are the base ingredients. I want to say this was all part of some long term devious plan, but actually this seemed to make sense at the time and it actually worked. So communities, but how? Well, we added a little bit of structure because we provided some sort of about space. This meant that communities could not only explain what they were about, but they could actually start to say what should be here? How should you behave? They started to come up with the idea of rules. And so they would literally go through and start enumerating on the sidebar a list of rules. Don't post emojis, direct links only, just some structure. So now instead of having to say on every removal, well, you're in violation of blah, blah, blah. Because we don't like to have blah. They can just say, violation rule one, done, and the community's on board and they can actually see transparently what's going on. So this also gets to things like, more elaborate things like repost rules. Rules about behavior. What's really neat about this structure is that the rules get more complicated with time, but then more simple. So you can imagine this as a. This is actually one of my favorite also ancient now comics about the idea of sea lining. Sea lining is when it's an asymmetric warfare where somebody asks you a question that's hard to answer. And so you waste all this time answering a question and they just have to reply with another question. So you end up stuck in this loop. The same thing happens with rule lawyering. You have this idea of like you put up a rule. The, the more complicated the rule gets, the more you end up getting corner cases and edge cases and all these kinds of gray areas and people start pushing on that. And so actually simple but applied vigorously works much better in these cases. Context also is key in all this because you can actually now the rule is simple. You have to kind of understand the culture of the community. That's where we're actually headed here. Just to simplify it here, this becomes less of a legal code and more of a set of rules of behavior. This is over the course of really 10 years of just kind of gradual evolution. One of the most common rules on Reddit that you'll see is literally some variation of don't be a jerk. There is no way we as a platform could enforce the idea of don't be a jerk. But the moderators can actually decide what the bar for a jerk is, and it varies by community. Jerk on R gaming is very different from jerk on pictures of cats standing up. And so we have to actually be able to adjust. Of course, the trick with cat standing up is there has to be a picture of a cat standing up. It's in the name. I don't know why people have problems with that. So we started actually to see this use and we started to build the first class rules engines around this for moderators. So instead of actually having this like amorphous space, we start creating structure in the way the platform works, make it shorter for them, make it easier for them to manage this. The net result of all this is that these, these rules start to create norms and culture, right? Because you're going in with this clear kind of explicit social contract. It's like the Ten Commandments are posted on the side for any given time. You know what you're doing, you know what you're getting into. Okay, so let me Switch gears now to. So my push here is little simple things that shift culture. So I'm going to jump into an example of the rest of the job, which is the actual engineering management and how to actually scale up a company here. So I just want to give an engineering example for a bunch of engineers in the room. So we as technology leaders have to go in and figure out how to make sure our teams do what we want in the right way without having to tell them what they should be doing. The whole point is they should be autonomous. And so I'm going to give an example of what we did a long time ago with engineering design docs that kind of had this kind of result. Okay, so engineering design docs, here's a simple problem statement we've all encountered. You are given a spec X and then your intrepid engineer comes back with design. Yes. And the question is, is this the right design for the spec? Probably not. But they also haven't documented it up front. They've just thrown a bunch of spaghetti at the wall and they have a PR up. What do you do? Well, so for a lot of longer term, bigger projects, it's often useful to be able to express some sort of capital o opinion on what the right solution is and also to have a discussion up front before you really throw too much at the wall on what should the architecture be like? What are your assumptions? I think we've all seen this go awry in a number of different ways. Somebody comes along and like, I really want to use this new framework. It's really cool. So I'm just going to do that. And then before you know it, you've got six frameworks and they all have different models and you're kind of boned. This gives you a chance to say, like, okay, how do we actually make sure that we don't end up in that situation? So what we did, this is going back again, like good seven or eight years now, is we decided to do some very light process around documenting what exactly you are trying to do before you do it. And the goal here is like, you know, we have kind of two week sprints. Anything that takes more than about a sprint or two sprints, you want to document it up front just to make sure that you're actually headed in the right direction and just be explicit in the template here. So we have a question of what problem are you trying to solve? What problems are you not trying to solve? High level approach, whiteboard level, just to kind of get things fleshed out. Low pressure, low Amount of work, just kind of one pager and then ability to start hanging on the more detailed parts of it. And so later on you start adding things like security and privacy and compliance and all that really boring stuff. But to start with, you can start off with just engineering stuff. And the result here is you end up with this tangible thing that requires a bit of a sign off or at least some review. And maybe this is a crazy idea, talking to people about your ideas before you actually do something. So this actually now creates artifacts. Later you can actually refer to and say, why did we decide to do this thing? Oh, this made total sense at the time because there wasn't another choice to make made any sense. Okay, so I give this example because this small change, this like template create and this light amount of process has created long term outcomes. So to start with, we start needing some structure that kind of forms in the engineering teams. Somebody has to review the docs. You end up having people step up to be architects. You end up in a case where you have a queue you have to manage. And so we have to make sure there's enough process and machinery to keep it going. And the result is you can actually get engineers to now self organize to talk because people are blocked on things. They have to go tap the expert and say like, hey, I need help on this. Which is beneficial not only for culture, but for up leveling your team. We started pulling together weekly architectural review meetings. We made sure that there's pressure release valves in the process and these are little things that grew organically as the whole thing got more complicated. What works for 50 engineers doesn't work for 1,000. And so you start having to add some more structure. But the key point I'm aiming for here is we have a chance to not only talk about collectively trade offs and decisions to build some internal community across teams, but also we've changed the culture by just adding a little bit of friction in the right place in the system. Okay, so the lesson I want to try and get across here is one that I've carried with me for a while, which is process becomes culture. You make changes to the process, it will have long term cultural artifacts. Whether you like it or not is the key point. So some light decision making. We're showing what the org cares about, right? We're saying that for large technical designs they have to be thought out. We're saying that you have to be willing to justify your decisions potentially in writing. We're saying you have to be willing to document them. Isn't that great documentation. And of course you're also requiring engineers to engage with one another. Crazy, I know, but it's something that actually takes a lot of work. There's not yet been a technology that gets people to walk across the room and talk to somebody. And then, you know, this is a stronger statement than we use agile just to keep things organized. This is actually creating an opinion of how you operate. So I also want to be clear. This isn't just like repeating facts 64,000 times to make them a truth. Also kind of works. That's how I'll get into that in a second. But the point is that you want to mix the Kool Aid with reality. You want to show this provides value. I've had many discussions over the years in these design review meetings where initially an engineer who's really unhappy that we're not really vetoing their ideas, but just sort of suggesting there might be a better path, coming back later and saying like, actually that was a lot of fun. It was really good to be able to do a whiteboard discussion. And you really want to get to the point where this process just becomes the way things are done, right? That's how it becomes part of the culture. Everyone just behaves this way. Everyone makes sure that people are onboarded to behave this way. And the last thing I want to highlight here is, except the fact that processes are imperfect. You will have to iterate them, but they will actually, if they're working, you'll be comfortable iterating them because you'll know where the creeks are. Okay, so this leads to one of the things I always like to bring up. Feel fast and iterate. This is another thing we try to push really hard. If your process is going to be part of your culture, make sure you choose the right ones. I like to say also that humans are terrible Turing machines. They don't always follow your instructions. They find great loopholes. It can be really annoying. I'm also a big fan of the 8020 rule. If you can solve the first 80%, it gives you time to work on the next 20%. Take care of the easy stuff first. Work your way into the harder stuff. And as I like to say, don't even get me started on the fourth 80% of this work. There's always going to be another 80% to deal with in all these situations. Oh, here's my I got one ahead on my Turing machine joke. But anyway, process optimization is hard, right? You're not going to get right out of the bat and. And so optimizing for biggest win up front is generally the way to go. It's the 80%. And I usually try to invoke something like a minimum viable process where possible. We actually, as a matter of fact, we just did our annual culture survey and as usual, people are always grumpy about process. And when I went through and read the comments, it broke down cleanly into one third said we're doing great, one third said we have too much and one third said we have too little. That's not bad. That's actually kind of where you want to be. So now is the game of going and figuring out where the warts and all that. Okay, so to really hit home this idea of setting culture, I'm going to put up the slide importance of values, which honestly was one of those ones where like me 15 years ago would have cringed and been like, what books are you reading future Chris but the intent here is that values are like the rule sets of the mod example I started off with, right? Values are these shortcuts in behavior, right? They're these short, pithy statements that have a lot of context loaded in them and a lot of meaning in them. And they're effectively verbal shortcuts for when you're having a conversation, you're trying to decide between A and B. If you can invoke a value to say why A is better than B, that simplifies the whole conversation. If you can't, that actually means you might be missing a principle or a value somewhere in there. So just something to keep in mind for the really knockdown drag out debates. Distilling out values is a good way to broadcast out the things that are most important in a light touch sort of way. This is not going to be changing the speed or direction of the ship this year. It will gradually shift things over the year and you have to actually pay attention as that happens because you might have said something you didn't think you said in the first pass. And I just want to just emphasize the idea that almost everything that we do, we're knowledge workers. It's all ideas, right? The company itself is an idea. Legal constructs are ideas. And so the idea of leading with a bunch of ideas isn't really terrible. So you need to shore them up with other ideas and beliefs. All right, so just how to do this again, succinct, is really valuable. A couple of words, generally a couple of words you've actually heard people say is a helpful starting point. One of the ones that we currently have is one of my favorites, is Hope is not a strategy that is currently internally overloaded. We have a weekly award now as part of of our own hands for the person or group who manifests this. And the idea is that like hope for the best, plan for the worst, to be slightly pithy about it, really build into your plans the fact that things may not work and might break in some terrible way. Another key point, you gotta over communicate. And this is one that actually drives me nuts because I hate repeating myself. If you feel like you're talking about the same thing until you're blue in the face. Maybe half of the people have actually read the damn email that you see sent them and said please read. Although also I've discovered that please read in an email subject generally guarantees that it goes into the trash immediately. So you gotta have a better hook than that. You gotta really like, you know, take a page from buzzfeed because they're having a good year. And then, you know, last of all, it's like make sure you find ways to highlight other than with just comms, right? You want to be visible in this. In our case we started having awards, so just giving some bragging rights. Historically, when everyone was in the same office, having people that have stickers on their laptop was always a fun one. Incorporate into perf reviews, make sure they're part of the career ladder. This means you have to make sure they're refreshed as you iterate your career ladder over time. But honestly, values shouldn't change very often anyway. You really want to have a yearly maybe tweak or refresh if you can really handle it. I just did a refresh after about two years and I think it's actually a pretty good state for ours. And so if I can just get to the succinct point of all of this blathering I've been doing for the last 20ish minutes. Small and simple intelligible rules in the long run leads to shifting culture. So those little things you do and those little statements that you push and those little changes you make will shift the culture. And you're in it for the long game. So ultimately a tightly knit community is going to be much more nimble and able to react than a loosely knit bunch of bunch of nerds who are all unsure what the mission is. And with that, thanks all for listening. If you have any questions, I can take them live. I think we also have Bonnie with the official roster of questions ready to go.

Yes, yes, thank you. That was awesome. I never really thought about culture being just a key ingredient for community. And it makes a lot of sense. So really got a lot out of that. Okay, so we do have three questions in the slido so far. If you aren't set up with slido, you've got your QR code there. Okay, first question, how is Reddit handling false content from AI? What tools are you using?

This is a great question. So I think I'm going to answer a question right next to this question and say, and start off with what is the value of posting false content on Reddit with AI? And I think it falls into a couple of different buckets. One of them, the simplest one to deal with is like, okay, you are karma farming, trying to push spam later, right? Tale is old as time. Legitimately. It's been like the arc for Reddit for the last 18 or so years of boosting content or finding some way to artificially generate a bunch of Karma is a good way to push that content. The AI method of doing this is just a way to do it at a larger scale than we've seen in other ways, but it's not drastically higher scale than other ways that just do it mechanically. So that's kind of one starting point. Another one that comes up is, you know, maybe you want to get to like do a gotcha, which also happens every once in a while. You'll see like a poster like, I managed to game a thousand karma on Reddit with this simple thing. Look at me in my reveal video. Congrats. I mean, like, you did your reveal. Those, those kinds of things are always fun social experiments, but they don't really necessarily, they're not, they don't happen much at scale. The third case would be the bot. You know, this, this is eight agent comes along and starts to post a bunch of helpful content in communities. Well, that's kind of cool. Like you're paying for server time and you're helping our communities out. I'll go back to my on the Internet, Nobody Knows yous're a Dog slide for that one. And so I guess to get to the punchline here, it's like we care much more about the intent and about the behaviors than we do about who's generating the result. Oftentimes on Reddit, in fact, we use internally the word bot in a way that's actually much more positive because we have an entire ecosystem of party, third, third party agents that are kind of running around on Reddit doing fun things. Most of them actually self identify. And so we would rather take the tack of encouraging that sort of Thing of like, if you're going to make a cool AI bot, just label it as cool AI bot and you'll find the community is actually happy to engage with it as opposed to trying to do something a little shady for tools. Honestly, it gets down to just the value is actually not in the content, but in the metadata. Anything that involves scaled content analysis or abuse, the message and the payload and the way it was generated is less interesting than the signals that come into everything that goes into request and the structure there. So I think I answered around the question in a way that I've surrounded it, but I'm happy to do a follow up if anyone has a deeper request there.

All right, thank you. Okay, next question. What are a few tips to keep in mind when you're picking organizations to serve?

Ooh, could the person who asked this question. Oh, no.

Okay, I see. Okay.

Oh, is this from the. Is this from the. Oh, this is the mixed one from the other.

Okay. Okay. Yeah, we'll get rid of that one.

Board of directors. Yes, sure.

Okay, well, any other questions?

Any live questions from the room? Okay, wait, My question is, you talk about value. I think it's very important. Can you please explain to us how do we choose the right value for the organization? There's so many choices. Yeah. Okay, so I think my rules of thumb are I try to. Okay, so just some simple things. I try to aim for about four to five, which is just like, remember that everybody has about seven slots, right? So like four to five is like well within the range of. You can actually rattle them off pretty quickly. Second thing is identify things that people are already saying or that are already coming up as ways of behaving and use that to sort of distill down the right message. Third thing is try to think about what are you trying to affect for the change and how can you best express that. And again, that oftentimes is helpful in the lens of there might already be some teams that have those kinds of behaviors and those values present. They just might not be articulating them well. So it becomes a little bit of a game of just trying to basically find that type of behavior or find a team that's doing the thing you want and then say, like, okay, why are you doing it like this? And you find out they have some process and you can kind of start to think about how to distill it down. The last thing, honestly, is just like doing a fair amount of workshopping on it. So in my case, when I come up with them, I'll do like early draft sharing with my VPs and ask them to give it a read. And we'll do some. Appoint some directors and just kind of like start to expand the envelope of who actually hears the stuff before it gets up, gets to be broadcast. And you start getting really interesting, valuable feedback from that standpoint as well. And I think the last thing is game of making sure that whatever you land, even if you end up coming up with initially fewer values, it's always easier to add than to remove. And also you don't want to change them too rapidly. Otherwise people just don't know which of the many toolkits of values they should be using at any given time. The last thing I'll say is that I didn't mention this in this talk, but it's also valuable to pun intended, to be able to periodically roll values off. Because what ends up happening is some things that you do. It's like kind of three classes, right? There are values that you don't have to express. We don't embezzle stuff like that. Pretty obvious. We behave with integrity. If you find yourself doing that, probably switch businesses. Like, there's something really wrong with the culture there. The second thing is that there's going to be a set of values at any given time have become so implicit, you don't have to really celebrate, like highlight them anymore. There's also going to be a set that just aren't no longer valid. So like, as an example, for us, we had one way back in the day when we were a lot smaller, that was something like everyone does the dishes. And the idea was, you know, it's like you want to have everybody kind of pick up and the trash seems like legitimately, like as office mates and as software engineers, like, don't leave a mess for other people as you scale up. Turns out, you need somebody to do the dishes. Like, it's just kind of one of those things. And so you don't have to necessarily make that the same kind of value. Same with qa. So you end up hiring a QA vendor and that helps with some of the dishes that you create in the software side. And then the last bit is like, you know, continuity from one set to the next. So if you've got a couple of keep a couple and then add a couple invariants in and just kind of, you know, do some shuffling. That was a lot. But hopefully that was like a makes me send. You bet.

All right. Just a reminder, when you're in slido, you have to pick stage A just to make sure that those questions are, how about over here, do you want to stand up and ask your question? So I'm just going to repeat the question so everybody can hear. Process leads to culture. How do you avoid a proliferation of process and having too many processes?

So I would say, simple analogy would be this is similar to the problem of the too many frameworks problem of, you know, you have a code base and you have a bunch of frameworks running around. Sometimes you have to re architect. And so for certain, so, so for varying size of company, that can either be done as like, okay, like the leadership team or your equivalent goes through and says, like, we have like three different ways to do this very simple thing, which is the right one. Another option might be to say like, you know, there has to be an upfront question of like, how much do we care? Like, one thing that's come up for us for a very long time, for anyone in the room who's at Reddit, is we don't have an agreement on how big we should size tickets. We don't have a uniform sizing across all of the teams, but each team is consistent internally. And so it's kind of like a do you care? As long as the team knows what they're sizing and they can do their sprint planning, it doesn't really matter if we can have an agreeable size, but we definitely have more guidelines on what constitutes an epic versus a task kind of thing. And the third thing I would add is at some point you do start to back to the dishes comment. You start to need to have somebody whose job it is to start to really help wrangle these processes. And I'm thinking of TPMS here. So in our case, we started hiring TPMS when we were kind of at the 300ish size, like, you know, just a couple people, like smaller than our product team, mostly targeting larger programs or organizational wide stuff is the goal as opposed to being specific, P being program as opposed to project. And the idea is like their goal is to start to really be more of the kind of process wonks to help out and make sure that we're not doing something stupid globally.

All right, I think we have time for one more question. Maybe here back at the back, if we can hear you, I hope.

Yeah, I can speak that. Great talk. I love the focus on the lightweight engineering. I mean and I love the way you do a parallel between the Reddit communities and the engineering community internally. Have you ever tried using Reddit internally? No, It's a Great question. I didn't mean to interrupt, like I was like. It's funny because one of the things we've learned, having to do this internally, we do have a couple of internal employee only communities. We have a one that's basically for all employees. And what we've learned from this is that there is critical threshold size for communities to work on Reddit, in part because the model is very much async. And so it's like you need to have a certain. The lurker to poster ratio on Reddit is always pretty high. It's always like 10 to 100 to 1. And so if you want to walk into a place and not have it be an empty room, you need to have enough people who are kind of subscribed and active to really kind of create that flow flywheel. And so in our case, we found that even internally it was hard to get a community off the ground until we hit about 1,000 employees. Just because at that point you start having enough people who are posting and being a little chatty that it just kind of starts to take off. I laughed also because super secret, I'm launching tomorrow internal to our product and tech teams community with this exact idea in mind, which is like, hey, wouldn't it be cool if the team that actually literally builds the product had to spend a bunch of time dogfooding our own product and, and also probably posting a bunch of crap and being funny together and just enjoying some camaraderie. So, yeah, totally awesome.

Okay, one last question. I'm going to ask you. What do you enjoy so much that it makes you lose track of time?

Okay, honestly, the answer is software engineering, but I don't do that anymore. So whenever I hey, do you like your own product? I'm a meta meta meta engineer at this point, so I, I enjoy still to this day, sitting down and raging at a computer. I mean, that's actually very fun and cathartic to the point where it's a lot harder to do because I know I have a family and two kids and there's always some distraction at home and so getting a chance to have an hour of peace where I can just sit and write. It doesn't happen as well.

But what kinds of things do you write?

I've gone straight, so I kind of went back to my roots and more on the physics side. So I've actually been playing around with small microcontrollers and Arduinos just because they're simple. And I'll be honest, I started off my career doing full stack work. I really hate CSS and I just never have been able to get into it. And the same thing with I can kind of tolerate JavaScript at this point in my life, but I was a Python engineer when I was back in the day, so I think at this point node's grown on me. I'll be honest, and it's not terrible, but I do like just the purity of it is you and the fricking RAM and you can just code what you want.

Awesome. Well, thank you so much. I appreciate you coming out. Thanks to our crowd.