How to Lead An Engineering Team During A Period of Hypergrowth: an AMA with Chris Slowe, CTO at Reddit
1 April, 2020
Chris Slowe, CTO at Reddit, was also the first employee back in the day. He started 3 months into the startup as a Senior Engineer, and stayed there as a Lead Architect and Manager until 2010.
In 2010, Chris joined Hipmunk, as the Chief Scientist, enabling the company to build one of the fastest tools to find great travel deals. He helped the engineering team grow from 4 to 50 over the course of 5 years. His CTO at Hipmunk was also Reddit’s co-founder Steve Huffman.
He came back to basics in early 2016, where he joined Reddit — again, alongside Steve who became the CEO. After a few years as the Director of Engineering, Chris is now the CTO of the 6th largest website in the world. His current focal areas include security, data compliance, core architecture…and testing.
Chris is speaking at our upcoming engineering and product leadership conference, Elevate, on August 7th in SF! Come meet him and other leaders to share your experiences and learn how they manage their teams.
What can engineers learn from his impressive experience?
At Plato, we had the privilege of having him in a community AMA with our mentees. In this article, we’ll share with you the highlights of this AMA.
We would like to thank Willem Avé, Engineering Manager at Square, and Henry Hsu, Senior Engineering Manager at Zendesk. They are two of our top-notch mentors who participated in the community AMA and asked relevant questions to Chris. Thanks a bunch to our mentees who attended the AMA too!
On the role of CTO
The ins and outs of being a CTO at Reddit
Chris answered that his role actually consists of juggling with two positions: CTO and VP, which is both a challenge and a lot of fun.
On being a CTO at Reddit:
I think the CTO role at Reddit is primarily kind of a chief architectural role. I have an OCTO (Office of the CTO) 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 it’s like fix a thing and move on which is a lot of fun.
On being a VP Engineering:
The VP edge half: we have right now about eight engineering groups under the director, of about 170 engineers in total. So, a pretty flushed out organization, which is delightful considering when I restarted in 2016 there were 40, maybe even a little less than that.
Chris further explained his position has interesting challenges as the team scaled fast:
We’ve gone through a number of re-organizations from the original startup’s model […] It has been exciting to put a new model in place and learn how to scale up past Dunbar’s number__. The two versions of it are: you can keep track of the individual stories of about 50 people and you can keep track of about 150 people’s names. So, if you get past that point, all of a sudden you will have to rely on a trust network to make things work.
From a leadership perspective, what has the evolution been like? How does Chris manage to balance in a rapid environment, mentoring people and developing them into goals instead of bringing outside talent?
In this case hiring seasoned, experienced directors helps a lot. Having somebody who actually knows not only how to manage, but how to manage managers is critical. The next level up is like being able to turn bad managers into good managers. So, we’ve tried very hard to internally promote people to management roles and they actually want to do and we made sure that our career ladder is actually pretty evenly split so the IC track has parallels to the management track.
Chris added a bit later:
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. You have to rely on people’s ability to make decisions so I prefer to provide guidelines and let people make the decision. From there, 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. I think it comes to making sure people feel heard.
One of the AMA participants also asked Chris how he grew to become a successful leader:
For me, it was a very organic transition, which I think is a pretty typical path for people. You usually go from IC to a lead, or having people look to your leadership either formally or informally. I think that approach is why we care so much about our internal pre-manager cohort of people who are interested in making the shift.
Scaling through values
Being the #6 biggest website, Reddit has faced many challenges in terms of growing, both the tech and the team.
Back in the easly days, Reddit has seen exponential growth, doubling size every three months, which forced the whole team to learn continuously about the tech, live. This enabled the engineers to instill a culture of learning up to now.
On the human side, growth has brought Chris a handful of challenges too, especially in terms of company culture:
I think on the human side, starting in 2016, the whole company was about 90 people. So, we basically had two straight years of doubling, which has been exciting and terrifying at the same time. The learnings have been how on how to build good culture__, and how to keep good culture.
Chris further explained:
There are benefits and detriments to diluting with new talent. You get the advantage of new people who are bright-eyed and bushy-tailed. But at the same time, you have to make sure to take the time to — it sounds severe — indoctrinate people with the company culture.
While the term indeed sounds severe, Chris described it this way:
Make sure that they’re thinking in the same terms and that they have shared values. If you talked to me five years ago, before I had to do this or to see it, values seemed like such corporate nonsense, when really, it’s the opposite. The most critical thing you could do is to make sure that everyone knows what they are and actually recite them because it helps set the tone for how people behave.
One of our values, that has been around a very long time is also kind of core to the site is ‘remember the human’. It means both attach the fact that the person on the other side of the screen, whether it’s a coworker or somebody on Reddit is actually working towards some good intent.
So, company values act as the cement that brings together every employee of Reddit towards a common goal.
How is Reddit building those values?
We usually do it at the executive level. I think a lot of the values end up being the results of Steve Huffman, our CEO, mulling on it for a while. To some extent the job of the CEO has the biggest scope in the company and therefore can also have the least depth. It’s thus really about trying to define a gentle way to control where the company is headed.
In this case, setting the underlying tone of the culture is important. We generally have a brainstorming session where we discuss what we should do to tweak the values. Part of the values are quite easy to change as we already iterated on them many times. Then, there are values we keep, not because we need to work on them, but because it’s essential for Reddit that everyone thinks about them at all times.
How do these values include a body of knowledge and feedback brought by executives?
Feedback is a constant concern. In fact, this is something that has been hard for us as we scaled. With feedback, there is a need for trust at the same time. It’s all about attribution of intent. If you’re going to give somebody else feedback and you don’t know them very well, it can be really difficult, especially if it’s critical feedback.
For us, it’s been ultimately about transparency. When we have large discussions, we try to get it all documented, get everyone to write their feedback back into the document, so they can read it too. Documenting has been critical to making sure that that feedback is heard and acted on. 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 wordsmith it and think about what they are trying to say.
Sharing values also means sharing a common purpose among teams: whatever their task, they must go towards the same goal as the whole company. Doing so helps teams find a sense of identity while working towards a bigger objective. Chris summed that up with an cool story:
There’s an old saying from NASA during the moon launch, where if you went to NASA during the sixties and you asked anybody what they do, they would say, ‘I’m working to put a man on the moon.’ All the way from janitor up to the top.
I think one of the difficult and important things is to make sure that every person in a company can connect themselves up to the top level of what the company is trying to achieve. Or rather, asking themselves: “how am I supporting what are meant to be our top level OKR’s of the company?” Making that clear and drilling that in is difficult but rewarding if you get it right.
Scaling the organization
When Chris started talking about writing down feedback, our community was curious about how other engineering rituals evolved as the company grew, with an interesting take on unit tests and documentation.
One of the things we discovered in the five years [at Hipmunk] is the power of unit tests. Coming back to Reddit in early 2016, was a bit like coming back to an alternate reality where the team had chosen a different path. I came back and wrote my first patch, having not looked at the codebase in years. There were parts that hadn’t really changed and still bore my name. I was like, ‘okay, great, let me just write the unit test’ … ‘oh man, we don’t have any unit tests’.
We thus started building a real deep CI suite. We were moving from a monolith to services as an opportunity to clean up and rebuild along the way. That’s the time we shifted to a testing culture.
There is a set of engineers who are sufficiently competent that they don’t need to write unit tests, but that is a vanishing small number of people. If anything, the utility of unit tests as a means for us to make sure people do not repeat mistakes.
Chris admits documentation is usually neglected:
I think we’re still pretty terrible at documentation, but I have seen very few companies that are good at it. There’s always a tradeoff between solving technical debt and moving fast. In such a case, documentation is the thing that falls. Fortunately, we have layers of people making sure whoever comes along next knows what to do.
Yet, it seems that documentation has been good enough for Reddit to avoid mistakes:
I also think run books are underutilized in other parts of the stack. Nothing beats a good run book: it’s a process you can use in any sort of situation. If it’s bad, we postmortem it and figure out how to make the next version better.
We run a blameless postmortem method which is a timeline of what happened, what was expected to happen, how the engineer would remediate it and what the next steps are.
The entire attempt there is not to blame whoever causes the problem, but to make sure that it doesn’t happen again. Even if a human in the loop caused the problem, there’s probably some underlying thing that tipped it off.
Errare humanum est, perseverare diabolicum could be one of Chris’s mantras. He believes that mistakes and failures enable people to grow, as long as they don’t repeat them in the future, and shared an interesting anecdote:
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 up and says, ‘we just put a lot of investment in your career, so make sure that your next mistake is not like that one’. I feel like software engineering is much more like that. It has much more potential for any one person to cause a whole bridge to collapse and learning from that is the only way to progress.
In order to help people level up, Chris shared his process to find the right playbook:
I think for leveling up, it’s been a group effort across our leadership team and our management team. It really comes from the idea that you can do it the hard way and crank at 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.
Defining a clear career ladder with two separate tracks (IC/Management) enabled Chris to ensure people who wanted to get into a manager role did it because they wanted to manage people.
This involves explaining to people that it’s actually a very different set of skills than what makes you a good IC. For us, leadership and management are related but independent. Anyone who gets staffage in their cross, has to become a leader.
You can’t just be as lone soldier who drills down on code, hiding in the corner. 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 foster growth.
For management directors, that’s definitely part of the job. Making sure also, that for engineering managers, there’s a path to encourage for senior ICs to mentor junior ICs. The whole process is really about mentorship.
I would love to mostly hire a bunch of ICs, fresh out of school… and then there are those moments in your career where you find out, a couple of years later that there’s this senior person you’ve basically watched grow through their whole career. I think that is the best part of being a manager.
One-on-ones are valuable only if they are well-structured:
I think the value of one-on-ones definitely comes from it. We need to make sure that the one-on-one has a structure and 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 IC.
Finally, a talent development and a culture team are also here to help people grow in their roles, be it as a manager or as an IC:
We are big enough now to have a talent development team on our people and culture team and they provide the initial outlet for a third party in the room or a third party available. So, a month they can check in on both manager and managee’s and see if it’s working or where the gaps are and questioning if we need to make any changes.
Chris shared a bit more about his background, and the way he hires people.
First of all, it’s important to note that given his own experience, he doesn’t necessarily look for degrees when hiring:
I actually don’t have a CS degree. I have a PHD in experimental physics, and I’ve therefore been somewhat of an outsider for most of my career. I was originally a hobbyist who learned a whole bunch of stuff on the job, such as the process of crafting computer science during my degree. I don’t focus on the degree and rather pay attention to critical thinking.
His focus is more about spotting a capacity to reflect and analyse:
For us in 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.
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 to find the best package for your language that does binary tree handling and do it that way. I’d rather give you a problem that’s actually closer to the real world. We generally hit you with questions that are more pertinent to us.
In terms of what we look for, we are at a size right now where we are 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 startup vibe of just wanting to get stuff done.
Besides tech, personal skills are an essential quality he seeks in new hires:
We also definitely look for humility as a major component. I have worked with the self attributed rockstar engineers before and the hard part there is oftentimes if they come to us as a rockstar, they tend to be demotivating.
I don’t want somebody who works by making everyone around them feel terrible. Even if they’re shipping a whole bunch and they’re being productive and they’re moving the needle, if their entire team is demotivated because they’re a jerk, that’s worse than anything else.
Chris encourages interviewers to give the same set of questions over and over again. Doing so will help them improve their interviewing skills:
You have to be able to see the pitfalls people fall into when they’re trying to solve the problem and know when you have to give a bread crumb to help them get a little further.
Giving breadcrumbs has another advantage:
I find breadcrumbs and whether or not the interviewee accepts them to be one of the most valuable signals you can get. It shows if the person listens to your feedback and if they are reasonable. If they are in an interview they reject my help, it says a lot about their state of mind.
Moving into a leadership role
We asked Chris if there were any resources he would recommend for people who move into leadership roles, and his answer (obviously) delighted us:
I think that getting a mentor is something I would keep pushing and that’s not a plug for you guys, but that is also a plug for you guys. You can read all the books on management that you can get your hands on, but it’s a bit like saying you’re going to get good at chess by reading a bunch of books on how to play chess.
You really have to have somebody who has done it and can show you the patterns and anti patterns. You can then probably tune their pitch based on the problems you’re having. That’s really the only way you’re going to learn: tell them what you’re encountering and learn from it. If I had a theme for my career, it would be ‘how do you get the feedback loop as short as possible on whatever you’re working on’.
We are really grateful that Chris took the time to talk about his experience given his full agenda!
As the AMA was an hour long, we only skimmed through the surface of the insights Chris brought us. You may want to read the full transcript as well, right there!
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.