We’ve transcribed some of our most popular Product to Product podcast episodes for you to peruse.
In this episode, we chat with Nick Caldwell, who was the Chief Product Officer at Looker at the time we interviewed him. (Nick is now the VP of Engineering at Twitter.)
Nick will talk about his “toolkit” to successfully build an engineering org, which includes how to create a mission statement, figuring out what type of organizational structure is most effective and then he gets into the communication techniques he uses for growing companies.
If you’d like to listen to the entire episode, click below.
Highlights
(The highlights have been condensed and edited for clarity.)
What were some problems pertaining to product scaling when you started at Reddit?
Nick Caldwell: It was my first startup after a long 15 year career at Microsoft where I'd been growing pretty large engineering and product teams. At that time, Reddit was in the midst of hyper-scale.
Some of the key challenges that I faced when I got there was around the structure of the engineering team. I spent a lot of my early time introducing ideas and concepts around what mattered with respect to management. "Here's how you manage. Here's how you deal with people issues. Here's the operational tools that make sense to bring in when you're a manager to keep things being shipped on time with high quality."
You've talked and written about having a toolkit for product scaling. Could you give us a high level overview of what's in that toolkit?
Nick Caldwell: Every company is going to be different. So, the toolkit is not prescriptive! You have to pick and choose what makes sense for the challenges you’re dealing with.
The first thing is to make sure that everyone in your organization has a clear mission and set of objectives of why they're coming in to work every morning and what the definition of success looks like.
The second thing is to have a clear org structure. If you have a mission that you want to accomplish, form the right teams and make sure that those teams are well-resourced to accomplish the mission. The final thing I would say is some clearly defined mode and expectations around how you're going to execute toward those goals. That includes all the fundamentals around daily stand ups, weekly check-ins and what the rhythm of your business is to track your progress toward goals.
Why do you think this is often a challenge for companies when they’re scaling their products?
Nick Caldwell: There's a really important difference between vision and mission statements. Your vision statement at a high level is how the world will be different when you achieve your goals. Which as a company scales, gets super nebulous.
Have you ever seen the mission statement for Microsoft? It's something like "Empower everyone to work better." It’s super vague. When you're smaller, you don't have that. If you're a two person startup, your vision/mission is, "Make enough revenue and payroll in three weeks." It's very specific and practical. The challenge as you scale is that you get out of that survival mode, have more teams to coordinate and have lots of new objectives. Competing objectives also pop up and that can all get muddled.
The way I like to come into an organization with respect to vision and mission is to clarify that the vision is going to be separate from how we execute.
Vision is going to be this concept that's high level and very far out important to the world. But with respect to how we scale and execute, we're going to focus on missions. Every team is going to have a very clear mission about what they're doing day-today and what success looks like.
Mission to me is a very clear goal. It’s some idea of how you're going to do it and a time limit or a specific length of time you're willing to spend on it.
For us at Looker, we review the mission statement about every quarter. It's always present and fresh on what we're doing and why it matters. It's always urgent. It doesn't leave a lot of room for confusion about why people are doing what they're doing.
What are some of the ways that you guys communicate mission and vision regularly?
Nick Caldwell: There's lots of different techniques to communicate mission and vision. I will just say up front that none of them work really well. There's no silver bullet for this.
As your organization scales, it is safe to assume that at a certain point of scale, one part of the organization will not know or need to know what another part of the organization is doing. You may have helped out with sales calls when there were five people in the company, but at 100 employees, you don’t need to know what the sales team is doing.
There are different techniques you can use. The first one is repetition. So, if you're in a management or leadership position, just repeat the mission statement every opportunity you get in group meetings.
For Looker, we use this technique called cascading communications. I'll meet with the executive staff and we’ll decide on messaging and communication associated with our vision or themes for the year or other news that we might want to share.
We decide at a very high level what should be cascaded down to the rest of the organization and pass that down to our VPs. They put their spin on it and then pass it down to the directors and so on and so forth. Everyone eventually will get informed of what’s important and happening in the organization.
In addition, press releases work really well. If you have time, a bi-weekly or monthly newsletter helps too.
The other thing I do from a product standpoint is that we put our Roadmunk roadmap as the first page when you load our team site. If people want to know what's happening on the team at any given moment in terms of what we're building, it's always mapped out. Now, if you're outside of the engineering org, you might not be able to interpret exactly what’s on that roadmap, but it's always available and with pointers to who you can contact to understand it more clearly.
What were some factors that pushed you to do a new org chart at Reddit?
Nick Caldwell: I think when you go into most startups, they're going to have a fairly flat org structure.
When I joined Reddit, the org was very flat with only a few exceptions. There were only one or two people who were considered managers. And at that point, I think we had 35 or 40 engineers. What you see in those types of environments is that managers provide value. They provide engineers with cohesion, purpose and the ability to understand how their efforts line up to some broader efforts.
Even with that many people on the team, we used to have this meeting at Reddit where every single engineer and product manager would talk about the roadmap and what they were going to do every week. It was a 50 person meeting trying to talk through company strategy. That works when you’re 10 people, but at 50, you’ve got to do something else.
You've talked about how an org chart with 50 plus employees can be built in three steps. Can you walk us through that?
Nick Caldwell: It’s a little bit harder than three steps! (laugh) I use the analogy of building a house.
The foundation of your house will be shared services that are required by any product that you would need. It's not necessarily a product itself, but it's the tools and services that help you build products. This can be the shared operations team, a security team or even an API team.
You can’t build anything else unless these common services exist.
On top of that foundation, you build product pillars. The product pillars are "What are the major product components or the major units of product that you're going to try and put into the marketplace?" For Reddit, we had the website and we had a monetization strategy.
What are the big product areas that you're going to form product groups around? And then within each product group, you can talk about which teams are associated with that.
The third step on top of that are the investments you want to make that go across all product pillars. They're more outward looking. These would be your growth team and data science team. These are services, which are in support of building better products, but they're more about interpreting how customers are experiencing the product and using that data to help optimized product development or optimized product strategy.
To review: The first layer is your foundation, which are all the shared services and capabilities. Second is to use the mission statements and so forth to come up with product pillars that you want to invest in. And then finally, have an outward looking capability that's trying to understand and optimize how customers experience your product.
What are some of the challenges that you’ve encountered when hiring a lot of people very quickly?
Nick Caldwell: The first one is communications. It doesn't mean everyone has to know what everyone else is doing down to the lowest level of detail, but people need to know why different parts of your organization exist at a strategic level.
The second thing I would caution folks on is––we just talked about how to build an org chart. We made it sound like a very linear, like point A to point B to point C sort of thing. But you actually have to update your org chart very frequently.
A big challenge that you will have is a culture that it's okay to make changes in the org chart.
The faster you can make changes in the org chart, the faster you can address new customer needs. But the faster you make changes in your org chart, the more instability and uncertainty your team fields. You're continually trying to find the right balance for these things so that you always have the best people and the best organizational shape to meet whatever your current challenges are, with the caveat that this doesn’t happen so often that your team gets frustrated. Because relationships matter.
Sometimes when you do a re-org, it necessitates that you create or remove teams. You may have a re-org that results in removing managers from teams and that can really scare people. You have to be careful about how you make these changes.
When I have to perform re-orgs, I communicate it way in advance. It'll be two months ahead of time. I'll be like, "Hey guys, strategically, we should probably think about moving investments and people and money into these other areas. Why don't you help me think about how we can do that." If you have a healthy team that’s okay with transparency and that’s passionate about the broader mission, you’ll be okay. Sometimes you can just leave them with that challenge and they’ll do the re-org for you.
I've also seen it go the other way and it can be very unhealthy. I think this probably happens at larger teams, where sometimes you'll get people who view re-orgs more as an exercise of empire building. They're not putting the goals of the company ahead of their own personal goals. You have to be careful if you see people trying to do that because it can happen unintentionally. You can have a very well-intentioned person who might just think like, "Hey, my area of the product, which I've been working on for a while, and I'm very passionate about is super important. So, I'm going to try and optimize for getting more people and resources and so forth into my area." And they lose sight of the big picture. So that can be stressful.
As your team is scaling, it gets harder to coordinate all these people who are trying to get stuff done. Can you talk about the concept of coordination costs and how they can hinder a team's ability to execute?
Nick Caldwell: Coordination costs are this idea that if everyone needs to talk to everyone else, over time, it’ll be the only thing they spend time doing.
In order to overcome coordination costs, you cut communication lines, but make the existing ones stronger or at least more trustworthy.
If you look at your org chart, ask if it matters that product group A knows everything that product group B is doing.
Or can we just say, “The mission and output expected in three months from product group A is the following.” And you can trust that the tasks will be done and that you can just regroup in three months.
Is there anything you’d like to add to the discussion of scaling a product organization?
Nick Caldwell: For people in positions responsible for large organizations, it’s very easy to get lost in thinking of people on your team as resources or these apps.
We're doing re-org planning right now at Looker. We have like 250 people that we've got to move around. We're doing this all on a spreadsheet since it’s a large number of people, but if you only make decisions that way, you lose sight of what people's individual passions and motivations are. You’ll end up with a less effective organization because ultimately your job as a manager or executive, is to deliver business value, but I believe you deliver the best business value if you can get alignment between business and what people are individually passionate and motivated by. You have to always keep those things in balance if you want to get the highest output.
It's like the hottest part of the flame is the blue part––the part where you got the fuel and the oxygen mixing in just the right way. I think the same thing translates when it comes to organizations. You want to get people's individual passions and motivations lined up with what the business needs are so you get that blue flame output.
[Closing CTA: either to a related piece of content (currently nothing on metrics) or a highlight of Roadmunk’s value props to PMs + 14 day trial prompt]
Ready to learn how a roadmap should reflect the product strategy and product vision? Check out this post.