Chris Slowe, CTO of Reddit, on Leading During A Period Of Hypergrowth

The origination of the idea of what we want to do, all of this comes from our personal experience. So my two co founders and I, we were, we are engineers, so we are French, as you can hear my accents. And when we transitioned here, we had the immense chance to leave the Silicon Valley dream. So we have been accepted to Y Combinator. We accepted, we received some money from Y Combinator and that was amazing for a couple of French people. Graduated from college six months in, and we received like $250,000. And in France, with 250,000 doll, live for 18 months with 12 people. So from one day to another, we became engineering managers. Without even noticing it, we became leaders ourselves. And we went from a stage where we were all engineers at building things to a stage where we were responsible of leading people who were building things. And we thought it was extremely difficult to go from one stage to the next. What made you go to, what made you go from one stage to the next are not going to be the same. Skills are what going to make you successful for the next stage. And what happened is that in the world you had books, you had videos, you had trainings, coaches, but nothing really that we thought was really impactful and meaningful and efficient to help us to become good leaders. So we decided to build plato. And at plato, we are now on a mission to help every single engineer in the world who wants to become a good leader to become a good leader. And the way we're doing this is thanks to a community, thanks to experience sharing, thanks to a couple of hundreds of great mentors in the community who dedicate their time every single week to help out and to because just they believe on our mission to train the next generation of engineering leaders. And today I'm really happy to welcome Chris, who joined the community recently. And I would like also to introduce you to Woland and Henry. So before going and doing a broader introduction of Chris, I will introduce Willem and Henry. So, Willem, you have been a mentor for what, more than a year, Two years maybe already now?

Since the very beginning, yeah.

And every single week you have been helping out other engineering leaders. And you've been here, you've been doing that during your free time because you believe on our mission. Can you tell us in one minute a bit about yourself?

Sure, yeah. Thanks. Excited to be here today, excited for this discussion. So I came to San Francisco with a startup dream as well. Worked at a scheduling company called Book Fresh, where I was CTO that was later acquired by Square, where I've been for the past five Years kind of building engineering teams. And one of the reasons why I'm so passionate about the PLATO community is there is not a great path for how to learn to be a good engineering manager. There's a lot of good books.

Right.

But you know, practical experiences is sometimes hard won and hard learned and I made a lot of mistakes and that's why I'm kind of part of the community today.

Share those.

Great. So you are now a director of engineering at Square.

Sorry, Director of Engineering at Square. Yes.

And your company have been bought by Square or two years ago.

Five years ago.

Five years ago. Cool.

Thank you for doing this today for sure. And Henry. So Henry, you are a senior engineering manager at Zendesk and you joined the company in 2011. So it was in the really early days, right. You were less than 100 people at Zendesk and you went from all the way from software engineer to senior engineering managers now. So you have a different story than William, but maybe the same pain point. Can you tell us a bit more why you are a mentor in plato?

Yeah, I was IC at Zendesk first and I really enjoyed problem solving. And the more I grew in that path, I realized if I want to build bigger things, solve bigger problems, I need to work with people. And so the opportunity for management came across my plate. And that was where I figured, okay, I'm going to figure out this new space and learn about what it is like to be a manager. And I've always tried to apply my problem solving, problem solving methodology. And I realized that as much as I can come up with creative ideas myself, it actually is much more impactful to do with other people. So I got more into mentorship and trying different ideas to see how I could help people grow. And when PLATO came across my plate, I realized, oh, I can totally scale this whole exercise in my mind. Like how can I, with other managers in similar positions positions, brainstorm things together, come up with solutions, and then just build more experiential knowledge through experimentation. So that's a lot of what I enjoy about being on plato.

Cool. Thank you for doing this.

And now I will introduce Chris. So Chris, you joined the community only recently and thank you so much for sharing your experience. We have only a limited time today, but we will, in this limited time, try to learn as much as possible from you. Can you tell us a bit about yourself and then we'll kick off the conversation?

Sure. So I'm right now CTO at Reddit. I was also the first employee back in the day, so I Started at Reddit three months in the startup, moved to San Francisco in early 07 when we got originally acquired by Kanye. Cast worked through it for five years originally, at which point the team was never more than about four, which is a, you know, definitely skeleton crew I think. Left at a startup for five years. Hipmunk, you know, kind of Hipmunk was the, was the time where we learned kind of how to actually build a company. We had a successful product but not much of a company around it. This was a successful company and then came back to Reddit in early 16 when a whole bunch of we OGs came back. So Steve Huffman, our CEO came back in 15 and I came back early 16 originally doing IC work and then gradually had teams thrown at me over the course of a couple of years.

All right, let's get started. So again thank you everyone to be here today and hopefully we learn a lot. Hopefully yeah, in such a way things. And so we are going to do those community AMAs regularly so that we can learn as much as possible from the best engineering leaders we know in the community. So if you want to Hear more about Plato platohq.com we'd be happy to tell you more. So let's get things started.

So.

In the Zoom interface in the bottom you are able to ask your own question and we are going to divide the time in two. The first half Willem and Henry are going to learn as much as possible from Chris and during the second half we are going to take questions from you and hopefully we'll answer the most of them. All right, let's get started. Cool.

Well probably just kick it off and tell me a little bit more about yourself and kind of your role at Reddit. You mentioned kind of CTO and what does that kind of involve?

Sure. So currently actually I'm actually dual wielding CTO vpng which means I get to wear both hats poorly I think is the joke. So it's actually a lot of fun. I think CTO role at Reddit is primarily kind of a chief architect role. I have an office as CTO Octo group and the tagline for that group, I usually refer to it as extreme tactics and extreme strategy. So either long term planning or drop in and fix a thing and move on, which is a lot of fun. The VPN chaff we have right now about eight engineering groups, each of the directors, about 170 engineers in total. So pretty flushed out org, which is delightful considering when I restarted in 16 there were, I want to say 40 tops, maybe a little less than that. We've kind of gone through a number of reorgs to go from the original startup model, which I think is layer kicks, which is a blob, into did the standard front and back end team. And then we're doing the kind of candles on the cake model right now, which has been exciting to put in place and actually kind of learn how to scale up past Dunbar's number. I think it's been the fun part. Two years. Exceeding Dunbar is where the stress really comes in. Yeah.

Dunbar's number Is that 150 connection?

About 150 connection, yes. That's the number the two versions of it are. It's like you can keep track of about the individual stories of about 50 people and you can keep track of about 150 people's names. So you get past that point and all of a sudden you can't restore. Rely on trust Network to make things work. Totally.

How's that kind of evolution been from kind of leadership perspective, who you leaned on to kind of help get some of that accomplished?

Definitely. In this case, hiring seasoned, experienced directors helps a lot. I think there's a bunch of very well defined known failure modes, and one of them is this one, which is that trust kind of goes out the window at some point. And it's not even that. It's not even that. We try to hire basically skilled, humble people and I think we do a very good job at it, but there's no technology that will get an engineer to stand up and walk 50ft and go talk to somebody.

Even slack.

Oh, man, Slack. Yeah, Slack will. It's funny because I think the older I get, the more I appreciate that in person. There's so much more nuance in conversation than there is over text. I think text. There's always this potential to apply whatever filter you have mentally for the person on what they're writing. And I've actually. I know engineers, especially Reddit, tend to be a somewhat snarky crowd and there's a subset of people who I would say their sarcasm is indistinguishable from their wit, which in text form can be a real disaster. Yep. Cool.

We're going to go back and forth.

Questions.

So you mentioned Dunbar's number and hiring seasoned directors. How do you balance in a rapid environment, mentoring people and developing them into roles versus being outside tower?

This has been a tricky one. I think what we've done is with a couple of seasoned directors at least helps with the mentorship of managers. Having somebody who actually knows not Only how to manage, but how to manage managers is critical. And the next level up is like being able to turn bad managers and good managers. So we tried very hard to internally promote people to management roles when they actually want to do it. And what we've done is to make sure that our career ladder actually is pretty evenly split. To be ICTrack has parallels in the management track. And so all the rungs line up, all the confidence are the same. And so we want to make sure that people want to go and manage it not because they think it's some new shiny thing they get, but because they actually want to manage people. And explaining to people that's actually a very different set of skills than like what makes you a good IC is always the fun part. And I usually say that for us, leadership and management are related but kind of independent. I think that anyone who gets to about staff engineer, for us, you have to kind of be a leader. You can't just be a lone soldier, drill down and code or hide in the corner and write. I mean you get to sufficiently senior for a long time for that. But I think for staff and above, it's really about your ability to influence others and get them to not necessarily work on your stuff, but to have that discussion and to foster growth and mentor. I think for especially managing directors, that's definitely part of the job. I think it's in the title engineering manager, manage engineers and making sure that for managers there's a path to encourage, I think senior ICs to mentor junior ICs. I think to a large extent the whole process is really about mentorship. You just. We would love. I mostly want to have hire a bunch of, you know, IC1s fresh out of school and there's those moments in your career where you find out like a couple years later there's this senior person and you've basically watched their entire career arc. I think that's the best part of being a teacher. Great.

That's really awesome to hear that you've kind of structured the kind of engineering ladder in those two tracks. You do something similar. At Square. We've kind of found that the incentives align a lot better when they're kind of completely equal all the way up and you kind of go into management because that's something that you feel passionate about rather than something that's a promotion into some sort of compensation band.

Yeah, I usually make a joke that, you know, whenever someone switches to manager, you know, I just send an email saying, you know, you can pick up your mop on Tuesday.

That's awesome.

So you mentioned we're talking about scale and hyper growth. Could you put that into some context for everyone?

Oh sure. So I think for us depends on which side. So on the technical side I would say one of the delightful and terrifying things about Reddit is it's always grown. In fact, the way we describe it now is like Reddit has grown despite our best efforts. And so back in the early days we were doubling every three months, which meant that we all got a chance to learn about how to scale up a website live before they were getting our runbooks on how to do it. I very fondly remember some of the original early discoveries. I'm like we use postgres even to this day. And the first time we opened up the postgres config about six months in and discovered that it was tuned to run on a 486 with 8 gigs of RAM. One of those moments like, oh, we should learn about how this file works. I think on the human side, starting in 2016 we had total company was about was under 100 people, 90 people. And so we've basically had two straight years of doubling each year, which has been exciting and terrifying in the same kind of way in that, you know, the learnings have been how to kind of keep the wheels on, how to build a good culture, how to keep good culture. You know, there are benefits and detriments to diluting with new talents. I mean you get the advantage of kind of like new people who are bright and bushy tailed but at the same time making sure to take the time to like, you know, it sounds severe but like culturally indoctrinate, like make sure that they're thinking in the same terms and that they have secure values. I think I've gotten a lot. I think if you talked to me five years ago before I had to do this or had to see it, it's like values. It's like a bunch of corporate nonsense. No, actually values. Most critical thing you can do is make sure that everyone knows who they are and can actually recite them because it helps set the tone of how people behave. And like one of our core ones has been around for a while. We kind of tweak the values as they become part of the culture, trying to highlight the thing that we need to work on next. I remember hearing at one point that you can tell what a company's bad at by looking at what posters they have around the office. Motivational ones in our case, one's been around for a Very long time. It's also kind of core to the site is remember the human, which means both, again, like attach the fact that the person on the other side of the screen, whether it's a co worker or somebody on Reddit, like they're actually working towards some good intent. Totally.

Yeah.

I've always hated the word user. Right. Kind of like a very. Kind of dark. Kind of like almost like an addiction. Just taste. Just taste or clicks or page views. Right. It's like there's people actually using these products. That's really awesome. How have you kind of started to build those values? Is that like group brainstorming or kind of like tactically, how would someone kind of go about setting up a clear set of values?

Do pretty regular. We usually do it at the exact level. I think a lot of values end up being the result of Steve, our CEO, kind of kneeling on it for a while. To some extent, the job of a CEO has the most scope of any person in the company and therefore also can have the least depth. And so it's really about trying to define the most kind of gentle controls you can apply. So in this case, setting the underlying tone of the culture is important. And so we generally have like probably about every half year or so we do like an exact brainstorming session of kind of discussing what we should do to pick the values. Which ones are actually kind of already so easy to do now that we don't have to highlight them and then kind of keep iterating them. And the other ones in there that we keep that not because we think we need work on them, because remember the human, it's really important for Reddit, that should be a thing everyone's thinking about at all times. Totally awesome.

It sounds like in that case, execs are bringing in a body of knowledge or feedback that they have. And in your experience, what's been effective in terms of building that feedback from.

Your team or peers? Oh, feedback is always a constant concern. In fact, I think this is something that has been, I think, hardest for us as we've grown to the size. Because with feedback there is this need for trust at the same time. Right. Because you need to. It's all about attribution of intent to some extent. Like if you're going to get somebody else feedback, you haven't done very well. Really difficult because now it's like you have to. If you. Critical feedback. I think for us it's been about ultimately transparency. We try to make when we have large script discussions, get it all documented, get Everyone get their feedback into the doc so everyone can actually read it has been really critical to making sure that that feedback is heard and acted on. It's also, you know, I think verbal feedback is great. Written feedback is actually even better because you really have to be deliberate when you put your words to text. Like, you can say a lot of stuff out loud and then the other person's going to pick and choose kind of what bits they want to hear, to write it down and have somebody read it. That works really well to make sure that your message is getting across. And I think it also encourages the person who's delivering it to kind of like, wordsmith it and think about what the restraints say. It also prevents the. I won't curse, but a craft sandwich, that method of, like, you're doing really great, but you need some work, but I still think you're doing awesome. And, you know, the person picks out the bread on either side, doesn't actually catch the feedback from the middle. It's a lot harder to hide that and get rid of. And I think in terms of, you know, But I'd say for general, generally, for us, it's a struggle. And it's like, requires constant work to keep that culture going, if only because it's just very easy to settle into a pattern where it's like, oh, you know, just the dorker, everything's fine, they'll fix that.

What kind of, kind of curious, like, feedback and kind of using docs is kind of one great engineering ritual. What are some other, like, engineering rituals that you've seen change, grow, add, remove as kind of the company's gone.

Well, so I'll tell a story on that one. So when I first, when one of the fun things about both of my startups had the same set of architects, so it was a lot of kind of, you know, me and Steve and one of the early Red employees, David King, also came over at Monk at one point. And so we all kind of had the same, like, methods for building both stacks. The difference being that one of them was five years later than the other one. So we had come up with a better set of reflexes. One of the things we discovered in those five years was the power of unit tests. And so coming back to Reddit in early 16, it was a bit like coming back to an alternate reality where they'd chosen some different parts of the tech tree. And so it came back and I wrote my first patch. Have not looked at code base in years. And there's parts of it that hadn't really changed and was a whole lot of it still has my blame on it. Which is terrifying because I remember that guy. And I was like, okay, great, let me just write the unit test. And I was like, oh man, we don't have any unit tests. And so trying to build out like basically in 16 we started building a real deep CI suite. We're moving from a monolith to services. There's an opportunity to kind of like clean up and rebuild along the way. But the value of testing and, you know, culturally shifting to there's a set of engineers who are sufficiently competent, they don't need to write unit tests. That is a vanishingly small number of people. And if anything, the utility of unit tests as a means for making sure that you don't repeat mistakes. Most of the utility unit tests actually comes up the first time turns green. Preventing regressions is another big one. And making sure that the corpus is. I think we're still pretty terrible at documentation. I've seen very few companies also that are good at that just because it's that kind of balance of, you know, you take your debt in different ways. And if you're trying to move fast, usually documentation is the thing that falls. Fortunately, with growth and with new people, that tends to somewhat fix itself in that there's a set of people who just come along, make sure the person is long. Next. Awesome.

Yeah. Large scale refactors and documentation is almost out of date the second you write it. But you know, it's definitely useful for runbooks and kind of operational stuff is almost impossible to scale without.

I think also runbooks are underutilized in other parts of the parts of the stack as well. Having had a background in ops, nothing beats a good runbook. That's true for. It's just documenting a process. You can do that in any sort of situation. I think it's. In fact, I often am the guy in the room who's trying to apply engineering principles to other situations, trying to drive things like, we just had a process mistake or some sort of internal management mistake. We should post more of this. We should actually do what we do as engineers and figure out how we make sure that the next version is better. This one's broken. Let us all bask in the brokenness of this thing that we did and now make sure that we don't do it again.

Totally.

Yeah.

Postmortem culture, how's that been kind of solidified within the engineering teams.

So it mostly came from the back end up where the nature of having a Very understaffed team for so long is that we have a really solid tenured back end team who are basically battle tested and know their stuff and have seen it all. And so, you know, when you're, when you're, when you're defending against onslaughts of traffic, coming up with good runbooks and coming up with good postmortem processes that are blameless is very important. So we run, we were in the blameless post mortem methods, which is basically, you know, timeline of what happened, what did you expect to happen, how would you remediate it and what are next steps? Right. And so the entire intent there is not to blame whoever caused the problem, but to make sure that the next problem doesn't happen again. Because even if the human in the loop who caused the problem, there's probably some underlying thing that kind of tips.

It off, like confusing or not clear.

It's confusing. Or you know, even down to maybe the extreme case is like, maybe we shouldn't allow that kind of access without some oversight. And I think even for things that I almost would like to, one of the things that I've struggled with in my career is trying to figure out how do you respectfully highlight to junior engineers when they've actually followed up poorly? And in a way that's like, hey, congratulations, you just learned a whole bunch. The site's down, good job, let's not do that again. Here's your golden trophy of something. And I never actually committed to it because I always feel like it's like, it feels like it could be a hazing ritual if we do it wrong. But there's some value in the. It's like the. There's an old story about a chemical engineer who blew up the factory and expects to be fired on the spot. And the boss comes in and says, we've just put a lot of investment in your career. See to it your next mistake, not like that one. And I think it's kind of how I feel like software engineering is much more like that. It's much more potential for any one person to kind of cause the whole bridge to collapse. And learning from that is the only way you can progress.

Totally. It's the only way that that investment's worth it. Right, exactly.

You want people to be, you want them to learn how to learn exactly their failure. And if we don't give them enough room, then they kind of get stifled in that you mentioned, like with postmortem culture, I think one part that's interesting is like, how do you empower Teams to identify the right thing and then go to it. Yeah, I think that happens at the scale within the team. But as you look at bigger and bigger teams, how do you make sure that people are in their minds understanding what's the right thing to do?

I mean, I think it comes back to, I think it's very closely related to execution priority and figuring out how do you make sure that you're balancing tech daddy tasks and quality tasks like engineering tasks against product roadmap. And finding that balance for us comes down to engineering leadership, Engineering management as part of the process of dispatching genetic tickets. Right. You kind of want to have a guy. I want to encourage engineers to go and fix things that are broken when they find them, but also to think critically of if there's something else that has an urgent deadline. We might be able to hold off on that for a week or two. So striking that Merck balance has been tricky. I try to have a rule of thumb about kind of 73 in terms of work on the roadmap, but leave a buffer about 30% variable by team. For teams that are more focused on support or internal customers, usually there's a support load that ends up eating pretty deeply into that 70%. I think it's a bit more like 50% is all the stuff that appears during the quarter because you're downstream from some other team that didn't quite plan correctly, trying to make that as thin as possible. And then 30% for new stuff and 30% for tech. But it's, you know, we, you know, we do kind of agile practices as everyone does. I consider myself though kind of an agile unitarian. I believe in the religion, but I don't have a particular version that I like best. As long as run what you want, as long as you kind of have some notion of sprints and some notions of like back pressure.

Kind of curious like how working with product has changed. So you mentioned kind of some of the rules of thumb is like a third on tech dev, third on new feature work, maybe third on visionary, where the hockey puck is going, so to speak. How's that relationship changed as teams have scaled? Have you kind of decomposed or centralized or do you have still unitary orgs of product design engineering?

Yeah. So what we have is we moved into more of like a pillar based model where we have a bunch of teams that are focused around, we call it foundation engineering, which is the, you know, it's where all the platform E teams live, where data lives, there's some product outlet, but primarily that group's customer is internal. And then we have our consumer teams which are in charge of things like the core product experience, all of the product services growth like that part of the stack. And then separately we have our monetization team and then a last team for us which is we prefer to safety, which covers things like Anti Abuse Trust and safety security. Internally there's an engineering team that we call Anti Evil which absorbs all that or a lot of that. And so for organizing on the product side, we've got the product set up kind of parallels the engineering setup. So what we try to do is have triads for each one of the levels on the ladder. Each team generally has an am, PM and a designer if appropriate. The platform team is less so. There's usually a couple PMs floating around who are generally pretty heavily overloaded because they're kind of brightening that border between PM and tpm, which is tough to navigate totally, but definitely trying to keep that kind of match up. Like making sure there is a triad and making sure that you have the roadmap isn't owned by any one person in that group. The roadmap is the aggregation of what's the product roadmap, what's the entry map, what's the design roadmap and how do we intermesh it? And I think in the past trying to find that balance has been tricky because we have had a whole bunch of new initiatives to undertake. We did a redesign last year and to some extent a redesign by its very nature is a giant new product. And so in that case, I think in terms of resources, we put a lot of resources into that and now we're actually probably skewed a little more towards tech debt cleanup. Because anytime you try to target a deadline with a giant pile of code, you're going to have a hangover of tech debt. Side effect of that. But it's been actually kind of fun to clean up. And the important thing is as long as it's better today than it was yesterday by some objective metric, I think you're good shape. Cool.

That's a great way to look at kind of when to do tech debt. You know, as long as you leave the place your room a little bit.

Better than you found it, I'm always worried that there's no light at the end of the tunnel.

Oh, there isn't. That's cool. That was always more dead. I think if anything's like, I know, I don't know what your experience has been with like to do lists. My experience is there's a hot set at the top that's constantly churning it out and then there's the increasingly long backlog. And I think that backlog is always there. I think it's kind of healthy and we prioritize. We have P0 is critical. We do go all the way down. Like P3. P3 for me is like, we will never do this. It's never going to happen. We should earmark the fact that it exists the thing but anything. It's really just about the. If you keep rediscovering the same bug, bump the priority up a little bit, making sure that part and queue makes sense. But yeah, I think it's the process is really the point of it.

Just.

To switch gears a bit.

Something that's like burning in the back of my mind is how did you make the transition and grow to become the successful leader that you are?

I think, well, thank you for thinking me a successful leader. I think that the. I think it. For me it was a very kind of just kind of organic transition which I think is kind of a pretty typical path for people. In fact, I feel like now that I'm involved heavily in like interviewing managers and having discussed their process, everyone has a very similar or 90% of people have a very similar track which is like I was an IC and I was having a good time and then I became like tech lead or I had this like switched to having a couple people who kind of looked up to me either formally or informally or equivalently. There was like a hole in the organ. It's like, hey, you managed for a while great, so see later. And then you kind of like you learn by doing. And it's, you know, if anything I think that that approach is why we care so much about we. We have like an internal like pre manager cohort, people who are interested in making the shift at some point and we try to basically start priming them with like cement with some mentorship and some like external talks and like just kind of get them ready to go. Because for me it was really the like, okay, let's have a one on one. So how are you doing? And then learning kind of how to run a one on one and you know, not do the technique of. There's an old Simpsons episode where Homer becomes a manager at some like it's getting really far out of the field. I'm going to go for it. So he becomes a manager at what amounts to being a Bond villains like evil lair who's in this episode and he has these Engineers reporting to him for the first time. And he kind of walks in, he's like, so guys, can. You guys can work harder? Sure thing, boss. And just start typing faster. And I feel like that's kind of like the first method you think of for management. It's like, oh, yeah, I'm just going to tell people to look better. And, you know, I think engineers also tend to be. I mean, I'm micromanaging by nature. And so I think some of that was beaten out of me. I went to grad school as well, did a little bit of, like, the academic mentorship side. Had a little bit of that kind of beaten out of me early on. I think that's really the process for me has been like learning by doing and then also learning by. You know, I have a mentor. I also have a whole bunch of friends who've gone through the same process with the same learning from each other. It's really important too. Right, right.

It's one of the reasons why the PLATO community is so great.

Yeah, exactly. No, I mean, that's definitely a big thing. I think you have to. There has to be either a learn by doing or learned by other people's doing with management.

Another thing is, like you mentioned, kind of a safe space for people to try out management. Right. And I think having levels and having that kind of has an expectation that it's not for everybody.

Right.

Some people just don't like it. And being able to go back to being an IC without being scarred or anything with an organization is really important.

Yeah. We have an. Internally. We're big enough now to have a talent development team on our people and culture team. And they provide the initial, you know, outlet for a third party in the room or a third party available. So, you know, a month in, they can check in on both the manager and the manageees and see, like, is this working? Where are the gaps? You know, do we need to make any changes and have that available as an audit? And I think it's very important also to frame it as like a. We're trying this out. If it doesn't work out, that's not a failure. That just means you're. Maybe this isn't the time for your manager. Maybe management isn't what you thought it was. I mean, I for one, like writing code, so. Me too.

It gets harder and harder.

It really does get bigger.

But yeah, you mentioned a big rewrite previously. Has there been like. As a product rewrite, have there been, like, technology transitions? How do you kind of manage that while Scaling from an investment perspective, especially with like your relationships with product and design and other stakeholders.

Yeah, I think that the redesign that we did last year was probably our most drastic rewrite to date. I mean we did a redesign 10 years ago which was a very different version of that. No product involved in Etherics, we didn't have any product team. This version was very much driven on trying to make. There's two sides of it. There's a technology side which is take an ancient stack and move to something that's modern, that can actually be quickly iterated and that one is easily sold across the org because it's really about when you have the promise of increased velocity down the road for this investment. And of course at that point when you're thinking about doing a redesign, generally everyone already hates the stack you're on or at least has enough pent up energy to want to build a new one. Of course, being cognizant of the second system syndrome is a real thing. It's very easy to fall in that rabbit hole of like, well, while we're in here, let's just take care of these other 20 things that we want to do. So for us, the, the critical thing was to make sure that we did set clear boundaries on what was going to change. One thing that we didn't change in this last year was the API layer. And so instead what we did was we built out a shim that does a lot of API translations has some potential. Whenever you create a new writing layer, you always create potential for the new model of Surface. But that helped also with Velocity on the it was written in Node. In that case, our main stack is actually Python and has been the beginning, or almost the beginning. The actual first version of Red was in Lisp for the first six or eight months. But adding that shim, allowing for server side rendering and client side rendering of the same stack, letting our actual prod end do their job and not have to worry about fiddling with Python when they're not as familiar was very valuable. The flip side is that there's a slightly different mentality of developing on the client versus on the server especially. I think there's a, you know, if I'm going to get on my rocking chair being like an old man. A lot of modern frameworks are designed to hide the fact that there's a wire there and that there's like a whole pile of technology that's making the system work. And it's very easy to make a very kind of heavy, bloated stack just by not paying attention the multi megabyte JS download because you have to deal with chunking or you haven't double chunk. So that was a major shift I think in that process. We passed into React as well. We actually decided to consolidate our own TypeScript for the client, which actually means we have a more strongly typed client than we do server, which is fun. And right now we're doing an equivalent start of React in the backend. And so this is a combination of demonolithing as is the style of the time, switching to researching the containers as well in the process thinking about services and then thinking about our actual API and the current likely candidates in GraphQL and making sure that works in a way that's same is always fun.

How do you decide on some technologies and how you either enable your teams to do it or who decides?

I think that one of my learnings over the years has been almost it doesn't always matter what you choose, as long as you choose only one thing. There's a tendency to always have the multiple competing standards and there's that initial decision point where you have to pick one and because you have, you know, generally those are led by fairly senior engineers who kind of know what they're talking about and it becomes like a either religious thing or just like a I worked in the past or I have some experience in it and I think that, you know, with some constraints, like if I didn't, I'm going to alienate part of our community here. As long as you don't tell me you want to write the whole thing in Erlang, which is by the way a great language. But it's really hard to hire engineers for Erlang and we've never used Erlang before. So why did you decide to use Erlang Again? I think it's actually picking one is a critical thing for TypeScript in this case. I remember the process was we had a senior engineer who just decided to try it and fortunately it was very easy to get interrupt working with our existing code and it was working and he just by sheer force of will or really just because it's working, other engineers started doing it and then we're like oh, this is kind of neat. Are the tools. Yeah, I think for GraphQL is a little more deliberate and you know we generally do for big technology decisions is wrap a design doc, have a good discussion, have an architectural review in a way just to make sure that you've at least thought about trade offs. Like you're not just going to like new Shiny or like you just pick this thing because it was the first thing you got in a Google results. Right. But because there's a, you know, and I think for that discussion it's always like, is there a history of this thing being used? Is this like actively used now? You know, we don't want to. We don't want to. Like, you know, at this point I would never use Hive for anything because like it's a dying technology effectively. Yeah, probably true about Spark as well. But like, you know, we're using airflow now for our etls and it has a certain amount of new shiny, but also it seems like very well developed and very well.

Five.

Yep.

That's awesome. Yeah. Also like security implications and kind of understand as you scale it becomes more.

How many stars does it have on GitHub? Four forks. How many forks? Yeah. When was the last commit? Does it have unit tests? Is it documented?

Yes. Yeah. Or if it's just one superstar maintainer and you get like bus factor of one.

It's also a challenge, I think.

So grassroots decisions versus top down decisions or like what's the right balance? What sticks?

I mean, I think so. One of the nice and scary things about being CTO is I always have to make sure to hire people that are better at their job than I am. Right. And so you have to rely on people's ability to make decisions. And so I prefer to provide guidelines and let people make the decision. And I can help to support it or I can help to test it. But at the end of the day, there has to be some internal support ready for it. And I think when it comes to even kind of going back more historically, when I was more of a lead, making sure people feel heard and making sure to have that discussion and making sure everyone gets their repairs, their grievances down one place. I actually have most of my meetings. I have a standing item on the agenda I call the airing of grievances, which is just making sure everyone knows, is it time to like, okay, the door shuts. This is a safe space for now. Let's all argue and then we go outside and we look like we're a unified front. I think that's very important. I think that's true for management decisions as well as for process decisions as well as for engineering decisions. You know, it's kind of like the disagreeing commit being an important step in the process.

Yes.

Okay, cool.

Awesome.

Thank you for all the questions.

Thank you, guys. So we are going to go to.

The second part and we are going to crowdsource question from the audience. So thank you, Henry. Thank you all for your questions. And I'm welcoming now Sid, who is going to moderate and ask the questions. So, Sid, welcome.

All right, thank you.

All right.

And you can still ask your questions. Sid is going to take them. So have a seat, Sid.

All right. Thank you so much for the question, Henry. We're going to be taking questions from the audience now. If you haven't thrown it into the Q and A box down at the bottom of the screen, do so right now. We have Leanne helping us moderate the question. While you're doing that, I do want to say a couple of things. We have a couple of friends and partners who helped us promote this webinar with Chris today. The first one is Codementor and have a product called CodeMentorx which helps you scale your engineering team with remote developers so that you can bridge skills gaps that you may have right now in your current team with the remote developers. Thank you so much, Codementor X for helping us with the promotion. Second partner is hired. Hired is a marketplace that matches your company with tech talent and tech talent with innovative companies around the world. So they have intelligent job matching to help you again with hiring people internally into your teams. All right, so let's get started with some of the questions. I have pulled out a few questions already, and as we answer them, maybe you could just mark them off as answered live on the screen there. So first up, Chris, you talked about how you level engineers and help them level up. Did you develop these playbooks or did you borrow them from friends and peers and mentors?

I think it was, I think for leveling up, it's been group effort across our kind of leadership team and our management team, because it really comes from. From you can do it the hard way and bring the wheel or you can find people who've done it before and learn from them. In this case, it's been definitely leaning on people who've done it before and building those playbooks from that. Okay.

And any lessons learned or best practices rules of thumbs that you have from.

This, I think the value of one and ones definitely comes from it. I think making sure that the one on one has a structure and that. I'm going to call for a second. Sorry, excuse me. Making sure that there is a path towards having the career advancement discussion on a regular basis. Not everyone thinks about their career or at least doesn't say they are. And so if you don't have that outlet to actually talk about your career it can be very stressful to the actual Sean.

Right.

Okay. Yeah.

Our next question actually for Willem, I guess we could answer this first.

Sure.

Is there was a discussion about hiring great directors and so someone was wondering what is the difference between a director and a manager and how do you cultivate that jump?

Yeah, that's a great question. So we talk about playbooks and kind of progressions. I think there's even less of a playbook for kind of going between kind of manager and managing managers. I think the biggest struggle for me is when you're a line manager. I actually think a line manager is almost a more difficult job because you're balancing both kind of hands on technical contribution to some degree, coaching up kind of individual engineers, hiring. As you kind of jump to the director level, it's a lot more about managing expectations across up in the down, being very clear and principled about how people make decisions. Right. Because you can't or shouldn't be making all the decisions yourself. And basically, Chris, you mentioned transparency being as transparent as possible. We use a similar tactic of airing of grievances, really creating the space for people to talk together. A lot of times they say leaders eat last, so you should be the last person to talk at meetings. One thing to remember is that your voice holds such a loud weight whenever you say something. Right. So just being very careful when you weigh in because your opinions can meaningfully change the direction of teams or products.

All right, Chris, do you have anything to add?

Yeah. The way I've described it is, you know, most. I think a lot of most management structures have a hierarchy, which is usually a pyramid. I think what they don't tell you going in is that the point faces down. And so you really have to be set up to be the kind of catch all and like the problems should trickle to you. And you know, I think so for difference between manager and director, like totally agree. I think of it as manager, you're kind of more an advocate for your team than you are an advocate for the company. Whereas I think a director kind of switches to being. You have to be this like effectively an interface to make sure that you know, you're representing the company's needs to the team and your managers are capable of rebroadcasting that message kind of down the chain. And equivalently you have to be able to kind of like across your entire org aggregate problems that are showing up and be able to report up or report cross team. The job is actually to some extent also a writing layer. There's no way A line I see is going to be able to communicate or know who to talk to over in some other org, because they don't even know that project is going on. And so your job is to some extent to keep track of like, a subset of what's going on for us, the company. I mean, the joke I always use is like, you know, engineer engineers, managers are like meta engineers, and then directors are meta, meta engineers. And that makes me like a meta, meta, meta engineer. I'm not sure that does anymore. But, you know, you have to cube. Yeah, I know. It's like, exactly. It's like you have to kind of. That's why. That's why it becomes more about strategy and that kind of like, up the chain because, you know, it's impossible to get down to the weeds. There's just too many weeds. And hopefully you've got talented engineers who are in the weeds. And so anything that kind of trickles up. I mean, I used to joke that especially cto, part of the job as CTO is to kind of keep track of all the fires or fundamentally, the stuff that I know about is generally stuff that's going wrong. So I have a very stilted view of, like, the way things are going. So things are going well. Like, I don't have a clue. Everything's great. It's like, you know, teams. I've heard about that team in months. It must be awesome over there. Good job, director.

It's kind of like more exception handling.

Yeah, exactly.

I'll always.

Exception handling.

You're the outermost. I'm just. Yeah, exactly.

I think you're right. Kind of like, organization exists to help communication, like at a most fundamental level.

Right.

There's been a lot of experiments with like, hierarchy list organizations. And a certain point they kind of just start to fall apart. And recognizing that and being kind of deliberate about that is super important.

All right. Yeah. I think also the size of the power engineering groups, if I want to keep invoking Dunbar's number for a given director, it's kind of good to keep it around 50 or so, because then you have enough of a notion of all of your people, you probably know them all. You can't get too into the weeds, getting bigger than that, and you start to lose track of what's going on, or at least you have to think about a different unit. So for me, it's like, I know my directors and I know my line managers, but it's very hard to keep track of. For example, so making sure that those group sizes are kind of in that range is reasonable.

This is actually a great segue into a couple of questions from Jim and Marco. Jim asks how are the development teams structured currently at scale and how has it changed from the past before you start scaling up? And Marco was wondering how do you determine when that change should happen as you scale?

Yeah, I think that there's a standard. I think this kind of goes to the layer cake model of doing engineering. In the beginning was the startup and it was good and everyone is working on the same stack and there's no differentiation between front end and backend. Or you might have the guy who likes doing CSS and the one who doesn't or the mobile engineer, but it's still just like a single team. And I think the first break that usually happens in evolution is you break at the API or you break at the server client. And so everyone goes to transition at around a dozen or so people of having the front end team and the back end team. Both of those are these just featureless masses of they're working on all the product and all the technology. The next step for us was to take the product teams and actually break them into products teams. You don't focus. We've chosen not to focus around the technology we're using, but to focus on what product you're working on. Which necessarily means that in any given team you're going to have a blend of full stack mobile engineers, web engineers on part side, maybe some back end if you really have to get down and dirty. And then the function of the back end is to generally to stay horizontal and try to basically support the product services. The job there is to ensure that there's a clean API at all layers, both in terms of contracts between teams and contracts between the actual services. And so we've had to definitely go through shifts of like we've gone through this shift from single, monolithic. We called it the, we actually called it the Reddit.com team. It was like the team that ran the website into a bunch of product orgs that cover things like the core user experience, the growth, you know, relevancy services and making sure that every team has a clearly stated mission and generally also has disjointed. You know, you want to have as best as you can interconnected but complementary okrs between teams so that you don't have like, you know, the bigger you get, the more likely you are that you have two teams stomping over one another and that's okay if they know about it, but getting back to communication, you don't always notice it until you get two PRs up and it's like, what do you mean you're working on that? We thought we were working on that. Or like, you know, it turns out that both roadmaps steered in the same direction. They collided. And so it does become a lot more of a game of making sure that that stays consistent across the board. And the way to do that is unfortunately, you have to rearg every once in a while. And that's just a natural state of affairs. It can vary from very straightforward of like, oh, yeah, of course, this makes perfect sense to wait, what are you doing? Why are you taking my team apart? It's like, well, it's because you don't really have a clear mission. I'm sorry. Or this is the business needs have to come in at some point. That's another kind of director level concern. You have to deal with it just like needs the business also has to be revenue growth.

Those things all kind of. Yeah, I totally agree with like kind of splitting the layer cake.

You got to slice the layer cake, right?

These like little full stack teams and like ownership is super important as you kind of have these teams and even identity talked about missions and values and that kind of kind of should trickle all the way down. Like every team should be able to say, this is why I exist. And if not, then that's a smell and something to address.

Yeah. There's an old canard from NASA during the moon launch where if you went to NASA during the 60s and you asked anybody what they do, they would say, I am working to put a man in the moon. All the way from janitor up to. And I think one of the difficult and important things is to make sure that every person in the company can connect themselves up to top level. What are we trying to achieve or how am I supporting what are not to me with top level okrs for the company. Making that clear and drilling that in is difficult, but rewarding if you get it right.

Exactly.

All right. We're getting a ton of questions around the organization and structure of teams, but we do have. I mean, we are running out of time. So I thought we could move to another aspect that we haven't really touched upon, which was like the hiring bit of things. When we saw this question, Leanne and I, we were like, wow, it's a good question. So character traits. What character traits do you look for in candidates when you are hiring and how has your perspective on these traits changed from the early days to today?

Okay, so I Think for me, additional background for me is that I actually don't have a CS degree. I have a PhD in experimental physics. And so I've been kind of, you know, somewhat of an outsider for most of my career at least, you know, kind of came at it from the angle of originally kind of hobbyist. Learned a whole bunch of stuff on the job, like learned the process of crafting computer science. Also did a whole bunch during my degree, like natural state, doing sciences, doing a lot of computer science. But the thing that is most important to me, me and what was really drilled into me in grad school was critical thinking being an important skill. I think, you know, being able to, you know, for us, for interviewing, I would much rather have somebody rediscover a heap during an interview than be able to explain to me what a heap is and why it's useful but not really have any understanding of the real why behind it. Right. And so, you know, I think I. When we interview, we do not ask you to reverse a binary tree because the correct answer to how to reverse a binary tree is to go to Google and to find the best package for your language that does binary tree handling than to do it that way. I'd rather give you a problem that's actually closer to the real world. So we generally interview with questions that are kind of more pertinent to us, I think in terms of what do we look for. We're at a size right now where we're not quite a big company and we're not quite a startup. And so I still want to try to attract people who have a little bit of that like kind of startup vibe of just want to get stuff done like you know, they're not looking for, they're looking for, they're looking for an enjoyable experience to some extent. Like there's fun project, they're looking for reach. Like the fact that they actually, they're going to be, you know, more than a few percent of a given team, you know, because of just the size of the company. And so they have to actually have some ability to control their own future. We also definitely look for humility as like a major component. I have worked with the self attributed rockstar engineers before and the hard part there is like oftentimes if they call themselves a rockstar, they tend to be demotivating. It's like that kind of getting back to micromanaging. I don't want somebody who works by making everyone around them feel terrible. Right. Even if they're shipping a whole bunch of and they're being productive and they're moving the needle. If the entire team is demotivated because they're a jerk, I mean, that's worse than anything else.

The whole team will stop functioning. One of the things for hiring, a lot of things to say about kind of not evaluating. Just, can someone understand this one algorithm to do something? But we try to do problem focused. But I think the key thing is bringing the human back. It's a person going through this process. And so really important to calibrate the interviewers, the people giving the interviews, to know what kind of like what a successful solution looks like. Do trainings and trial runs between your interviewers. Another thing that we've kind of tried to do is always try to make someone at least some part successful throughout the interview. Right. So always have problems that kind of gradually get harder. Right. Like there's always some way to go to a dynamic programming solution to this problem or what are those different steps? I think the last part is really just having kind of a set of criteria that you can help train the interviewers on. Like, what's the code good on these axises? Good variable names, good code structure tests, or not. And kind of like having some sort of scoring system so that you can be, at the end of the day as objective as possible. Right. And you could do something at square, called the hiring bar, where there was really senior, you know, level engineers that have done hundreds and hundreds of interviews that can kind of help calibrate the feedback and say, yeah, yes or no.

We should hire this person. The mentorship is very important. Especially, like, I also encourage, I do encourage people to kind of give the same set of problems over and over again. Because you have to learn experience on your own problems like it's it. You have to be able to see the pitfalls that people fall into when they're trying to solve it and know when you have to give a breadcrumb to kind of like help them get a little further. And if anything, I find to some extent the breadcrumbs and whether or not the person accepts the word crumb to be one of the most valuable signals you can get is like, does this person listen to feedback? Are they reasonable? If they're in an interview and I try to give them some help and they reject it, it's like, I'm not going to try and screw you up here. I am motivated to make sure you succeed. And so it really is that human side of it. Just like, can I work with this person? Because. Because in reality, the situation you're often in is like here's an unsolved problem. We're talking so both of us don't know the answer. So we're trying to talk through something. And I think trying to retain as much of that structure in an interview is the, it's the arc of interviewing, it's the art of interviewing.

And I think totally thinking about that, spending time having a group of people that are passionate about that in your company and continually evolving because these things change as your organization scales.

All right, I think we have maybe time for a couple more questions. Let's move to another topic that we haven't really talked about and that's managing remote engineers. Have you ever had to manage remote engineers and any changes or processes that you would suggest around that?

So we currently have most people in San Francisco in one office, but we have a fairly decent sized group of just kind of one off remote engineers. The good thing about that has been the fact that these are mostly self selecting people who've done it before. And so managing remote engineers in that case is, you know, like everything else about communication with the additional hampering of the fact that that person's not in the room. And so, you know, I've heard basically do it all or nothing is the best way to go. And we definitely started seeing some of that as we've had more from rogue people is that when the person who's a part of a team isn't sitting next to the pod, you start having a lot of sideline conversations. They're kind of missing out on a whole bunch of important details. Or equivalently if everyone's sitting in a conference room and there's one person on D.C. you end up with this problem of if there's a bunch of side conversations, they can't hear it when you're there. We've considered the kind of. We've had a couple teams experimenting with the like. If there's a remote person involved, everyone takes the call at their desk and does it over vc. That way everyone's on equal playing field. We're also looking to start opening up remote offices. We started hiring actually in New York and just going to be starting in actually Dublin, Ireland soon. So we're going to be stretching pretty soon. So I will have more to report in shortly on all the things that went wrong in the process of making that decision.

I would agree. I think that one anti pattern is teams that are like split between two different offices or something like that.

Or yeah, you're right.

We have this one kind of loan engineer and the rest of the team's kind of in the office. You have to be very deliberate to make sure that communication happens, the person feels included and things like that. Also just like good tooling, right? Like really, really fast. You know, Slack is great. Good video conferencing equipment. Good pair programming like Screen Hero and stuff like that. So you can kind of jump on and solve problems quickly.

Nice.

We have been experimenting with the Facebook portal here at Playdoh.

You may have seen when you came in.

All right, so I guess we're kind of at the end here. Just do we want one more last question or should we wrap up?

Yeah, one more.

Okay, one more.

So any resources you would recommend for.

People who are moving into leadership roles?

Oh man, this is a tough one. I think that definitely getting a mentor is one I would keep pushing. And that's not a plug for you guys, but it also is a plug for you guys. I think that you really have to kind of. You can read all the books on management that you can get your hands on. It's a bit like saying you're gonna get a chess by reading a bunch of books on how to play chess. Like you really have to have somebody who's done it and can show you the patterns and anti patterns and you can actually probably tune their pitch based on like the problems you're having. That's really the only way you're going to learn is to be able to tell them what you're doing, pondering and like learn from it.

That feedback loop.

That feedback loop, Yeah. I think that's another probably if I had a theme for my career, it's like, can you. How do you get the feedback loop as short as possible on whatever you're working on?

I think one part of that is just being open and honest with your team.

Right.

If you're new at it, like just be kind of totally honest. If you're struggling with something, let them know. If you want to try to change something, try to change the process with them. Learn how that high bandwidth feedback loop is super important. Stay curious, stay reading. Yeah, there's like a million books. Books aren't going to tell you, but just staying curious is super important.

Great. Perfect.

All right, thank you very much. Thanks again, Chris.

Thanks for having me, Sid Henry. Appreciate it.

So as you were saying, a mentor is really important, but not only because they are going to give you great tips, but also because they are going to make you feel better. So if you are not great at documentation, if you don't do perfect unit testing. If you are struggling with your to do, and if you are, if one on one is not natural to you and you don't have a computer science degree, then it's okay. Because the CTO of Reddit is struggling.

With this thing too.

So feel better. But there are still some things, obviously tons of things I learned today. And I just wanted to give you a couple of things that you could do tomorrow. So the 70:30 roadmap privatization, which is good. The post mortem culture, very important. Work on your values you don't need. So you were saying twice a year. So maybe it's six months, maybe three months, maybe it's a year. Leave the room better than. Take that. Leave the room better than you found it. Give a room for experimentation when you are transitioning to something new. For example, for new managers, it doesn't matter what technology you use, what matters is the choice. Pick one and deal with it. Make sure everyone is connected to the mission and know why. What is their overarching mission. Keep evolving your hiring process. So this is only maybe half or 20% of all the advice you gave today. So it was really good.

You're making me feel like I'm wise. This is actually very disconcerting.

So thank you again and hopefully we'll see you again in another community AMA with someone else we'll learn a lot from. Thank you again, Willem.

Thank you.

You.

Thank you. Yeah, bye. Thank you.