As of 2017, Reddit has 300 million monthly visitors, ranking #4 most visited web-site in US and #8 in the world. This kind of tremendous traffic takes some serious engineering efforts that have had to scale with the site's growing popularity. Nick will discuss his engineering team's approach to agile development as they scaled from 40 to 120 engineers. He will walk you through their engineering work flow, use of tools like JIRA and Tableau, discuss meeting rhythms, an and cover the must-have cultural elements of a successful team that work at every point of scale.
My name is Nick Caldwell, and I'm going to tell you about Reddit, a lot of Reddit fans in here that helps my self esteem so much. I used to, I used to work on business intelligence software. Raise your hand. So my topic is a triple a team size without losing control.
I'll tell you a little bit myself first. So I'm currently the VP of engineering at Reddit and I formerly am the general manager of a product family called power BI at Microsoft. I was there for 13 years and I grew a small team of about 10 people up to about a 350. Organization with with five different products graduate of MIT go beavers and MBA at Berkeley Haas go bears.
So that's a little bit about me and I want to tell you about Reddit. So. For those of you who don't know much about Reddit or actually for those of you who are already, you may not know a few of these things. So quick stats. Reddit is the fourth largest site in the United States, according to Alexa ranking, and it's 325 million monthly active users.
A lot of cool stuff is happening at Reddit. For those of you who are Redditors have, you've seen a lot of different product announcement. I'm going to tell you about. What we've been doing this year later in the presentation, but just to summarize what's new, we've got you know, a new exact team cares a lot about making the platform more welcoming and care about monetization as well.
So a very, very different product vision and then the, the thing that's important is rapid expansion. So that chart on the right is the number of employees at Reddit. Well, actually this is out of date. So this is a quarter out of date read it's you know, has grown. 30 engineers when I arrived to currently about 120.
So let's talk about why tripling the scene size without losing control is important. So a couple of years back there was a. Reports called the startup genome report and it surveyed about a thousand different startups and, you know, looked at the successful ones, like the ones that failed and asked them what worked and what didn't work.
This is an interesting stat that I care a lot about. It says within three years, 92% of startups fail and of those 43% fail due to issues with. Right. So as someone who wants my Reddit stock to someday be worth something, this is a very, very important statistic for me. And I'm a big part of the reason why they brought me to Reddit was because of my past experience at Microsoft scaling a lot of different intrepreneurial teams.
So with that in mind, let's talk about. My first week at Reddit and the challenges I had there. So again, I'm coming from a big gigantic company Microsoft coming down to a smaller organization. So my first day, this is what I see. I see a 30 person stand up. There is a a Google slide that we're using to track the work across the entire company.
I'll show you that a little bit later. There's these people floating around called tech leads, but I can't find anyone who's like an actual manager. And then things are going really slow. Like we're a startup, we're not shipping stuff, so it's not going out the door. So given all that, we still had a ton of work.
I think any of you guys who have seen Reddit would probably agree that it needs a little bit of a refresher and
we need to get that done. And then I also was asked to scale up the team. So I had to hire about a hundred people. So this was kind of the jungle that I was dropped into. And I needed to figure out, you know, how am I going to find. Managers how many give them roles and responsibilities, so even know what to do.
What is the process we're going to use? And then how are we going to get all the stuff that we need to ship done? Like, how are we going to move quickly? So that's what this talk is going to be about. There was tons of other challenges that I needed to hit, but those are the ones that I think you guys would be most interested in.
So, first one how do you find managers? So, you know, First problem I had is I had these folks calling themselves Glades. And I remember when I started my engineering career, like 15 years ago. So my manager and I asked him, what's a tech lead, you know, what is a tech lead? And he looked at me thoughtfully and he said, I have no idea.
And, but now 15 years later, I'm an executor. I'm a bonafide examined actual executive, 15 years of experience. And one of my managers came one of my ICS came to me and asked me what's a tech lead. And I told him I have no idea. I don't think anybody knows what a tech lead is. You know, the, the best I can think of is like, there may be prodo managers that's for the purposes of this discussion, this isn't a philosophical discussion.
There's a practical meetings. You know, we're not going to talk philosophy what I'm going to answer for the purposes of this discussion. We're going to call tech leads, program managers, and that's, that's how I treated them. But what I wanted to get to is from a place where we had this lack of clarity about what the role of tech lead was to something where it was clear what the responsibilities for each individual was.
So. And it came up. If you guys are familiar with blade runner, blade runner is coming out. I'm looking forward to that. They have a test in there called the void camp test to determine whether or not a person's like an Android or a human. And I decided to and then the same thing for for our managers versus architects and this, and this flow chart, you insert your tech lead, and then you ask a few questions and you get like a manager and architect on the other side.
Why, so, why is this a, what are the questions here? Right. I'll just breeze through them real quick and say, why, what do you care more about? People are architecture. If you're a manager, I hope your answer is people. What are your thoughts around sh shipping's word, a deadline. I've had many of the IC engineer telling me I don't need no stinking deadlines.
It's ready when it's ready. And if a manager ever tells me that boy your PM goes to two of your direct reports and asked them to start working on an urgent new feature. Do you do? All right. So engineering managers turns out the responsibility for an engineering manager is to manage engineers. It's not that complicated.
So if your PM's dropshipping into your team, you've got a kind of. Put a little protection on them. And then finally you spend one day a week, trolling, LinkedIn or working with recruiting. How does that make you feel? Well in an organization where you need to hire a hundred people, if you tell me you don't like working with recruiting, if you tell me you don't like being rejected on LinkedIn over and over and over again while you may not be a great fit for a manager, now you can come up with.
But this is the test we use at Reddit. It's the test that leads to a management style that I like. And it also reflects what we really needed urgently at the company. But so we ran this, we identified a few people who are going to convert from tech leads managers. We also got some architects out of this, but that's beyond the scope of the meeting or this presentation.
And next stuff was, well, what are they supposed to do? Right. So I got all those people who could maybe be managers. They don't know what to do at a. Right. It's a startup. And I think many of you in the room at startups, you might agree with this, that at startups, particularly small ones you've got an issue with roles and responsibilities.
And I think like the classic example of this is if you got a brand new startup, you get the, you may have the technical co-founder and you've got the business co-founder. But really, if you look at what those two people are doing, it's pretty much. Well, you might expect like the CTO to be on like a sales call, for example, but as your company scales up, you need to get more specialized, you know, you start getting like the growth hacker, the marketer you know, you, you split engine, product and design, like all these specialized roles start to emerge because you need to be a little bit more optimized about it.
And now Reddit had this problem in spades and I'll give you a quick idea. From our chief legal counsel Melissa Tidwell's, who's one of the smartest people I've ever met. She told me this story. She said, when she first got to read it, her first day was the following. She went into that same big room that I showed you a picture.
And it was the Reddit security council meeting. And you can imagine Reddit has a lot of issues. Talk about legal issues and security and so forth. And who would you imagine would be the members of this like legal advice and security council? Well, of course it was all the line level. I see engineers Pontificating about legal issues as if like you could get 10 engineers crammed them together, and then the output would be like a Harvard educated lawyer.
So Missy you know, shut that down like on day one and, and took responsibility for leaving. But if you, if you don't have a very strong line that lawyer and you need some some way to do this at your startup here's the thing that I learned about a while back, it's called a RACI chart.
So this is a chart where what you do is you try and list out all the different activities in an organization. And then you decide whether or not, you know the people in your organization are responsible accountable should be consulted or informed you know, about those different activities.
So the nice thing about this is you. If you do it, you do get like really, really clear ownership outcomes. It has some disadvantages I'll talk about later. Here's how that ended up for us at Reddit. So, common question was what does an engineering manager even do while the core problem that we had was we had this role called a program manager.
And some of you guys might still have that. Particularly at smaller organizations, you may have program managers, but as you get bigger, you may split that role into product managers, feel responsible for customer, vision and straps. The who, what and why. And then engineering managers, people managing engineers who are responsible for architecture and execution.
And that was kind of the fundamental thing we needed to pull apart at Reddit. And and racy has helped with that somewhat. But it does have disadvantages. Disadvantages are it's very inflexible. So it turns out like some people can switch it, but you do have occasionally a person that can do more than one thing.
And now if you do this RACI chart, you lose that flexibility. And then the second thing is it doesn't address like a more fundamental issue, which is lack of trust. And I think that in, in a healthy organization maybe you don't spend as much time filling out these funny charts. You just trust people that you hire, who have particular titles and backgrounds to do the job that you hired them for.
So at Reddit we did we did have a little bit of that problem even after we went through. The exercise of making these RACI charts we still had to work a little bit on, on trust and I'll skip that slide and just go into what we did, you know, tactics for building trust. And I think, you know, when we talk about trust, the place you want to get to is you want to be able to say you know, that's not my job, but the person that we hired to do it is amazing, but what do you do to get right at Reddit?
We did a few things. I'll talk about three. The first is pilot teams. So I came in and I had a grand vision of how engineering should run. I had new ideas about processes and workflow, but I know as a new leader into an organization, I can not just blanket. Change everything you know, instantaneously the best way to build trust is to show an example, a small example, and then build from there.
So we actually piloted a lot of the ideas. I'm about to show you with a small team showed good output and then extended it to the rest of the company. Second thing is the next speaker actually helped us a lot with leadership offsites. So. When you're talking about teasing apart roles and responsibilities it really helps if all the people on the executive team are on board with what those new responsibilities are going to be.
So we actually had offsites, we didn't do trust falls, like I wrote here, but we did have deep conversations about the role of engineering managers, the role of PM, and then the rest of the roles in the organization. And that helped a lot. And then the final thing that really like punches it through. Is frankly necessity because when you talk about things like roles and responsibilities and org charts and dah, dah, dah, dah, if you're a 30 person team, it doesn't, you don't really see the need for it.
You're like, yeah, that sounds all highfalutin. Oh, Nick, he's just from you know, Microsoft that big gigantic company with all that process, trying to. So the way you get around that you just hire a hundred engineers and then you see what happens. Okay. Yeah. You want to run an engineering org with no word chart and a hundred people?
Yeah. Good luck. All right. So scale pressure and increasing complexity and coordination actually saw, you know, don't necessarily solve it, but it shows the need for this, this type of role delegation That's roughly what we did at Reddit. Oh, my slides didn't come out. Correct on here. I will I'll quickly like try and memorize the stats that were on this.
Here are the results. So read it no longer has tech leads or program managers. We've got 10 architects, 10 product managers and 20 managers. And then half of those managers that we engineering managers that we have were promoted from within and then, oh, of those 20. Only two decided to go back to IC roles.
So if you doubted my tests that I described earlier on, I have a 90 cent, 90% accurate accuracy success rate. And then the final thing, which is on the bottom of this is we actually got an org chart out of it. So if you go to read it, now we have orbs built around a particular investments. We want to make with leaders in key places, which is something we didn't have before.
But now we feel really, really good about okay. That's that's how we built up our management team and gave them roles and responsibilities. It turns out that's still not enough. You need a process, right? So if you meant a new manager, you still have to give them the tools to execute. And we'll talk about what we did there.
So just to talk about like, what happens when you're trying to scale an organization extremely quickly, there's kind of three things that start to get really, really hard. First is awareness. Everyone, as your aura gets bigger, wants to know what everyone. Else is doing, nobody likes to say what they're doing.
Second thing coordination. And I'll talk about this in more detail in a second, but there's more processes. There's more teams like you have to, everyone does really legitimately need to know what's going on in other areas because dependencies can cause big problems in your in your product pipeline, a bottleneck or miss dependency can essentially cripple your production roadmap.
So those are the things you have to deal with. So. As a as a, as a person coming in into an org, you might say, well, let me just drop ship a bunch of process on these people and see what happens, but that's not what I'm going to suggest if you ever find yourself in this situation. But first I'll talk about why.
You need to do this with a chart that I generated using my, the power of my MBA I got to give myself a hard time. So fundamentally, like you might think you just add more people to an organization and you're just increasing linear output, but in actuality, what happens is the more people you have.
The more coordination costs occur. And then you start to see output go down and actually start to decrease unless you make process changes or reorganize your team. So let me just show you what red rent it's processes were when I walked in the door, right. And this is a real. Okay. So this is our Reddit product tracker for one of the teams.
And there were 12 of these different product trackers, this product tracker, even though it is perhaps slightly hard to parse and most likely inaccurate does have some great cartoons on it. And we did spend a lot of the time and our spent review deciding what sort of cartoons would go onto the slide.
But you can see that this is a handcrafted. Google slide. So the likelihood that any of those pieces of data are accurate is pretty low. You know, some of these are coming from JIRA, but I can tell you at the time that we were using these slides, JIRA, wasn't uniformly used at the company. So whether or not you would click one of those links and get like actually a good day who knows?
Right? So this is what I walked into 12 of these slides looking at that every day. So I needed to add some process on top of that. Let me just give you some advice and caution about what to do. If you find yourself in this situation. First thing is you do want to avoid process junkies. If you need to Institute process into a new organization, I, I made a mistake once of believing a little bit too hard and an agile coach for a team for, for a team that I needed to, to build up.
And the guy came in, he, he laid out just a insane amount of process on the team, but it turned out that a process that he delivered was actually more about coordinating you know, between team members and it was about shipping code. So I'd go to their stand-ups and they'd be talking about whip limits, and they'd be talking about.
Everything other than like, did the customer get the product? And that's the thing I'm actually really passionate about. So you have to be careful. I don't just dump a lot of of process into your team. And I'll tell you a little bit more about that. Just to hammer the point home us, for those of you who are management nerds like me maybe, you know, about.
Where the original Kanban ideas came from there used to be well as there still is something called the Toyota production system. And you can read about this. I encourage you to read about it. If you care at all about management they had an idea called Kaizen. And the idea with that was you could be on the, on the production line in Toyota.
And if there was a problem, you pulled this thing called the . And the whole production line would stop. And the managers would emerge down from management heaven and come down to your line and they'd say, Hey, what's going on? And you would talk with the managers and invent processes there so that the error did not repeat.
So if you can imagine the cycle repeating you're going to build the only, the processes that you need from the bottom. At a very organic fashion, driven by the people who are actually doing the work. And and that's what I like about it. Second thing is, and I'll actually, I'll just leave this slide by saying the reason I like that idea is because over time, your process becomes your culture.
And I like to build organizations that are not overburdened by processes, but that are very, very flexible and adaptable. And I think that using this Kaizen technique, So let's see what we did at Reddit. Reddit as I said, didn't have any sort of, kind of engineering workflow when I dropped in. So I did come in with something very, very simple, a workflow that I've used on five other teams.
I won't read this entire slide, but six steps. If you are going to ship a new feature. Definition planning, staffing, execution, launch, and monitor. These are the steps. I think that, you know, most work needs to travel through in order to be done predictably and and with. So our it guy explained to me how JIRA works and you know, con and took that kind of rough flowchart and converted into a JIRA workflow.
And we gave it to this pilot team to see how things would turn out and it turned out pretty well. So I can show you where, where that took us. Now we have a team dashboard. So this is a, this is a view of all of the work happening within a particular team. Those numbers represent the number of active stories, if you will or features that are being delivered.
And you can see across this entire part of the organization which are implanting staffing, execution, or monitoring. And then you can also see at a glance which are blocked off tracker on track. So this gave Reddit the first kind of all up view of what was happening at the company. So really, really good, but actually line level engineers.
So it was really good for, you know, managers and directors, but didn't quite make it all the way down to the line level. So we modified a little bit, JIRA. JIRA has got this Kanban board system. You can see the same, like states going across the top. The difference is now if you're on any one of these teams, you can click in.
Here's our conversations team and you can now see all the major epics just for that team. So now what you'll see is for daily stand-ups if if you work at Reddit, you'll open up the main dashboard, you click into your team and you'll see the Kanban board for your, for your part of the organization.
And you can also do some cool stuff with your I'll. Just show you real quick. If I only want to know, like which things are off track, this is useful for me. You can have a couple of buttons at the top off track. So I can see in this media team, three things are off track. Still not quite good enough.
What about reporting upward? Right? What if I need to instead of having stand-ups, what if I need to be in a director and executive? So let's look at what we did there. For that I took JIRA, I added a Tableau extension. I'm a business intelligence guy, so I love charts. And with this, we've got a dashboard that can show a directors and above.
Across any part of the organization notes about epics that are in progress along with a little bit of metrics about how healthy that part of the organization is. And if you look across the top of the screen, this is fun. It's interactive. You can click on the team you want to learn about, and this, this whole report gets updated on the fly.
And then the final thing, because this. A little, still a little bit too much detail. The final thing that we did was executive level dashboards. We'll show you that. And this is a real-time updated executive level dashboard, and we brought back the cartoons and now we have complete buy-in from the organization.
So I won't go into that any further. This this is how we rolled out the process. And these are the tools that we ended up using. And I'll maybe talk through the results after one more thing, one more topic I want to hit, which is urgency. So even having all those processes in place, we still needed to execute and move quickly.
I want to just say a few things about urgency. When I came into Reddit, I noticed that there are many days when there were more engineers. In the room with our Nintendo playing smash brothers, then there were out on the floor writing code and there's a couple of different ways you can react to a situation like that.
You can get mad and go to engineers and like take the controller out of their hand. You know, but you should also kind of ask yourself, like, why does an engineer think playing smash brothers is more fun than writing code for one of the best websites in the universe. So I asked myself that and I think that In order to fix it.
There's kind of a formula that I'll describe. And that's the urgency formula. I think you'll get urgency. When you do three things, you give your ICS a clear mission where they understand what they need to do and how they fit into the overall goal. Like what they can contribute. Second thing is they need to know like how their work is going to impact some customer's life.
So one thing we started doing at Reddit was actually. Moderators content creators into the building to meet with some of our engineers or our product. And then the final thing is discipline. You know, I think that the best kind of urgency is really just discipline in disguise. So if you saw all those tools that we were using before using them in a very rigorous fashion will lead you to the appearance of urgency without a bunch of people having to stay late at night, which is what I like.
So to summarize. I don't think we we get urgencies from acts, acts, actually asking people to stay late. I think we get urgency from giving people inspiration. And then in terms of dates and when things need to get delivered, I have one other piece of advice I'll give you that is to say if you are a top-down kind of person giving your ICS dates to hit, I think you are doing the wrong thing.
And the reason I think that is because as an executive manager has gotten very, very high in the organization. The one thing I can tell you as that, all the people who actually know what's going on are right down there on the floor. Right? So if you need dates, estimate. You want them coming from the bottom up from the people who are actually doing the work.
And if you allow that to happen, one other really nice thing occurs. You can get those people to commit to the dates that they have given you themselves. So you aren't coming top down, demanding people do things by a particular time. You're asking people, Hey, given this mission that we need to hit, it's urgent.
It's important for the company. Can you tell me when it will be delivered? And as long as they're setting tough, but achievable deadlines. Good things will happen. So let's talk about the results. Like what happened after we did all this stuff at it. This is a chart of the JIRA epics that we shipped at Reddit over time by quarter.
Right. So At Reddit, I think that has like an eight X total increase. Since I joined the team and instituted this process, you might just say, Hey, well, you were hiring a bunch of people too. So, you know you know, you can easily get more output if you hire more people. That's why I circled these first two bars, because we had no extra head count between Q4 and Q1.
And we essentially almost doubled the output of the team simply by improving our processes and communication. And then in terms of what we actually shipped over the year. These are all the major releases that happened that read it over the past year, read there. The moderator tooling launched a new feature called profile pages, did an entire self-service ad platform, international Reddit, new video platform, new search, new chat, which just launched yesterday.
If you guys want to check it out and upcoming and in some indeterminate amount of time, which I can not speak to at this exact moment, a complete site-wide. It does say, man, come on. Is that as bad as not that bad? So all that's landing in 2017 more output in this essentially three, three quarters than Reddit has ever seen in the history of the company.
So what's next at Reddit? There's three things. I'll talk about quick. First is we gotta hire more engineers. So we're up to about a one 20 now. I think we'll be healthy at around one 40. So we're still hiring. Second thing is more product-based Reddit just simply put needs to be more welcoming.
Reddit has about 320 million Mau right now, but we imagine what it might be if the site were free. If people who landed on the platform could have an enjoyable experience where they could find content. That was interesting to them. So making the site more welcoming is the thing that we're really, really cranking hard on.
And then the final thing is more. So what are, what I mean by that? Well, pretty much every other social or new platform that you use nowadays you don't have to manually tune it to tell you what you're interested in. It simply looks at the things that you interact with and discovers your interests over time.
Reddit didn't have a data platform up until about five months ago. So we're generating five terabytes of data per day. And not using it to make the experience more personalized for each and every user. So one thing I didn't list on in that last side was we now have an entire team working on search relevance and personalization.
So with that calls to action, read a tiring you can follow me in a bunch of places and. I am doing a thing called color-code fund and there's one other thing I want to mention. What's not on the slide for black engineers in the audience. There is a group called dev color. If you're not in it, please join it.
It is the best organization for black software engineers in the bay area. Please join it. And with that, thank you so much.
Founded in 2015, Calibrate is a yearly conference for new engineering managers hosted by seasoned engineering managers. The experience level of the speakers ranges from newcomers all the way through senior engineering leaders with over twenty years of experience in the field. Each speaker is greatly concerned about the craft of engineering management. Organized and hosted by Sharethrough, it was conducted yearly in September, from 2015-2019 in San Francisco, California.