Engineering leadership: strategy, systems thinking, and treating engineers as adults

Executive overview

Engineering teams spent the ZIRP era being coddled — leaders avoided accountability to retain headcount, and engineers were shielded from real business problems. The market shift has created an opportunity to treat engineers as peers, hold them accountable, and put them in genuinely senior roles.

Will Larson (CTO at Carta, formerly Stripe, Uber, Calm) shares frameworks for engineering strategy, systems thinking, EM/PM alignment, and measuring productivity drawn from two decades of operating at scale.

The best thing to come out of the post-ZIRP correction: engineers can finally be held accountable — which is the prerequisite for giving them real power.

The shift in engineering culture

• Hiring used to dominate engineering managers' time; retention metrics drove all decisions
• Coddling engineers — shielding them from hard problems — was bad for engineers, teams, and the organisation
• Now teams are shrinking, being consolidated, or cut; leaders need skills beyond recruiting
• The upside: accountability is back, which enables putting engineers in genuinely senior roles
• Engineers can finally get what they wanted — real ownership — because companies can now hold them to it

Systems thinking: stocks, flows, and the limits of the model

• Systems thinking models reality as stocks (things that accumulate) and flows (rates of movement between stocks)
• Classic example: fish in a lake, fishermen fishing — each is a stock; fishing rate is a flow; reproduction rate is a return flow
• Applied to a hiring pipeline: potential candidates → sourced → recruiter screen → hiring manager screen → offer → close; each transition is a conversion rate
• Mapping the pipeline against actual ATS data reveals where the real drop-off is — panicked offer extensions, low close rates, or simply insufficient top-of-funnel
• The biggest failure mode: mistaking the model for reality. When model and reality conflict, reality is always right; the model is what needs to improve
• Systems thinking is a learning tool, not a substitute for action — measure to improve, then actually improve

Engineering strategy

• Every company has a strategy; most just haven't written it down — and unwritten strategy can't be debugged
• Richard Rumelt's definition: diagnosis (what is true today) + guiding policies (how to address it) + actions (how to implement)
• Bad strategy usually traces back to a flawed diagnosis — leaders assert what they wish were true about constraints
• The best engineering strategies are boring: "we only use the tools we already have"; "we run a Ruby monolith"; "no cloud"
• Boring strategies work because they direct limited capacity toward problems the company actually values
• Uber's no-cloud policy let them spin up in China in three months; Stripe's monolith policy kept engineers focused on user features instead of tooling
• A strategy's job is not to please everyone — it's to dictate how limited capabilities are invested

Writing: sustaining output over a long career

• Write what gives you energy; stop writing what doesn't — this is the only sustainable approach over 16+ years
• Writing about topics directly related to your current work eliminates the conflict between job and writing time
• Publish almost everything — a quick internal check ("can I write and publish this?") filters out the duds before a word is written
• For career positioning: write two or three excellent pieces with heavy revision and feedback; don't start a newsletter
• For ongoing output: just publish; imperfect posts that are honest about your current thinking beat polished pieces that never ship
• The biggest risk to any long-running content effort is quitting — not growing too slowly
• Don't chase hot topics; people converge on the same thing, and you rarely have genuine depth there

EM/PM relationships

• Most EM/PM friction comes from not understanding the other person's actual needs before trying to resolve conflict
• Misaligned incentives are the harder case; the most common case is simply not digging into what the other side truly wants
• Hidden constraint: EMs have an obligation to give their teams interesting work — PMs often have no visibility into this pressure, making EMs look like unreliable partners
• Most apparent trade-offs dissolve when both parties genuinely understand each other's constraints
• Will's structural fix at Carta: EM and PM pairs receive the same performance rating, forcing shared accountability for outcomes
• Carta's CEO Henry also experiments with trifectas — EM, PM, and business lead all graded on the full set of constraints, not just their functional slice

Measuring engineering productivity

• Engineers themselves are the most reliable early signal — if you talk to the team, they will tell you whether they're effective and why not
• Benchmarking R&D spend against VC datasets gives a defensible board answer but doesn't help you run the org
• Tie engineering evaluation to product and business goals — don't optimise for interesting internal systems at the expense of customer outcomes
• A six-month roadmap of meaningful, high-impact shipped work is more compelling to stakeholders than any dashboard
• Accelerate's four DORA metrics (lead time, deployment frequency, change failure rate, mean time to restore) are useful for diagnosis, not verdict
• Start measuring something imperfect rather than ruling everything out — imperfect metrics open conversations that educate stakeholders about the real complexity underneath

Company values

• Values must pass three tests: honest (the company actually does this), applicable (can be used to resolve a real decision), reversible (a reasonable company could choose the opposite)
• Identity values ("we care about customers", "we have integrity") feel good to write but can't be applied — they don't help anyone decide anything
• Stealing values from admired companies is cargo-culting; Amazon's "customer obsession" worked because Amazon actually made decisions that way
• Good values describe who you are, not who you aspire to be — Airbnb cut "simplify" because the honest answer was they weren't good at it
• A useful value implicitly excludes some people; if it applies to everyone, it filters no one

The Digg v4 rewrite: a failure story

• Digg was losing to social networks and needed social functionality the existing codebase couldn't support — the decision was made to do a complete rewrite
• Complete rewrites almost never work; the Digg case is a canonical example of why
• Launch day: the site kept crashing; within days most of the team had stopped trying to fix it
• Core issue turned out to be a Python variable initialisation gotcha in default parameters — introduced by an engineer new to Python, missed in review
• Site was read-only for ~3 days; most user functionality was broken for nearly a month
• The company still went to zero — SEO changes had already eroded the ad-driven revenue model before the rewrite was attempted
• What Will took from it: joining a company in trouble early in your career is an accelerator — he became an engineering manager two and a half years in because everyone more experienced had left