Whenever Will Larson meets up with fellow CTOs or heads of engineering at other startups, he often finds himself having the same conversation over and over again — an engineering leader's version of Groundhog Day. The biggest challenge these leaders face is pressure from their CEOs to drive engineering velocity. As the CTO at Carta and formerly at Stripe, Uber, and Calm, Larson has scaled engineering teams from tens to hundreds of people and penned three books on engineering leadership. First Round Review sat down with him to unpack three commonplace practices he believes have become unexpected anti-patterns.
What makes the top 1% of engineering executives stand out?
The core challenge for engineering execs is they have to wear three different, kind of opposing hats. The best ones can toggle back and forth between them deftly. First, as an executive team member, you're finding ways to drive the business forward — sometimes that means making decisions that are "bad for engineering overall," like reducing the engineering budget. Second, as an engineering manager, you're figuring out the structure of policies needed to run the engineering org and how to be an effective people leader. Third, as an engineer, you're keeping the bar for technical excellence high. You're still responsible for the technical excellence and execution of engineering, despite any outside stressors.
I find a lot of executives tend to lean a little bit too heavily on one of these dimensions. And a common denominator lurks in all three roles: leaders stumble when they carry overmanagement practices that no longer serve them.
Your first unexpected anti-pattern is about micromanagement. That seems counterintuitive — isn't micromanagement clearly bad?
One of the biggest lessons in management over the last decade is that micromanagement is bad. But I think this is an anti-pattern, because it creates disengaged and context-free leadership, and leadership can be so much more than that. Too many executives take this kernel of advice and as they grow more senior, start to think of themselves only as resource allocators — that their main job is to allocate budgets to different teams and periodically check in on the quality. While that's certainly an important part of management, that's not the entirety of it.
New engineering managers are often advised to "step away from the code." But an extremely high-functioning exec understands the domain they are operating in at some level of detail. As you get too far out of the details, you just become a bureaucrat. Too many well-meaning engineering managers end up as bureaucrats.
“Anytime you apply a rule too universally, it turns into an anti-pattern.”
How do you tactically get closer to the details without crossing into harmful micromanagement?
The first tactic I call "conflict mining." The number one way that I see new engineering leaders struggle when they come into a new place is that they assume the context from their previous company applies as is. When I came to Stripe, I saw a provisioning problem that I'd solved at Uber with self-service automation tooling. I started pitching the idea to senior engineers. One of Stripe's most senior engineers absolutely hated my idea. He told me there was nothing I could tell him to get him on board. At first I thought, "This is a really unreasonable person." But later as I dug into it, I discovered he was right — Stripe's core undocumented strategy was a Ruby monolith, and my approach wasn't aligned with that.
Things are not the same across companies, and you can figure that out pretty quickly by finding something controversial and testing for conflict. The wrong way to solve this is to actually implement the conflict-heavy thing. The right way is just to go have a bunch of conversations. You can usually get buy-in from other executives pretty easily, but it's much more difficult to get buy-in from people with the most context around a given problem. Their opinion is most valuable because they are the ones who live in the details.
What's the second tactic for getting into the details?
Write the details down. Every company you come into, you'll start asking around and the engineers will say "There's no product strategy." Then you turn around and go to the product managers and they'll say "There's no business strategy." What ends up happening is that senior leaders coming in will just assume that their last company's strategy will apply because nothing is written down that would say otherwise. There's this pervasive belief that there's no strategy anywhere, but that's not true. There is strategy everywhere, it's just rarely written.
It's the small decisions that end up getting documented. The answers to important questions like "Why did we go into this business? Why are we shutting down this business line?" literally aren't written down anywhere. If you just write things down, no matter how bad they are, your strategy will improve almost overnight. If you don't write things down, it's impossible to improve your strategy.
“If you just write things down, no matter how bad they are, your strategy will improve almost overnight.”
Your second anti-pattern is about measurement. What's the conventional wisdom you're pushing back on?
Measurement is ripe with anti-patterns. Earlier in my career I was a self-described "purist" when it came to finding and measuring the right thing. What I found is that this took forever, and you can't guide people to the perfect thing if they don't have the context of why the earlier, simpler measures didn't make sense. Getting caught up on finding the right measurement was the anti-pattern. I'm a believer in measuring something imperfect but useful, versus holding out for the perfect metric while measuring nothing in the interim.
Everyone you talk to about story points in a sprint is going to say this is a terrible way to measure velocity. And that may be true, but if your CEO disagrees with that, that's actually interesting — it means they haven't built an intuition about how these things work. Engineering leaders are better off helping their CEO build an intuition. That only happens by actually measuring story points, reporting to them, and then getting into the details of why it's not a useful metric to show velocity. You can be ideologically pure and say we shouldn't measure something, but all that does is slow down the learning of the organization around you.
How should leaders think about what to measure upward to their CEO?
The ultimate goal when it comes to laying out the measurements in your eng strategy isn't getting into the weeds of a debate over whether reliability more accurately measures the progress of your team. Instead, the real goal when you measure upwards is how much does your CEO understand the real substance of the work your team is getting done? Remember, measurements are going to change every quarter, for the rest of time at your company.
When you think about how to show off measurements to your CEO or your board, worry less about things that offend your personal mental model, and think more about things that would inform the mental models of your board, your CEO. People want metrics to show reality. They want them to show the truth. But metrics are only partly about showing the truth. The other half is about educating people, to inform their mental model about how the truth works.
“I'm coming to appreciate that the most valuable thing you can do as an engineering exec is to educate other execs on how engineering works.”
Your third anti-pattern is acting as an "umbrella" for your team. You used to believe in that approach?
There's this graphic that circulated a long time ago that showed managers acting as "umbrellas," protecting their team from interruptions and other managers who kind of direct problems at their team. I used to be a big believer in the umbrella concept; I wanted to protect my team from the reality and problems around them so they could focus. The more senior teams I've worked with, the more I've come to believe that protecting your team from reality just makes things worse for them in the long term.
In the past I used to think I was energizing my team by sparing them the details. But now it feels like lying to them. That means even if it's disappointing for folks, I'd rather them process news bit by bit, rather than deal with a huge ocean of mess all in one moment. I'm a big believer in bringing folks into the room so that they can represent themselves rather than having small decision groups.
How do you avoid both the bottoms-up and top-down failure modes in strategic decision-making?
At Carta, we've been relying on people we call "navigators." We appoint one person per business unit to act as a mini-CTO. They get to be the final decision maker for their area's technology. For example, in our fund administration area, we have one navigator and 60 engineers working together. In many other areas at Carta, we've started rolling out Kafka as a messaging system, but the navigator in fund administration called out that they didn't think it was the right tool for them to use. So they didn't. We've seen a lot of success by empowering the folks with the most context on the ground to make the tech-stack decisions that make the most sense for them.
We have a written strategy to guide navigators when making decisions. They can make exceptions if they want to, and then they're accountable to me in terms of the exceptions they make. But it all gets written down. Organizations, even large ones, are just the culmination of a few individuals' judgments. No amount of budget can allow you to escape that.