Nick Caldwell on the engineering cultures that power Microsoft, Reddit, Looker & Twitter

EP.30 Nick Caldwell

Nick Caldwell: [00:00:00] Engineers are often asked to go work on things without being explained to why they matter to the business. Just go build this feature and they're often asked to maintain or keep legacy code alive without understanding how. Every minute you spend explaining to an engineer of how it benefits a customer or how things ladder into the overall strategy.

A minute.

Brett Berson: [00:00:35] Welcome to in depth, a new show that surfaces tactical advice, founders and startup leaders need to grow their teams, their companies, and themselves. I'm Brett Berson, a partner at first. And we're a venture capital firm that helps startups, like notion, roadblocks, Uber, and square tackle company building firsts through over 400 interviews on the review.

We've shared standout company building. The kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast in depth, you can listen into these deeper conversations every single week. Learn more and subscribe [email protected]

for today's episode of in-depth. I am thrilled to be joined by Nick Caldwell. Nick is Twitter's VP of engineering, where he leads a 700 person team responsible for all of Twitter's consumer facing products. This latest role at Twitter is another step in an already storied career in engineering leadership.

He started his journey at Microsoft, where he worked for 15 years, rising up through the ranks to eventually become the general manager of power BI Microsoft's business intelligence. Next. He pivoted from enterprise and took on hyperscale by joining Reddit as its VP of engineering. He then returned to his BI roots by joining Looker as its chief product and engineering officer leading the org through its acquisition by.

Between Microsoft Reddit, Looker, and now Twitter, Nick's worked for companies with vastly different cultures. And in today's conversation, we comb through the biggest lessons from each of these orcs. With Microsoft, we unpack what Nick believes is a massively underrated approach to organizational design.

He explains the company's rigorous approach to regularly pruning and shaping the org chart. He also gives us an inside look at their management training and talent development, as well as what Nick calls the fairest performance review system he's seen. He also shares some advice for startups from Microsoft's approach to deeply understand and competitors.

As Nick tells it, there was a steep learning curve when he pivoted from 15 years at Microsoft. He doles out advice for others getting their bearings after a big career move. He also explains how Reddit's mission-driven culture informs his approach to leadership at Twitter. Finally, with Looker, Nick unpacks, his biggest lessons from leading both the product and engineering teams, which offered him a unique perspective on how these orgs that are often at odds can properly.

It's an incredibly wide ranging conversation. So there's something for pretty much everyone, whether you're interested in the cultural practices that power, some of the world's biggest companies, or you're a manager looking to level up, or you're an engineer with goals to take on leadership. Nick's got plenty of advice and insider stories.

I really hope you enjoy this episode. And now my conversation with Nick, thank you so much for joining us. I'm excited for our time today. 

Nick Caldwell: [00:04:07] Yeah. Glad to be here. Thanks for the invite. I've been looking forward to it. 

Brett Berson: [00:04:11] So one of the places that I think I thought that might be interesting to start and explore is having you reflect a little bit on the different cultures that you've worked in, because it's been an interesting journey starting with the first big chunk of your career at Microsoft.

And then read it and then look her into Google and now Twitter. And so I was curious when you think about each one of those chapters and you think about the culture and to be more precise when I'm using the word culture, I'm meaning like the way in which work is accomplished or what gets rewarded or all of the ways in which people work together to create some kind of outcome or the way in which people behave.

I'm curious what you've learned or observed because. Many different companies have different scales with very different cultures, all very successful in their own, 

Nick Caldwell: [00:04:59] right? Yeah, for sure. And those are all radically different cultures. I think part of the joy I've had over the last couple of years of my career is getting to learn that there's a lot of different ways to ship software and a lot of different ways to lead and get things done.

I can run through some highlights from each of them. I didn't appreciate it at the time, because it's hard to understand the culture while you're in it. But Microsoft is phenomenal in terms of how it approaches organizational design and any other place I've worked relative to Microsoft has been less effective.

Forming teams, forming business units, understanding how to move people and resources to whatever the most urgent problems are on a regular cadence with some predictability tied toward a mission, vision, et cetera, that place in retrofit. Runs like a well-oiled machine it's clockwork in terms of how vision translates to strategy translates into org design, translates into people moving, et cetera.

And they do all of this while also maintaining a bunch of legacy or older products as well. And I appreciate that in retrospect, I think they're like the modern equivalent of like a GE in terms of. Just being good at organizational design management and so on and so forth. And it doesn't get talked about much publicly, but I think that is Microsoft's cultural superpower red.

It was the first consumer social software company I worked at. And that was where I sort of came to appreciate two things. And it maybe a bit surprising Reddit when I joined. Incredibly passionate about building a diverse team and had started to Institute a ton of mechanisms like hiring diverse leaders, changing how the hiring funnel worked so on and so forth.

And it was the first time I got exposed to accompany aware. If anything like the values came before, the product that they were making. If that, if that makes sense. And everything that we did was through the lens of does this ladder up to our values as a company, that the second aspect of that was just being very mission aligned.

The culture at Reddit was really around knowing that the site had been attracting deeply passionate users and moderators for more than a decade. And wanting to serve them and the employees at Reddit up until very recently weren't as concerned about business growth and so on. Like they, they were there because they just simply loved the mission of the company.

And then later on when Reddit started to expand and attract investor money and so on, so forth the monetary and growth objectives, intersected with the mission objectives. And I think they're off to the races now, but that was a real. Interesting deviation from Microsoft, which is ultimately like a big box, big business company.

And, you know, they, they're very competitive and red. It wasn't competitive in that way. Looker, for those of you who don't know, Looker's a BI company and the headquarters is in Santa. This has this introduced a bunch of like cultural oddities that I've not experienced anywhere. And I think it has to do with the fact that the headquarters was in such a remote location.

Santa Cruz is hard to get to, you have to drive through a two lane mountain paths to get there. So most of the employees live in Santa Cruz and Santa Cruz is characterized by. Kind of relaxed beach culture, if you will. Everyone knows everyone else. So with Looker, it's just going to sound very odd, I think, compared to how other companies talk about it.

But Looker is the first place I've worked, where I heard the CEO and exec team talk about the company being a fan. Every time I've ever heard that in any other context, I go, ah, full of shit doesn't mean anything. Looker is the first place I've worked, where they said it and they were genuine about it.

Like they genuinely cared about the employees in a way that felt familiar. And I saw activities from the CEO and the CFO there, which was. Just heart melting. I mean, like just the things that they did for the employees there went so far above and beyond what I've seen at any other corporation, like taking care of employees who got sick and, uh, looking out for each other in ways that went above and beyond.

I remember that too. I killed a bit of the cynic in me to see the leaders at that company and how they operated. Look, I got acquired by. And Google to all surprises that I, it was absolutely stunning to me as someone who never worked at Google. And if you're from Microsoft for a long time, you looked at Google as this super agile competitor.

At the time I joined Google really felt like a gigantic company. It really felt like it had all of the big company, innovation dilemma, bureaucracy that Microsoft had without. The skill of organizational design and so on and so forth. So I wasn't there for very long. And I think that Google is undergoing a reckoning on this right now.

I've, I've read a couple of news articles lately questioning their operating methods and so on and so forth. So I don't have a lot of detail on that, but it was shocked to me. I was expecting a culture. Characterized by innovation and what I saw it was not that, and it was a very surprise to me. And I've been at Twitter for a year, Twitter and Reddit have extremely similar mission-driven cultures with Twitter.

It's a little bit more on the nose though, because Twitter as a platform is. Something that surfaces all of the world's events, as soon as they happen, people go to Twitter to talk about what's happening in the world. And there's a lot of wild stuff happening in the world. And people at Twitter inherently understand that the power of this platform, that if you think about communications systems over the course of human history, from the printing press to radio, to TV, And so on, but each of these has allowed people, a new lever to reach a broader and broader audience and Twitter and social media are the latest incarnations of that and their orders magnitude more powerful than, than anything that has come before.

So everyone in the company sort of has this intrinsic understanding of the importance of the platform that we enable public communication in a way that is more powerful than any point in human history. And that has to be made available. As safely and responsibly as possible. And we see the impact of either success or failure toward that goal around the world in real time.

And this mission underlies everything that we talk about the company in a way that overcomes a lot of other faults that we might have on execution or problems. Like the mission binds us together. That 

Brett Berson: [00:11:42] gives us some great points to jump off. So the couple things I wanted to chat about in a little bit more detail, I wonder to go back to your reflection of Microsoft and maybe have you describe what great organizational design looks like or stories that come to mind.

And one of the things that I think is just so. Under appreciated about Microsoft is the diversity of the businesses that operate under Microsoft. And they are just the world's best modern example of a multi-product company and a multi business line company. And I assume to your point. There's a lot of organizational design.

It's a lot about the type of people that they hire, but we'd love to hear you particularly given you were there for such an interesting, I think 15 year period. If you were to teach someone how it works or explain what the organizational design philosophy or how it shows up there, what that might look like.

There 

Nick Caldwell: [00:12:37] are some drawbacks to this too, if you want to cover them later, but a good parts of it. What the org design looks like is it starts with, as you mentioned, Uh, Microsoft is broken into multiple business units and they change these over time, depending on how they want to tackle the market or report to the street.

But you can think about windows, cloud, gaming, office, Ike, these sort of product families, and each of them is generally speaking. Multi-billion dollar internal business with even larger partner networks. So with that framing in mind, the company has to figure out a way to organize its resources. To address all of those business needs and the mechanics of how this works.

Are trying to say it, I'll try and simplify it within a particular business unit. You've got a silo or a VP who runs it and he'll have a, he, or she will have a corporate exact reporting into them and so on and so forth. But every business unit then breaks out, down into product families, and then within product families, product units, individual products, and then down from there into technology teams, feature teams.

Et cetera. And then in some cases there are support teams which provides shared technologies to all of the above. We're talking about within one product line, you get that entire tree of organization. What I'm describing here, you can look in the org chart at Microsoft and map back out what products are being used.

And there's a common saying, like, don't ship your org chart, but this is incorrect. Actually you should try it and ship your org chart. It's just, you need to have fluidity in your org chart to make sure that it maps whatever product or objective you're trying to achieve. Going back to what I said earlier, Microsoft on a very regular case.

Changes the org chart, like where the people sit, which products are owned by a particular product manager, et cetera, and communicates these changes very clearly, very succinctly like on a regular cadence. So you might expect that every quarter or every six weeks. That there will be some reorg announced by your executive and it will be backed up by, you know, Hey, we're doing this because we're going to go after this particular business strategy, or we need more people to, to shore up investment in this area.

I keep it at that level of detail, but it's a regular cadence. Of pruning and shaping the org chart to match whatever the product or goals that we're trying to get are secondarily, there are support teams. One challenge I see with many companies is that they neglect sustained engineering tasks or software fundamentals tasks.

Microsoft has an entire. I won't call them a product team, but there is an entire division which does nothing, but take care of internal tooling, software development, life cycle, et cetera. If there are products which are in sustained engineering mode, which has reached the maturity phase and will now no longer have any new feature development, but still need to be maintained.

Teams are formed to maintain those so that they're taken away from the responsibility of your main line product teams. This massively simplifies resource allocation in ways that don't quite exist at other companies. The final thing, which you may say as a pro or con, this entire structure and system is replicated for every major business unit.

Now. Pros of this are that the team working on gaming doesn't have to necessarily coordinate super tightly with the Bing team or the cloud search team. They can operate independently, run their own businesses. They have their own P and L et cetera. The downside of this, which is Microsoft is famous for, is that.

These teams might end up creating competing solutions to the same customer problem. And this is where I don't know if you've seen this funny diagram on the internet where they try and show a picture of the Microsoft org chart. And it's like every business unit has a gun pointed at the other business unit and.

Does happen. So like while Microsoft is very well organized to solve particular product lines, challenges that they can often come into conflict with each. So it can be a little bit territorial sometimes. And Steve bomber, who was the CEO for a long time, actually embraced this. You want it in multiple competing solutions with Satya, that's been less a part of the culture and he looks more for one Microsoft approach where all of the business units sort of aligned to overarching shared goals and reduces some of the conflicts.

Okay. Awesome. 

Brett Berson: [00:17:09] That was great. So how does zero to one product development work in the org design for 

Nick Caldwell: [00:17:16] zero to one projects? The simple all answers doesn't work really well because Microsoft's a big company and any large company, Microsoft, Google, et cetera, is going to have a challenge with doing zero to one projects.

In general, there are two or three ways you might tackle them. Forming a V team or a spike team or pulling people from across the company into kind of a seed team and then isolating them and allowing them to focus on getting that new product that out the door is generally the approach that Microsoft uses.

In the past, they would do similar things through labs teams or entire organizations would sort of simulate it, startup incubators, but that pattern generally didn't work and as been abandoned by most companies, but a pattern that's frequent is to pull people together for a new initiative, spike on it and try and get to a V1 as quickly as possible.

The reasons. Tends to not work is in a big company. Anything that you might do in terms of making a new product could impact existing business lines. So if you're a PM at a big company, you can't just ship a new thing. I was on the power BI product at Microsoft, which was a zero to one BI tool, which is now quite successful.

But in the early days of it, when we were talking about building a new data visualization tool, We had to go and clear that idea with multiple teams like that would be impacted from office. The obvious ones are Excel, there's existing BI reporting tools, et cetera, but to even get moving on the concept, we had to clear a path to understand whether or not our product would cannibalize.

The preexisting business and you had to overcome a lot of inertia there. Even if you manage to do this, you have to sort of, it's not like a one and done, like you have to make time in your schedule or product roadmap to continually sort of carve out space for your zero to one. Until you manage to get to product market fit or some acceleration, but the best iterations of zero to one projects I've seen at Microsoft where pull the team together, spike as fast as you can, and then use middle managers and execs to provide air cover so that the folks who would claim you're cannibalizing, their business are held at bay until the team has enough time to get a fair shake at whatever they're trying to do.

So, 

Brett Berson: [00:19:40] given that we're talking about Microsoft, I was interested. Are there other things that you've taken away? Or things that Microsoft did exceptionally well, that you've taken across your career. And I'm interested in the topic because I think that Microsoft is the most misunderstood or it's a company that operates in a very particular way that most companies in Silicon valley don't study.

Right? Like if you think about the way the Google operates. It's washed over almost every company in Silicon valley. And even over the past, call it five or 10 years, Amazon, I would say with some of their cultural practices, the way they operate an organizer more well understood. But Microsoft is a little bit of a black box and given the incredible success over such a long period of time, I was interested in any other practices or primitives that you find useful, or maybe founders today should be looking and studying and getting inspired.

You're 

Nick Caldwell: [00:20:36] totally correct. And I've been in the bay area now, I guess for six years, I see what you're saying all the time, your Google management practices, the Amazon culture deck, all of that is really held on a pedestal. But my honest assessment of those things is that pale in comparison to the effectiveness of what Microsoft does.

And I have no idea why Microsoft isn't more open and about their practices. So there's. Maybe two other things I would say that they do extremely well. Microsoft scales through manager training. They have some of the most effective leadership development programs, the most effective leadership development programs I have ever seen in the industry.

And I've worked in several places and this comes from identifying top talent. They have what are called high potential programs. Other companies have this as well, but at Microsoft, they start very early on and there's a high potential program for every single career stage. So if you're an intern, a relative new employee, a senior employee, Staff level, there's a program for every single level to nudge you toward excellence at whatever that layer might be.

Additionally, Microsoft going back to org structure. They're one of the few companies which has career paths for ICS that go all the way up and they're clearly defined. And similarly they have career paths for managers, which lead into general men. So when you talk to, I don't want to pick on Twitter, but like every other company, every other company I've worked at has career paths that stop at being a great IC engineer or a really great engineering manager.

Microsoft's career paths lead into general management and then executive leadership. And there are book length analysis of it, like posted on their HR site. Learn quite a bit about management from the ground floor, all the way up to the highest levels, just by spending time on their learning sites. So long story short, their ability to develop managers as a superpower.

And to your question about what should people study? Microsoft doesn't publish these things publicly. I wish that they would just publish how they approach job ladders and management training and so on and so forth so that others could simulate it. But if you want to see a company that I think inspired this, I think it's actually GE I've read some Jack Welch's books and looked at how he developed leaders and how he structured his business units and so on and so forth.

And a lot of that, I would bet was picked up by gates and bomber in the early days to form Microsoft. And it seems to inform a lot of their management practices. Now, again, when you go do this, I'm not saying like replicate GE management tactics. Like these are very outdated right now. It just mean that the focus on management development and good organization performance systems.

I think there are seeds of all that content within GE that Microsoft picked up and has evolved over the years and just super briefly, cause I just reminded me of one other thing. Microsoft used to have a really atrocious stack ranked performance, the review system. Uh, 

Brett Berson: [00:23:44] I was going to ask you about this.

This was my next question. 

Nick Caldwell: [00:23:47] Yes. And I was going to say they got rid of that about I guess, seven or eight years ago and replaced it with what I've come to believe is the simplest most straightforward, fair, equitable performance review system. I have seen since, and I've tried to reproduce it in every place that I've worked and I just wished that they would publish what they do.

Simple easy to use fair tracks performance over time puts control levers into the right layers of the organization. So on and so forth. So I wish I had artifacts I could share about these things, but again, Microsoft is not right. Talk about its systemic approach to developing managers and performance in the way that other companies do.

And I wish they 

Brett Berson: [00:24:28] would. You just mentioned how impressed you were with that performance management system and how it's something that you've adopted. Could you explain the primitives there or how it works and maybe why you think it's a powerful way to do this type of. 

Nick Caldwell: [00:24:40] So there's a couple of different elements to it.

First is how you assess yourself. Other companies use an OKR framework where it's very rigid. Did you hit this metric or so on and so forth? Microsoft has elements of that, but it's more introspective. It's more. Did you hit your personal goals? Did you hit your business goals and you fill out at a very high level, some goals alongside input from your manager that you want to achieve.

And you check on these things once a quarter, a basic starting point is this quarterly check-in, and then you may have metrics associated with those goals, but some of them are literally just personal development type tasks. You're encouraged to do those as well. Every so often you're going to have a performance review that is tied to.

Compensation as well. And here you need signal and input and that's how much of your goals did you achieve if you have metric-based goals or business related goals, what were the outcomes? How did they affect the business? Like all the things you would sort of expect because quarterly checking. Are happening.

You have a trajectory that's collected over time. So it's not just this, like every 12 months, you look at this long list of goals or OKR is, and that's a one point in time sort of thing. You can look backwards at the person's trajectory over however long they've been doing performance reviews and get an assessment of their momentum.

And this provides a lot of additional signal managers at a certain level, have the ability to have discretion over reward. So there are differentiated rewards. Like many companies have, but managers are given responsibility to spend budget toward their top performers and take away budget. If someone's performing at a lower level, all of this then gets reviewed.

Phenomenal oversight. So when you make your budget recommendations as a manager, they roll up to your director and then they roll up to your VP. HR overlays their checks on top of all of this. So that promotions are distributed equitably. We check that diverse employees are not being missed. So there's sort of a layer of oversight that goes into all of it.

And then additional. You can use this Florence review system too, because it's differentiated, uh, to signal when employees are performing really well or performing poorly signal that, and it all happens on a six month clock and you're constantly aware at all times. Of your top performers, your low performers, you're simultaneously rewarding people at a good rate.

And it's all done in a way that is, um, tracking equitable distribution at the same time. 

Brett Berson: [00:27:20] What are the primary benefits of this system? Or maybe how you would compare it and contrast it to what might be a more traditional 

Nick Caldwell: [00:27:28] model? I actually don't know what traditional isn't it. So I worked at five companies and they all had different that's fair.

Yeah. But the benefits of it are, it's a predictable case. You collect signal. If you get a new manager, for example, Without having clear history and consistent signal that new manager may have a different assessment of your performance or a different rubric that they're using with this system. You're over time collecting a history that includes your performance or feedback and your trajectory.

So it gives you a record that better informs your performance review at any given time, the predictable cadence of it, the fact that there's oversight, you can not run through this process and result in an outcome that right. Have an unfair inequitable distribution. Whereas in other companies we don't necessarily tie the oversight from HR into the performance review systems.

You run that risk. I like the fact that it starts by. Putting the onus on the individual employee to come up with personal goals that a track record gets developed and that it results in something that has equitable oversight. And it provides, again, signal to the management team about who the top and bottom performers are without being.

As onerous or obnoxious as a stack ranking system. So you're not operating in a culture of fear 

Brett Berson: [00:28:51] in the stack, right? The main downside is the Lord of the flies competitive dynamic. That's right. 

Nick Caldwell: [00:28:56] Yeah. Most of my career, well, early career before they switched was in stack rank meetings for performance reviews.

And those were very contentious and combative. You're essentially trying to go into those meetings. Not just to lift your team members up, but to find ways to pull other people down so that you can protect your top performers. And the dynamic of those meetings was never. Healthy. The intent, I think, was to find differentiated rewards and look for poor performers.

But the way in which it was done was frankly, unhealthy and combative and glad that they got rid of that system. 

Brett Berson: [00:29:33] The threat, you mentioned just a few minutes ago about Microsoft manager training and clarity around managers. I was interested. Maybe you could share, how would you define a great manager as defined by 

Nick Caldwell: [00:29:46] Microsoft?

It depends on the role that you're in, but at the highest level, a great manager is going to be able to define a strategy and execute against it effectively. And depending on what their discipline is, you know, engineering product, et cetera. By pulling together the necessary people into a strong team, coordinating with the cross-functionally dependent teams and then tracking toward clear progress.

So management at Microsoft is around coordinated execution. It's like a big ship, a lot of players on it. And you got to figure out how to get them all on the same page while marching toward a clear goal. And then related to that is. Doing so in a way that develops people's careers toward being excellent in whatever their function might have to be.

And then the final thing is that Microsoft is unique to other companies in the bay area. Is that if you're in management, if you're in a management role, You may start in engineering. You may start in product, uh, but you can lead your career toward general management in a way that allows you to have control over multiple disciplines.

Your career doesn't end at being a great engineering manager, your career. Is really only the beginning. You shift into a mode where you become a business leader and Microsoft has the ability to grant. If you're a corporate vice-president, uh, you can own a P and L inside this large multinational multi-billion dollar company, you can work your way up into that role in a way that's clear in the job ladder.

It's not, if you look at other companies and wonder like how they become VP. That path is not always clear, but in Microsoft you can start from almost any discipline and work your way up into owning a piece of the business. And that entails multi-function leadership, go to market, et cetera. That is unique.

And what I've seen in the industry, there's maybe a couple other companies that have the size and scale to do that. But Microsoft, I think is a great, 

Brett Berson: [00:31:44] and so in that case, you basically wind up with a whole group of mini CEOs running their own businesses. 

Nick Caldwell: [00:31:51] Exactly product unit managers or CVPs or general managers, or however you want to call it.

But one hallmark of companies that I think managed to innovate and execute really effectively is the deeper in the organization that they allow general managers or product unit managers to emerge. The more that company will be able to tackle new product areas or innovate. Amazon is actually an example of this.

We haven't talked about a lot about Amazon, but Amazon allows GM's are multi-discipline managers fairly low in the organization? I would credit them with being able to execute very, very rapidly. I think it's a hallmark of their culture. You see a similar thing at Microsoft, maybe not at as rapid of a pace, but a similar sort of pattern.

It's no coincidence. Microsoft and Amazon do share some organizations. 

Brett Berson: [00:32:38] Before we move on from Microsoft. Are there any other insights or lessons that company builders in Silicon valley should be taking from the way in which Microsoft operated 

Nick Caldwell: [00:32:49] within the startup community? I think there's one thing I would say, which is Microsoft was relentless in terms of its understanding of competitors in the market.

And I think when I talked to early founders here, or even some experience founders, I think they. Maybe overweight, technical cleverness, or a product idea without fully understanding what's come before or how other competitors are situated in the market. And that works to the detriment. The more you can understand the landscape, the more effective you're going to be.

And Microsoft had entirely. Teams of people doing nothing, but understanding competition and crafting strategy and so on and so forth. It's not to say that you need to do that as a startup, but I often hear advice from VCs or folks in the star community that you just have to power through and ignore your competition.

But for certain spaces are crowded markets like data and BI and AI. It really helps to understand how your competitors are positioning themselves so that you can carve out a niche to be successful in. They did a amazing job at understanding the landscape before diving in switching gears 

Brett Berson: [00:34:00] just a little bit.

One of the things I was excited to chat with you about is the interplay between product and engineering. You're one of the few leaders that, you know, you mentioned in the backside of your time at Microsoft, you were a general manager. And then you were an engineering leader. And then I think you were an engineering leader in product leader in the case of Looker.

And now you're an engineering leader. And so I was interested given that you've worn both hats at different times at the same time. What has that taught you about each function in the sense of now that you deeply understand product and we're responsible for product, how do you behave differently? Or what do you see differently when you're wearing your engineering leader hat and maybe vice versa?

Nick Caldwell: [00:34:42] That's a deep question. Over the course of my career, I started in engineering and early on, um, really had no clue like what product people were supposed to be doing. I thought that code solved everything. And obviously we can't ship anything without code in our line of business, but I overweighted it because I didn't understand everything that went into getting the software out the door and into the customer's hands.

So if I had to characterize what I've learned. Playing each role product's job is to synthesize from a wide, wide variety of inputs, customers, market strategy. In the case of Microsoft, we talked about going across organizational boundaries and getting inputs, but trying to look across a very wide variety of input signals, synthesize that into a winning strategy.

And then influence the organization engineering PMM, but go to market functions, influence all of those, to agree with your strategy and then form their organizations around it. And the challenge here is that each of those different groups of people or inputs has different interfaces and motivations, right.

PMMS think very differently than engineers think very differently than designers and so on and so forth. They're incentivized in different ways. They have different group bricks for how they judge their success and product people sit in the middle of all of that and have to figure out a way to corral it all toward whatever your product goal might be.

And it's a maddening, multidimensional, never ending chess game in that way. And, uh, I've come to later in my career. How much challenge goes into that synthesis, particularly when, after you do all of these things, it may still add up to a product that doesn't work. So all this, all this energy and, you know, it's, it may not work for engineers.

I think the interface has to be that engineer. Are often asked to go work on things without being explained to why they matter to the business. Like just go build this feature. And they're often asked to maintain or keep legacy code alive without understanding why or how it contributes. And every minute you spend explaining to an engineer, the why, like how it benefits a customer or how things ladder.

Into the overall strategy a minute well-spent and that has to be the interface. In many companies. The engineers are sort of, you know, lock them in the basement through a pizza and every once in a while and hope code comes out. Um, but I, I don't think that's how you get the best, uh, output. The best output is when.

Engineers can trust that the PM's have a great understanding of the market and why they're doing things for the customer. And that, that gets expressed to them in a way that ideally is inspiring. But if not inspiring, they at least. What their work is laddering up to. And then PMs are looking outward and trying to collect and synthesize all of this information.

And their skill set has to be balancing data and intuition to come up with the right roadmap and being able to explain that in a way that resonates across multiple. Functions. It's a very challenging balancing act. 

Brett Berson: [00:38:06] So, I mean, you're hitting on this, but if you were to look at the way that you run and lead an engineering team, or you run and lead a product team, are there hallmarks of the NIC way of doing those things?

Nick Caldwell: [00:38:19] Yeah, for a lot, my way of running product and enj comes from my time at Microsoft. And I like to win. So I like to come up with winning strategies and get people inspired by them and line up around those strategies, like build an organization. And then relentlessly go after that strategy. So when we talked earlier about analyzing competition or building the right org structure and so on and so forth, if you drop into any organization that I'm running a product on any way, you will see that we're spending every quarter doing an assessment of our strategy and strategy in my mind is what game are we playing?

What game? Why are we here? What does winning look like in this game? And then what are the tactical things that we're going to do toward victory and how can we measure them? And when we've agreed upon all of that, do we have the right organizational alignment, not just across engine product, but across all functions within the company to achieve whatever that goal is.

If not, let's make that change right now and then start executing. And if we're wrong, we're going to do it again in a quarter. So those would be the hallmarks of what you see. Let's. And let's acknowledge where we're not winning and adjust as necessary until we get there. And that results in a lot of focus in the teams that I run and a relative rigor on execution.

So maybe a downside for this would be, I don't have a lot of teams off doing exploratory innovation process. Anything new that we would do would have to ladder up to the strategy. So it's not to say that we wouldn't do brand new things. It would just be like, has to make sense within the overall framing of our strategy.

And then once we decide to do it, we're going to put as much wood behind that arrow as we can and make sure that it works. I like the focus when I joined start-ups, you know, Reddit Looker, you generally don't see that level of focus in a brand news. Tend to be more exploratory. When I joined Looker, I remember there was a saying on the edge team, the engineer has pen and because Looker was a very data engineering focused product engineer had the pen meant that the engineers on the team had the best understanding of what needed to be built.

And I changed that attitude pretty quickly toward, oh, the customer has the pen customer is going to tell us the right thing to build, and we're going to focus around that and build. As quickly as we can toward what they're asking for. Can you 

Brett Berson: [00:40:52] maybe tell us the story of what this looks like, maybe end to end over the course of a quarter at some point in your career, when you thought this was really humming, 

Nick Caldwell: [00:41:01] this.

The best I've seen it done was likely at Looker because the CEO explicitly was like, Hey, Nick, come in, set up a, set up an R and D cadence. Like that was the reason I was brought in and what we did there because the team hadn't really been operating with a clear roadmap was very quickly. I determined we need to add.

Some understanding of what a roadmap is, what value it has and build some cadences toward developing and maintaining that roadmap. We had to do it really quickly. So the framing that I used was we're going to start with Frank. That comes from the top down, like the exact layer, like in general, what, here's the strategic landscape as I see it.

And in one page, I'm going to describe some of the opportunities that I think are ahead of us for Looker at might've been addressing some of the technical debt. They had moving toward a developer platform, you know, a few other things, but just kind of a super high level framing. Then asking the teams to come up with ideas and strategies toward contributing to that high level set of goals or pushing back against them over the course of a two to three week period.

And what this would result in would be strategy memos, those strategy memos for Looker. I think the initial ones came back. Yeah. Hey, we need to redo our data visualization layer. It's outdated. It's customers comparing us to more beautiful looking platforms. Another one was like, Hey, we're seeing a lot of people building applications on our platform, but they don't have formal support.

Maybe we can build apps into the product. And another one was the core product analytics just has a bunch of improvements, a backlog of improvements. Analysis and language capabilities that will delight our existing customers and one or two other things. So we got some strategy documents, which outlined how we're going to win.

And then we look at our org chart and ask, do we have the right setup? Do we have the key leaders in place to meet each of these objectives? Fortunately it Looker. Like we. Had people on staff who were able to hit all of these goals, it was just a couple of minor tweaks we needed to make, you know, make sure that the funding levels were right.

Make sure that people who are passionate about any of these particular areas, got an opportunity to move into them for certain areas, which were a little more controversial, like changing out our visualization and tech stack. Well, now we know that's going to be a bet, so we let's get people who are passionate about that into the right place and ensure that they have top-down support.

So on and so forth. So like positioning the work and getting people ready to execute the strap memos, then get converted into roadmaps. This was the most challenging part because the company had not done it before. But imagine for every one of your major pillars of investment, you then need to break that down into thematic areas.

Say you want to change out the front end of the tech stack? Well, that's going to be. The medically we need. New data is one, two. We're probably going to need a new layout engine so that we can display reports to three. We're likely going to need a way to address all of the existing tech debt and older reports.

So how are we going to do migration? So three or four different thematic areas. We then assign those thematic areas to teams. So they can tackle them directly. And then they fill in the roadmaps with specific items, the roadmaps that we would generate need to be accurate. So I like to run teams that have predictability, and I like to ensure that anything within a three month or quarterly window is more than 80% accurate and, um, uh, held the team accountable to that.

Anything after three months, Can be less accurate because we're going to do this quarterly exercise. Anyway, we're going to come back to it and refresh our plan. So if we're less accurate and a quarter doesn't matter as much, anything, six months. Yeah. That's too far to predict. So we put it there. If customers ask us about when we're going to do something, that's not on the immediate roadmap, throw it into the six month bucket, but that's so far out, we don't really need to worry about it for most cases.

And then we start the clock. We start executing, we've got our teams formed. We've got tragedy with a clear roadmap. We got tight deadlines that we believe we can hit within a three month period. I'm glossing over some of the things you need to do with estimation. Engineering estimation as a whole talk in and of itself.

And then we check in on our progress toward these goals on a biweekly cadence, depending on the level of quality of execution within your team, you may do that more frequently. So for the first iteration of this at look or act, we were actually doing weekly check-in. So I sat with all of the drivers across each of these major bets once a week.

And we looked at progress toward every single item on the roadmap. Eventually everyone got tired of this. And, and I also got tired of it because I could trust the team to run itself. And we eventually like pulled back to biweekly check-ins and then at scale, and just delegate this entire thing down into your organization.

But Looker at that time was only about 150 people. So I was able to look at this bi-weekly with the team at the end of the cycle, you see how much you got done. You retro, you optimize. You change strategy and you do it again like clockwork at the end of the year, you might set and have a bigger overarching objective, but again, it's like clockwork.

You're constantly iterating toward the improvement of your strategy and the improvement of your execution, the improvement of your organizational design. 

Brett Berson: [00:46:31] When this isn't humming, do you find that the root cause tends to be the same thing or it could be a zillion different reasons? 

Nick Caldwell: [00:46:39] It depends what you mean by not humming from the engineering point of view.

Are you building things on time or not? That generally comes down to improper estimation. Or setting the scope of work too high. Sometimes we want to build toward perfection instead of doneness. And part of the reason I set three month boundaries on roadmap items is to ensure that we're not over architecting or doing too much, that we have something clear that we're going to get out to a customer within a quarter, but from an edge perspective, in terms of delivery, it's either like we didn't resource properly.

We overscaled. Or perhaps the most criminal defender is we took independency. So I sort of skipped that in the earlier summary, but one thing I advise people to do when they're coming up with roadmaps and figuring out how to build teams and so on, just eliminate as many dependencies as you possibly can.

Every dependency you take either from one team or another, or God forbid across organizational boundaries, every one of those things is going to be 10 X, whatever the original estimate was, unless you can. 100% ensure that both teams. Are aligned on delivering that dependency, which is somewhat difficult when you go across boundaries by definition, your org chart is created because you want to have groups with different goals to tackle different objectives.

So when you put a dependency across them, it can cause some challenges toward that framing doesn't mean you can't ever take a dependency. It just means be extremely cautious and try and remove dependencies. By either moving people around, if the dependency is a skillset based one, or if you can't do that, just make sure that both teams are putting the completion of that dependency at the top of their priority list, to make sure as we wind 

Brett Berson: [00:48:29] down our time together, I thought maybe we could zoom out again.

And I was interested when you look back. At your operating career, are there foundational inflection points or moments that you changed your mind or real moments of insight that made you rethink priors or moments that wildly changed the way you think about certain parts of the way that you operate today?

Nick Caldwell: [00:48:55] I think from a career perspective, the biggest shift in mentality that I made was leaving Microsoft after 15 years. So I had convinced myself, Microsoft again, does a really great job of structuring a career. They did a phenomenal job of setting up career ladder. Employee mobility allows you to get exposure to a wide variety of different opportunities.

I, you know, I was working on yeah, natural language machine learning, search gaming, like all sorts of different things. So they make it a very easy place to live in, like use this to spend your whole career, the biggest inflection. Right. To me came when I realized that I was self limiting in terms of my opportunity monetarily, and experience-wise by only living within that one ecosystem, which had been very comforting for so long, it took a lot to break me out of this mentality.

If you only work in one place for a long time, it really becomes your world. The exact same that company become your hero. You get wedded to the tech stack. Your understanding of the market is influenced by the products that are around you. You really start to live in a bubble. So to get out of that bubble, you know, I had to do all manner of stuff to get an MBA.

I had to then start traveling down to the bay area, making new friends. Ironically, the moment that pushed me over was the success of power BI. So if you don't know what power BI is, it's an internal sort of startup that led to being what is now the number one BI product in the world, according to Gartner anyway, and the success of that led me to rethink my approach to entrepreneurship.

I had been in Microsoft, bouncing around doing all of these intrepreneurial projects. And I was kind of focused on the downside. Like, Hey, if this doesn't work, at least I'll still be at Microsoft with my safe, cushy job. And I'd never considered the upside. Like what happens if one of these things actually works and we turn out to build a hit multi-billion dollar business power BI was that ended up being colossally successful.

And it caused me to rethink what I was doing. Even though in power BI was colossally successful in the context of Microsoft, it wasn't earth shattering. It wasn't like a major needle mover, but if I had done this as a startup or as a true entrepreneur, it would have been a phenomenal victory. You know, I started to just sour on intrepreneurship and focus more on true entrepreneurship.

And that's what got me over the hump to try and take a leap. Into the startup scene and joined Reddit. Now I sort of advise people not to, like, if you're going to come up with a brand new startup idea, really engage in the startup ecosystem as opposed to operating underneath the safety net of a big company like Microsoft or Google, we do have programs to support entrepreneurs, but I think you really have to get out into the ecosystem and engage in it.

For real, that has a similar, 

Brett Berson: [00:51:45] is there anything about you that you think. Enabled you to be so successful post a 15 year career at Microsoft. Because what I tend to notice is if you're at a company long enough, And you leave a lot of people 

Nick Caldwell: [00:52:01] struggle. It's not that I didn't struggle with. I mean, I think that the first year out of Microsoft, you have to unlearn a whole bunch of things and then really like double down on what actually worked well.

So if you were to dig into my career post Microsoft, you would see that in the year that I left Microsoft and joined Reddit, I started writing. Tons and tons of blogs about what I had learned at Microsoft and was then applying at Reddit. So all of the stuff I've written about engineering management and org design and product market fit and all this stuff I wrote within the year after I left Microsoft.

And what I don't talk about is all the stuff I unlearned. Like Microsoft has like a lot of. Big company behaviors. The way that you get things done at a big company requires a lot of political maneuvering in ways that if you bring that into smaller companies, doesn't fit, you don't want to be doing that.

Smaller companies and startups are powered by the mission. You don't need to overlay any more complexity into the situation than if we don't achieve product market fit. This business will not work and we'll all have to get new jobs. Whereas Microsoft and big companies. Yeah. You don't have that type of clarity and the lack of focus, breeds politics, and other sorts of things to succeed in those environments.

You do have to navigate that a lot more, but in smaller environments, it's not helpful. You have to unlearn that and then learn other skills which are more amenable to scrappiness, moving quickly, being able to experiment and pivot fast and inspire people to do those things. So I felt like my game really up-leveled okay.

Teaching people influencing and inspiring and then learning the needs of my cross-functional counterparts. Like all of that went way, way up where people fail here. I mean, I think, I don't know anyone who's left a big company gone to a start, but not struggled with this initially in some way. It's just whether or not they ended up liking the overall experience for me.

I. Just love working in the more uncertain and chaotic environment of a startup. You know, Twitter also feels this way at times it still feels like a series B. We're doing a lot of new things, but being a part of that environment where you're paving over the wild west is fun for some people and not for others.

To me, it's been really rewarding. Yeah. Found that having worked at Microsoft and knowing what good can look like allows me to go into these environments and make a big difference really quickly. And I think that's where my success is from. So 

Brett Berson: [00:54:31] to wrap up, I'd like to ask you a question that I like to ask a lot of folks that we talked to, which is when you think about your career, who were the one, two or three people.

That have most impacted the way you think or the way that you operate and maybe what are the things that they taught you? 

Nick Caldwell: [00:54:51] Probably three people. The first one is really early on in my career. It was a guy named Ravi Shahani. I need to keep in touch with him more. I haven't talked to him in a while, but this is when I was very early in my career.

I was like a brash headstrong individual engineer. And I was complaining in his office. He was my manager at the time, it was complaining in his office about how crappy the PMT was. Like, these guys are know what they're doing and they're making me build them. Stuff. And none of it's going to work and just going off on him.

And he said, Nick, you're an amazing engineer, but you're just a shitty leader like ouch. And he said, uh, leaders take responsibility for what happens next. So, are you going to sit in my office complaining about this, or are you going to do something to change it? And that was an incredibly important turning point in my career is the moment I decided that I was going to do more than just be a grunt engineer.

I left his office and went to the GM and was like, Hey, we need to change this in the product strategy. Give me a chance. The second person was a person named James Phillips, who is, I think he's currently a CVP or a president at Microsoft now. But when I, when I met him, he was a general manager. I eventually became the GM in his place and he taught me.

About the difference between engineering managers and directors. Up until this point in my career, I loved line level IAM management, even though I had like 30 people reporting to me, I did all of the things that you would, someone who had a much smaller team, got to know everyone individually and all of the things about motivating and inspiring people on a one-to-one basis, which are great about being an EMT.

I tried to carry that into my role as a director. And I was just having trouble scaling James one day early on after we'd met, said, Nick, you have to learn how to get off the floor. And what that meant was if you, if you think about, uh, engineering team or the product team is a, um, warehouse production or something like that.

You've got your line managers and then you've got your directors and they've gotta be off the floor. Overseeing multiple lines. He made me stop sitting with the teams directly to like force me to get a little bit removal. And it did teach me about how to delegate more effectively and how to see when you pop up off the floor, you can see systemic.

How your teams are working together and understand where the bottlenecks are and so on, so forth. And the last person may be a surprise is Alexis Ohanian would take another whole other podcast, Wayne, this dude, but he has been a phenomenally supportive person when I joined Reddit and I met Alexis for the first time at one of the board meetings.

I had never met this person before. And he literally said, Nick, I'm here for you. I'm going to support your career. And I'm like, oh yeah. You know, everyone says that, you know, thank you. Right. Uh, appreciate it. But. Alexis has gone on to one support my career at Reddit, but later on encouraged me to become an investor.

And now I'm in a fairly well-established angel investor. He helped me with my recommendations for public board roles. He helped with my referral to see your role at Looker and has in every way, shape or form kept an eye out for me in ways that I, I often ask myself why. I don't have a quote or anything to take away from that.

It's just that every so often you'll encounter someone who is, as far as I can tell, like truly selfless and just wants you to succeed. He's been a great ally to have in my corner and what I've want to do and take away from that is to find ways to lift others up to lift as you climb that, I look for ways through my involvement in dev color, which is a nonprofit, I'm a part of the educational, blogs and videos that I.

To find ways to lift others up as I find myself. So he's taught me the value of looking out for the next guy. 

Brett Berson: [00:58:48] Well, what a place to end with your generosity and sharing with our audience and our community. So thanks so much for spending the time with us, Nick. 

Nick Caldwell: [00:58:55] Oh, absolutely. Yeah. I appreciate you having me on the show.