Engineering Leadership After ZIRP: Strategy, Systems and Accountability

Larson began his career just before the 2008 crash, when Yahoo seemed to lay people off every few months, and then spent a decade in which revenue, headcount and hiring all climbed together. In that era leaders learned to build very large teams and to hire constantly; at Uber he sometimes did six interviews back to back. Today, he says, managers who spent half their time hiring 18 months ago may do two interviews a month or none at all.

That shift exposes different competencies. A director who excelled mainly at hiring can now look like a low performer unless they also lead the team, dig into details and make decisions about how to size and allocate teams. Teams are being cut and consolidated, something leaders could mostly avoid during the ZIRP years.

Larson sees one real upside. In the previous era, losing team members was among the biggest failures a middle manager could have, so managers tended to shelter engineers from hard problems. He calls that bad for the engineers, the teams and the organization's efficiency. Now leaders can give engineers hard problems and hold them accountable, which is also what makes it possible to put them in senior roles, the career path he wrote about in *Staff Engineer*.

Larson warns that some of the smartest people he knows were strong systems-thinking advocates and also among the least successful. His own cautionary tale comes from incident management at Stripe, where the team became so absorbed in analysis that it prioritized measurement over improvement. His lesson is that when a clean model conflicts with reality, the model is wrong, and the gap between the two is where you learn. But once the model is close enough, you have to go and do the work.

He defines systems thinking in terms of stocks and flows: stocks are things that accumulate, such as fish in a lake or fishers on it, and flows are the rates at which things move between them. He recommends Donella Meadows' *Thinking in Systems* as the starting point. The book also draws on Rachel Carson's *Silent Spring*, where small amounts of toxins concentrate as they move up the food chain.

Applied to a hiring pipeline, the stocks are potential candidates, sourced candidates and candidates at each interview stage, and the flows are the conversion rates between them. Pulling historical data from the applicant tracking system shows where the pipeline actually leaks. The problem might be hiring managers who never reach conviction, managers who make offers that nobody accepts, or simply too few candidates entering the funnel. Without the model, Larson says, companies often roll out big process changes with no data behind them.

Larson pushes back on the common complaint that engineering or product has no strategy. In his view there is always a strategy, and sometimes it is a bad one; it is just rarely written down. Without a document you cannot tell whether a PM is misunderstanding the strategy, applying it faithfully to a problem it does not fit, or working from a weak strategy. A written one, even an unimpressive one, gives you something to debug.

He also argues that good strategy is often boring. At Carta, an engineer wrote the company's standard kit of approved tools, effectively an engineering strategy of using what is already there. Some engineers find that frustrating, but it focuses energy on the problems the company values. His other examples are Uber running only its own data centers, which meant it could stand up in China in about three months, and Stripe's Ruby monolith, which kept engineers on user-facing features rather than tooling for many languages.

To define strategy he uses Richard Rumelt's three parts from *Good Strategy, Bad Strategy*: a diagnosis of the current situation, guiding policies that respond to it, and actions that implement them. Larson says most bad strategies fail at the diagnosis, because people project what they want to be true onto real constraints, for example that all projects can be done at once. That leaves the guiding policies incoherent from the start.

For readers who want to improve, he suggests Rumelt's book first, then *The Crux*, then *Thinking in Systems*, and for engineering specifically titles like *Technology Strategy Patterns*. He still thinks the canonical engineering strategy book is missing, and he hopes to write it.

Larson has written for about 16 years, roughly a thousand posts by his estimate, alongside demanding executive jobs. His main rule is to write what energizes him and drop what does not. He avoids writing on a schedule or for money, and he abandoned an infrastructure engineering book that would not come together. He writes a whole book before approaching a publisher, which lets him reuse most of it when the publisher raises concerns.

Lenny agrees and adds that chasing what is popular creates a job you do not want. Larson says the biggest risk for any writer or creator is quitting, not growing slowly, and that people always believe they have missed the wave of Substack, podcasts or Medium. He sees it as an infinite game in which creators are not really competing, since a rising bar just means better content for readers.

On workflow, Larson says the key is picking topics that overlap with his day job so that writing sharpens his decisions rather than competing with them. Since having a child he mostly writes at night, which only works if he is excited about the topic. If your goal is to advance your career, he recommends crafting two or three really good pieces; if you want to write consistently, publish almost everything, and don't spend time trying to "debug" critics you do not know.

Larson sees two core problems between engineering managers and PMs. Sometimes incentives really are misaligned, for instance over timelines or saying yes to sales. More often, each side starts arguing before understanding the other's needs. He insists that there are no villains in the workplace, only people with complex incentives, and that if you understand what each party truly wants, there is usually a compromise that gives everyone what they need.

His structural fix is to treat EM and PM pairs as peers who generally receive the same performance rating. He and Carta's chief product officer calibrate together, with exceptions for clear individual underperformance, and the company tells people this is how it works. Carta's CEO has also written about extending the idea to trifectas that include business leadership. Larson notes that other functions, such as design in a design-led company, could be included depending on the organization.

For PMs struggling with their engineering counterpart, he points to a hidden constraint: EMs feel responsible for giving their team interesting work. On a growth team, an engineer may want to build something new while the PM needs fifty small experiments, and the EM sits in the middle. Instead of assuming the EM is unreliable, Larson suggests asking why they keep pushing something like a rewrite, which may reveal constraints you cannot otherwise see.

With venture investors pressing on engineering efficiency, Larson says leaders need ways to show their teams are productive. The simplest is benchmarking R&D spending against peers using data from funds, which gives a defensible answer and calms the board but does not help run the organization. To learn whether the team is effective, he says to talk to engineers, who know and can usually point to causes, even if their diagnosis is not always right.

To make the case to a board, Larson tries to align engineering evaluation with product and business goals, since engineering exists to support customers and not to build novel systems for their own sake. He also shows the roadmap of valuable work delivered over the last six months. If you can populate that list, people give you space; if you cannot, concern is warranted.

On tooling, he describes the metrics from *Accelerate*, which include lead time, incident remediation time and failure rate, and which dozens of startups now sell as dashboards. He calls them good diagnostic metrics but not a verdict on whether a team is good. Experts, he says, tend to rule out every imperfect measure and end up reporting nothing. He would rather report something imperfect, such as DORA metrics, and use each question as a chance to educate executives about the underlying reality.

Larson recalls a company whose executives copied Facebook's values onto their own walls, which achieved little and arguably hurt confidence in the executive team. Values cannot be borrowed, he says. The first test is honesty: the company's decisions must reflect them. "We're thrifty" and "we spend what we need to get the best value" are both valid, but only if you actually behave that way.

The second test is applicability, meaning the value helps resolve real decisions. He contrasts Stripe's "optimize globally" with Uber's implicit value of doing what is good for your team and ignoring everyone else. The two are opposites, yet each was honest and usable, and Uber's version helped it move quickly. The third test is reversibility: if nobody could plausibly hold the opposite, such as "we build good software," it is an identity value that cannot guide choices.

Lenny adds that a useful value should make clear who does not fit, and that it should describe who the company is rather than who it hopes to be. He recalls Airbnb cutting two of its six values, including "simplify," when it admitted the company was not actually good at it. Larson agrees that a value that applies to no one you hire is not worth keeping, especially when a company has 17 and needs to get down to four people can remember.

For the show's Failure Corner, Larson tells the story of Digg v4. Digg was losing ground to social networks, and the decision was made to rewrite the whole product to add social features. Larson says rewrites almost never work, but he was early in his career and had been recruited from Yahoo. The CEO was fired two days before he joined, Kevin Rose returned, and the team pushed toward launch. After wiping the existing servers to re-image them, the new site kept crashing, and the team ate sushi and drank champagne around a table on day one because the site was down.

Within a month most people had stopped trying to restore the site, and about five engineers kept going. Larson and a colleague wrote a caching layer from scratch in the first two days, though every server still had to be restarted every 12 hours. Weeks later he found the cause: a Python gotcha around default parameter variables, written by someone new to the language and missed in review. Digg still went to zero, with layoffs after launch shrinking the team from about a hundred to 30, but Larson became a manager just two and a half years into his career and calls it the seed of everything after.

Asked whether Digg could have survived, Larson says the real blow was a Google search change that cut the traffic driving ad revenue on its article pages, which created the urgency for the migration in the first place. He still wishes a product like Digg's original ambition existed, social news based on what friends read combined with a global index of similar users. He also notes he would have refused Uber's China migration if asked, but no one asked, and it became a defining experience.