Podcast Startups |

Reddit’s Nick Caldwell on engineering leadership

On day one as Reddit’s new VP of Engineering, Nick Caldwell faced a dilemma. He had just spent 13 years at Microsoft, most recently as the head of 300 engineers. At Reddit, he led a team of 35 – none of whom knew how to manage other engineers.

He had to quickly determine which team members displayed a potential for leadership and teach them the fundamentals of management so they could make new hires and scale – without ruining the culture.

I hosted Nick on the podcast, where we discussed the differences between management and leadership, fostering diversity in tech, and more. If you enjoy the conversation, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice.

What follows is a lightly edited transcript of the conversation. Short on time? Here are five quick takeaways:

  1. Management and leadership aren’t one and the same. Managers oversee their team members’ work and career development. Leaders are people who provide a compelling vision for people to follow and believe in, and take responsibility for what happens next.
  2. Find a sponsor, not a mentor — someone who is in the room when opportunities arise and makes sure your name comes up.
  3. Building trust can be tough when you’re a new hire in a leadership position. For the first week, 90 percent of your job is listening to what matters to the people on your team.
  4. Engineering leaders must do 2 things: a) execute and deliver high-quality software on a predictable schedule, and b) have the people skills to attract, retain and develop strong talent.
  5. To promote tech leadership skills among women and people of color, leaders should create a safe environment to discuss diversity and inclusion initiatives honestly.

Darragh Curran: Nick, welcome to Inside Intercom. To set up the conversation, I thought it would be useful for everyone listening to get a brief rundown of your career to date.

Nick Caldwell: I’m VP of engineering at Reddit. I’ve been there for about two years, and my primary responsibility has been growing the engineering team from around 35 engineers to the 177 we have today and building tons and tons of interesting stuff. The biggest project I’m working on is the website redesign, but I also created a machine-learning data science, data engineering organization, and an ad platform. Before that, I was a general manager at Microsoft. I had a 13-year career at Microsoft, where I started as an intern working on video games, if you can believe it. I then went into natural language processing, machine learning, and ended working on business intelligence through a product called Power BI, which I became the general manager for.

I got into engineering through my father. When was a little kid – 3 or 4 years old – he brought home a Tandy 1000 to replace his typewriter, and I thought the thing was fascinating. I used to sit on his lap and type random stuff into the keyboard. That got me fascinated by computing early on. And then when I was around 10 years old, my dad bought me a book called Learn C++ in 12 Easy Lessons, which was not an accurate title by any means. From there, it just snowballed. I became fascinated with computers and decided that was going to be my career.

Leaders are people who take responsibility for what happens next

I got into engineering leadership as a manager about three and a half or four years into my career. Part of it was that I had good relationships with some sponsors who saw a lot of potential in me, and part of it was that I don’t like being told what to do. A couple of years later, I got into a real leadership position. Managers and leaders are different. Leaders are people who take responsibility for what happens next. I got my first real leadership opportunity about five years into my career when one of the teams I was on was struggling with the product roadmap. Rather than complaining to my manager, I decided I would step up and take responsibility for figuring out the product roadmap. That project led to my first cross-functional team. It also led to winning a Microsoft internal prize, and it was really the first time I could call myself a leader instead of a manager.

Darragh: You mentioned that you became a manager because you didn’t like being told what to do. Presumably you’ve got about 177 people who don’t like being told what to do on your team right now, right?

Nick: I was being a bit tongue-in-cheek. Our 170 engineers at Reddit are great. What was missing for me early on – and why I make that joke – is that we needed direction. I do think one thing that’s a leader’s responsibility, whether or not you’re a manager or not, is that you have to provide a compelling vision for people to follow and believe in. At that early point in my career, I was frustrated and had to step up because no one was providing that vision. At Reddit, we don’t really have that problem; if anything, we’ve got too much stuff to do. And sometimes it’s challenge to keep all the balls in the air at the same time, but there’s no shortage of vision. That translates into missions that we carry out day to day.

Sponsorship vs. mentorship

Darragh: You wrote a blog post recently about the impact of having sponsors during your time at Microsoft. How do you see the difference between mentorship and sponsorship, and why do you advocate so much for the latter?

Nick: Sponsorship versus mentorship is a piece of advice I give to pretty much every person within my organization. Most people know what mentoring is: you find a leader, someone you respect, you grab coffee with them every so often, you unload your problems on them, and they give you some coaching and advice, which is useful. It’s good for building a network. It’s good for getting advice. Sponsorship is where – instead of going to someone and getting advice – you go to them, and they give you an opportunity. Sponsors are typically high-level people in the organization who are aware of opportunities. And in meetings and conversations where those opportunities are being discussed, a sponsor makes sure your name pops up, and they’re maybe pushing those opportunities your way.

A sponsor makes sure your name pops up, and they’re maybe pushing those opportunities your way

In my career, most of the major leaps I’ve taken came through sponsorship: people who were in a room when an opportunity was being discussed and said, “Hey, Nick would be a great person to try that out.” There’s another key difference when you’re being sponsored, you actually have to follow through. In a mentor/mentee relationship, you can even expect that your mentee isn’t always going to take your advice because they’re talking to multiple people and they want to get multiple perspectives. In a sponsor relationship, there’s a clearer back and forth. If a person sponsors you, it’s not only your reputation on the line but also the reputation of whoever sponsored you. You have a heavier more burden to carry through and make sure you deliver.

Darragh: Do you think sponsorship is implicit in a manager relationship?

Nick: No, I don’t think that’s the case. Great managers look out for you and want to make sure your career interests are being considered, but managers aren’t always fully aware of all the opportunities a company might have. A manager is certainly aware of what they want you to do, but your sponsor is going to come from the broader network of other managers, directors or executives. There’s a whole ocean of opportunity out there if you just go look for it, and if you limit your opportunity window to what your manager’s giving you, you’re going to be missing out on a lot of things.

Darragh: What’s your advice for people who don’t yet have someone they identify as their sponsor?

Nick: Getting a sponsor is difficult. It’s more challenging to get than a mentor. You start by getting a sponsor by simply doing great work. No one will sponsor you if they aren’t willing to take a bet on you. Step one: make sure your work is rock solid, and put a lot of energy into high quality results. Step two: gain sponsors through networking. When I was at Microsoft, I made a conscious effort to spend some percentage of my week meeting people who weren’t within my organization. Finally, you have to be patient and wait for your opportunity.

The value of my network outweighs most other investments I made in terms of my career advancement

When you’re networking, the value of your network is always immediately apparent. But in looking back over my career, it’s clear that the value of my network outweighs most other investments I made in terms of my career advancement. Find people who would be willing to sponsor you, that have a continuous stream of opportunities that they look at, impress them and then be patient and when the opportunity arises, don’t be afraid to jump. If you want to advance in your career, you have to get uncomfortable and be ready to try new thing. When that opportunity presents itself, jump at it and go.

Darragh: Was this a formal thing at Microsoft or is there a sponsor program?

Nick: There was not like a formal sponsor program until late in my Microsoft career because over time, people wanted to normalize sponsoring and they saw the value in it. Early on it was simply me putting in the legwork myself. Later on, there was formal sponsoring for a good reason, which was to promote diversity and inclusion. /dev/color is a charity I’m a board member of, and one of its goals is to promote leadership – particularly getting people of color into leadership positions. If you want to make real tangible progress there, sponsorship is a great method.

What to tackle first as a new leader

Darragh: What was it like when you walked in on day one at Reddit? What were some of the unexpected challenges that appeared? What needed to change or improve right away? And what did you pull from your time at Microsoft?

Nick: When I left Microsoft, my team was around 300 people. When I joined Reddit, it was 35 people and my mandate was to grow it rapidly to about 100 engineers. I would describe that first day as a 35-person team being run with the tools you would see in a five-person team. A lot of the engineering processes were missing; there were one or two (but almost zero) managers, and there were a lot of people calling themselves “tech leads,” but there were no managers. One other thing that was frustrating on that first week was that there was a video game setup with Smash Brothers right in front of where the executives sat, and people were just playing Smash Brothers all day. You can’t really execute if people aren’t motivated and excited about the company mission.

Those were three things I wanted to jump on. I said: “We have to get some managers in here if we want to scale. We have to figure out how we’re going to run our engineering processes in a way that’s going to grow with 100 people instead of using a five-person process. Then critically, if you can’t come up with a vision or mission that’s more interesting than Smash Brothers, then you’ve got a big problem.” We spent some of those early days crystallizing what we wanted people to be working on and why it was exciting.

Darragh: What game did you replace Smash Brothers with?

Nick: Well, the game playing really died out. If you walk in the office now, it’s people just cranking away. But after hours, there’s this game called Killer Queen. I’ve never played it myself; it’s a 10-player simultaneous video game that I’m told is the most fun thing ever.

Selecting the right tool for the problem

Darragh: You went from running a 300-person team to one 10 percent of that size. Were you sensitive to the idea of applying what worked for Microsoft in a different context?

Nick: Your natural assumption is to take whatever works in your previous roles and use it as a template for what’s next. I view process more as a set of tools I carry around with me, and I decide which tools are going to be deployed based on the situation. I immediately knew that trying to deploy tools from a big company like Microsoft on day one would not work at Reddit. If you’re coming into an organization, big or small, and you’re in a leadership position, you need to spend the first couple weeks just listening to the problems people on the team present to you. Then, you can dig around in your process tool bag, figure out the right tool for the job, and adapt that tool to fit the situation.

You want people to tell you what they need, and then you come up with the correct solution rather than assuming you have the solution from the start

At Reddit, the biggest immediate change I had to make was getting managers in place in a company that really didn’t have a formal management career track. But I didn’t just jump in and say: “You’re a manager! You’re a manager! You’re not!” I took time to talk about what management was, my philosophy on what it meant and the value it would add to the organization. Then over time, I just listened to the tech leads describe their problems day to day and said, “Hey, if we had a manager this problem would go away.” Over time, you get an inception where people realize that having this management layer is going to solve the problems for them. And that took about a month and a half from start to finish. Then, the pattern repeats. You want people to tell you what they need, and then you come up with the correct solution rather than assuming you have the solution from the start. That’s a great way to piss people off: to just land a ton of process on them that they’ve never been exposed to.

Building empathy for users

Darragh: Earlier you said one of the major focuses for your team the past year has been to make Reddit more welcoming. What does that mean in practice, and what the role of engineering is in helping accomplish that?

Nick: Making Reddit more welcoming was a theme for all of 2017 and most of 2018. From a user experience perspective, Reddit hadn’t been updated for about eight to 10 years, and it’s well known for being a site that was anchored in the past. The challenge, though, is that meant new users to the site were having a bad experience. They couldn’t figure out how to use the product, and it looked really dated. So they’d come in and think, “I don’t get this.” Then they’d turn right back around and leave, which is unfortunate because there’s lots of great content and communities on Reddit. If it were easier for people to understand and connect with, the site would grow, and that’s what we really want to have happen.

Over the last year or so, we’ve been redoing Reddit’s entire user interface, so it looks much cleaner right now. If you go to new.reddit.com, you’ll see the new version of Reddit, which has some cool features like infinite scroll and a card view that’s easier to consume. The challenge with this, of course, is we already have a ton of existing Redditors, so we have to make sure their old experiences translate well into this new experience. We had to redo the entire front-end architecture.

For me personally, another really fun set of things that we’re doing is using data to easily connect people with communities that might be interesting to them. We’re trying to understand: Can we group communities by topic? When someone onboards to Reddit, can we give them recommendations? As they use the home feed, can we make it more personalized and customized to their interests? From an engineering perspective, we have a data engineering team, a data science team, a machine-learning team, and a search and relevance team, which has all been really fun to create from the ground up.

Darragh: I love when you can get your purpose clear enough that all those things make sense, rather than bringing all those types of teams to the table without knowing exactly what you want to achieve. With such a large org, how do you build a sense of connection and empathy for your users?

Nick: There are two approaches. The first is the quantitative approach. In any product you’re building, you want to make sure telemetry and monitoring are baked in from the start so that you understand which aspects of your product are actually getting used. Then, you can either double down on those or decide whether or not they’re the right things to focus on. The second thing is more qualitative: developing customer empathy often times requires you to get down on their level and experience what they’re experiencing. At Reddit, we do that in a couple different ways. On a small scale, we invite people to the office, and we do user interviews.

On a larger scale, Reddit already has this gigantic community of moderators. Reddit is a network of communities, and each of these communities is run by teams of moderators. We’ve created communities where we can engage at a high frequency rate with those moderators to get feedback on any new product or feature we build. Every time we create a feature, we make a post announcing what that feature is, how to use it, and how to test it. We’ll put it into the moderator community, and almost instantly they’ll give us feedback on how well we’ve done so we can adjust as needed. Our moderators are not shy. You can really see that with the redesign. If you go to the r/redesign community on Reddit, you’ll see announcements for what we’re shipping, along with feedback both positive and negative about some of the features that we’ve created all the way back since we started the redesign. And we just keep revving that as fast as we can until hopefully people are 100 percent happy. Well, maybe 90 percent.

How leaders build trust

Darragh: What advice would you give engineering leaders who are moving roles or companies and taking responsibility they’re not yet familiar with? How do you build the trust you need to lead that team into the future?

Nick: Whenever you take over a team, the first thing you have to do is decide that you’re not going to just exert your willpower immediately. Nothing beats listening, at least for the first few days, to get a lay of the land and a sense of what matters to the people on the team. Listening is 90 percent if what you should be doing for that first week. Some engineering leaders there will tell you “Hey, it’s the first 30 days.” But I work in startups. 30 days is a long time at a startup, so I would dispute that you should wait and do nothing for 30 days. In a startup environment, the clock’s is ticking.

So, I would say listen for about a week. Make sure you understand what matter. You’re going to bucket what you hear into two distinct groups. First: things on fire that you need a bucket of water to put out immediately. Second: things that aren’t on fire that you should build a fire department to address in a more systematic fashion. For the things that are on fire, work with the key leaders who told you about them to come up with immediate solutions. This is a great one-two punch: it helps you actually solve a problem quickly, and you can build trust through actually doing things. For the second class of problems, take your time and use your normal approaches to toward getting buy-in with key stakeholders. Let the new systems roll out slowly over time.

Another thing is that you do have to identify people who are going to be supportive. The tricky thing is you also want to identify people who aren’t going to be supportive. With any organization, particularly one that’s going to scale quickly, sometimes you find people who fundamentally don’t like scale. There are plenty of folks out there who love that small-startup, 30-person feel, and they aren’t necessarily going to make it to the 300- to 500-person engineering organization. But corresponding to that, there’s also a bunch of people who are super excited to see that growth is about to happen. Find people who are going to be supportive, use them as advocates and guinea pigs for any new processes you want to roll out, and grow that way.

Darragh: With the people who are comfortable in that small 30-person company, do you think that that’s a changeable mindset?

The best managers understand that it’s about aligning people’s passion with what the business needs

Nick: Totally. People can change over time, right? So, if someone is only used to only working at small startups, they can learn over time how to operate with more processes and more dependencies. Those are totally trainable and if you have good managers and directors, they’ll bring people along for the ride. But I’ll always caution: sometimes people are just good in their particular lane, and you want to be careful as a manager not to force people out of their lane unnecessarily. If someone’s really strong at a particular skill or in a particular team size, there’s always a risk to pull them out of that. I would strongly advise you to make sure that people’s interests and passion are lined up with what you are trying to get them to do as a manager. If you can get that intersection, then you get the maximum output. If you’re always trying to pull people away from what they’re naturally inclined to do, or push them toward things they don’t want to learn, you’re going to be fighting an uphill battle. As a manager, you have to recognize that it might be better for that person to find a different opportunity. It would be better for them, and it would be better for your team. The best managers understand that it’s about aligning people’s passion with what the business needs.

Balancing internal growth with hiring

Darragh: When you joined Reddit, there was basically no engineering management practice there. You introduced that, but you did so by balancing both hiring and growing folks internally. I’d love to understand your thought process and approach there.

Nick: Whenever you’re building an organization, it’s always best to look within, before you bring in folks who from the outside. You want to preserve the company culture, and every time you bring in a new leader from outside, you’re going to change the culture up a little bit. Even though we had 35 engineers at Reddit, there weren’t a lot of managers. But it was clear to me that there were a lot of people who exhibited leadership and could be guided toward a management track. There are also a lot of folks who wanted to be individual contributors and maybe go up an architect track. So I introduced the concept that you could climb the ranks in one of those two roles. Within the first couple of weeks, I did one-on-ones with all these folks and tried to figure out what their career aspirations were. For engineering managers, I look for people who like to ship on a predictable schedule, people who enjoy coaching, mentoring, and investing their time in others. Then, you can identify architects as folks who are interested in the long-term health of the code base. They may talk your ear off about Kubernetes or some Erlang or a niche technical project. I tried to tease these folks apart, and for the folks I identified as being more managerial in nature, I started with one-on-one training at first and then group training later, teaching what I thought were the basics and fundamental requirements of being a good manager.

On the execution side, you need to be able to deliver high quality software on a predictable schedule. On the people side, you have to attract, retain, and develop strong talent. Those are the fundamentals of management. With the architects, I talked talked about how to manage and monitor tech debt, how to develop technical strategy in terms of scaling. So that gave me the first group of people. I had to train all these folks to try and hire more engineers – if you ever find yourself in a situation where you need to scale this rapidly, you do eventually have to hire external folks. But I only did that after we had a great system of execution in place and I also felt that the company culture would sustain bringing in more people from the outside.

Darragh: Your line of questioning to help explore is interesting. Do you get many people who want to do both?

Nick: Early on, everyone is in that situation. Most companies have a role called “Tech Lead,” which if we’re being honest, is a proto-position where you have some management responsibilities and some architectural responsibilities. You’re halfway between two worlds. We had that at Microsoft, and it seems to be really common. Rather leaving people in that limbo state, though, I prefer to track they want to experiment with as quickly as possible. If it works, great. If not, you can always switch. You can make a lot of different bets on yourself, particularly in Silicon Valley.

The magic of Snoo’s Days

Darragh: Speaking of bets, I understand that a big part of Reddit’s engineering culture is around freedom and experimentation and a particular ritual called “Snoo’s Days.” Can you explain what those are and most interesting things that have come out of them?

Nick: Snoo’s Day was actually started by the original Reddit CTO, Marty Weiner, and the idea was to give Reddit employees some creative freedom. They could literally explore any engineering or non-engineering topic they wanted for one day every couple weeks. When I joined, I saw this bi-weekly ritual and I thought it was great culturally because allowed people to take a lot of creative risks. But because I like to put process on things, I decided one day didn’t really give people enough time to take a full swing at some of these ideas. So Marty and I worked together to modify Snoo’s Day, by making it a few days longer, adding themes, and adding prizes. Now, it’s become an institution, and it’s actually a whole week long. One’s coming up next week, and we’ve got five different prizes. Nowadays, the projects that come out of Snoo’s Week will get shipped into full production, so we get a lot of great value out of that. Last time around, the theme was “quality.” This time, the theme will be “efficiency,” so hopefully we’ll get some great cost-saving projects.

The intent of Snoo’s Week is really creative freedom

Here are some examples: We were talking about Killer Queen a while back. Reddit really loves this game, and they were asking us to buy one for the office. It turns out this game costs like $15,000 dollars, and we weren’t willing to spend 15 grand on it, so during one of the Snoo’s Weeks, the team got together and made a game called “Killer Snoo.” It’s basically a clone of Killer Queen with all of the characters replaced by Steve Huffman the CEO, co-founder Alexis Ohanian, and a bunch of different Reddit. It’s really awesome. There are practical ones, as well: we had someone add performance monitoring to our continuous integration, continuous delivery pipeline. That shipped to production. There’s a good one called “Reddit Rabbit Hole,” where the idea was that essentially for any given post you would see on Reddit, we would find the next most addicting post so you would just fall into Reddit and never get out of the rabbit hole. That one is in experimentation now and might ship.

The idea here is that if you give a couple hundred people free reign to come up with any idea they want, sometimes you’ll get games, and sometimes you’ll get things that add immediate value to our end users. But the intent is really creative freedom. We’ve had people use it for things that weren’t even really code, like a pie baking contest and a gardening club, so that creative culture lends itself to a lot of different outcomes.

How to foster diversity in coding

Darragh: You’ve also recently created a scholarship program called “Color Code,” and as you mentioned you’re on the board of /dev/color. Can you tell our listeners what those initiatives are about?

Nick: To give some quick backstory, I’d been at Microsoft for 13 years. And I was one of the few black engineers I would see day to day. You’d really see few other people of color on campus, and that was frustrating. The whole time I was there, I don’t remember seeing any other black Tech Execs. Which was really frustrating. I had been trying at Microsoft for so long to change the numbers, both in terms of people of color and women in tech. We made progress with women in tech, but trying to get people of color up into Seattle was always a challenge.

Within the first two weeks of moving to San Francisco, though, I was invited to /dev/color. It’s a non-profit group whose purpose is to promote leadership for people of color in the tech industry. I attended one of their first events, and there were 300 other black people in one room, all in tech, from all age ranges, from entry level all the way up to senior executives. I was just blown away by this; I’d never seen anything like it in my career and it really gave me hope that I could really make a difference if I put my time in. In San Francisco, at least, there were enough people in the area with enough motivation to hustle and learn, that I could really help make a difference.

So, to answer your question, Color Code is a scholarship my wife and I started about a year and a half ago. It’s a small fund; it comes out of just our own money and our small donations. We pick a leader who we think has a lot of potential, and we’ll put them through training courses or give them mentoring. We’ve done that with a few people over the last year. /dev/color is much larger, though, and I highly encourage people to look at this organization if they’re interested in finding ways to promote leadership for people of color. I joined the board a few months back because as the organization scales, they want people who have run larger organizations. When I joined, it was 300 people; they’ve since broken through the 500-person barrier and now are expanding to multiple cities. /dev/color is different from other boot camps that you might have heard about in that it’s just not a boot camp. Boot camps are about getting people in at the ground floor. And /dev/color is really about getting them into positions of leadership, which is a key evolution in diversity and inclusion.

Darragh: What are some ways for folks who to get involved and help that initiative?

If you talk about diversity issues in a safe environment, you’ll make more progress

Nick: Start at devcolor.org. They do sign-ups every three to four months, so you can join anytime. If you want to join you do have to have some initiative, and there’s what I call a “lean-in circle.” The first experience you’ll have in /dev/color is joining a squad of other people who will tell you what goals they have for their careers, and your responsibility is to meet with them once a month to talk about progress toward those goals. That’s like the entry requirement for getting into /dev/color to show that you’re willing to put the time and commitment in to help others as well as yourself.

If you would like to sponsor, just shoot me an email and hit me on LinkedIn. If you sponsor /dev/color, you will obviously get to have folks in your company join the organization, but we also have training programs for folks who maybe aren’t people of color but just want to learn about how they can make a difference. If you talk about these issues in a safe environment, you’ll make more progress. Companies can be afraid to talk about their diversity initiatives publicly and honestly. And with /dev/color we have a closed-door environment where you can come and bring your honest questions and concerns, meet with other leaders who are trying to promote diversity and inclusion in their organizations, and talk about what works and what doesn’t without worrying about your initiatives showing up on Business Insider or TechCrunch or something like that. Talking about these things is a great way to continue making forward progress.

Join over 40,000 subscribers and get
 the best content on product management, marketing and customer support.