Will Larson, a three-time CTO (Calm, Carta, Imprint) and author of influential engineering leadership books, discusses how engineering management has fundamentally shifted from the 2010s to today, why the “never make technical decisions” management orthodoxy has reversed, and what career paths look like for engineers and managers in the AI era.
Will’s career arc and early industry lessons
Started coding as a kid on a Mac with Kid Pix, then MUDs and IRC scripting taught him regexes; didn’t write real software until college at a tiny program (13 students total, 4 graduates his year).
First job: remote contractor at Yahoo in 2009 during the financial crisis hiring freeze; experienced Yahoo’s “Y-prefixed” everything (YApache, YPHP, YUI, Yinst) and a server black market created by founder-approved allocations.
Joined Digg 3–6 months before the disastrous v4 launch (Cassandra, no load testing, 24-hour downtime, memory leak from mutable Python default args); fixed the leak after a month but the company laid off most staff anyway.
Couldn’t get hired into large leadership roles from a small startup, so targeted fast-growing Uber in 2014; grew an infra/SRE team from 6 to 70 in two years while manually reallocating servers for Friday rush hour.
Moved to Stripe (2016–2020) as an early manager in a company that initially had almost no managers (one manager with 40–50 reports); helped build management structure during 70% YoY growth.
Became CTO at Calm (3.5 years), then Carta (2 years), then Imprint (1.5 years); at Imprint also leads product and design in a unified EPD structure.
The 2010s management orthodoxy and ZIRP’s distortion
In the 2010s, new engineering managers were explicitly told “never make a technical decision again”; the role bifurcated into technical (staff+) and managerial tracks, with managers becoming facilitators, not decision-makers.
Zero interest rates (ZIRP) made hiring/retention the primary differentiator; companies competed on “rewarding work,” perks, and shielding engineers from business pressure (e.g., removing engineers from on-call).
Managers’ only levers became headcount and process, not technology; this drove bloated orgs and selection for “people-pleaser” managers who optimized for survey scores and low attrition over business outcomes.
Staff engineers were told their job was personally interesting problems; Will pushed back at Stripe: “I only have suffering to offer, but this suffering is what’s going to make the business succeed.”
The industry has reverted: managers must now be technical decision-makers again, and engineers are expected to understand business, unit economics, and product strategy.
How the engineer role is changing with AI
Implementation time is approaching zero, but decision-making (trade-offs, CAP theorem, product implications, unit economics, legal constraints) remains hard and is where senior/staff engineers add value.
AI agents don’t recognize implicit trade-offs outside the context window; navigating ambiguity and building conviction on prototypes is still a human skill.
Domain-complex businesses (e.g., Carta’s cap tables, fund administration) retain defensibility because the hard part is domain context, not code generation.
“AI engineer” label is mostly compensation signaling; every product engineer now uses AI tools.
Designers/PMs pushing production code remains rare despite better tooling; accountability, specialization, and attention constraints are bottlenecks—Imprint is experimenting with developer-led design for tier-2 features but hitting friction on design-system adherence.
Durable, high-ownership teams as the scaling primitive
Persistent teams that accumulate domain context and ownership outperform constant reorgs; Will has recreated this at Uber, Stripe, Calm, Imprint: form pods, let them own areas, ignore them until something breaks.
Mythical man-month still applies: throwing people at a late project destroys the durable teams that actually work; better to clear BS (recruiting, all-hands) for the critical-path team and run a focused sprint.
AI may extend how far a small team can go, but human attention still runs out before coding capacity does.
Slack’s agent launch exemplifies domain-context advantage: they shipped a well-integrated agent feature competitors haven’t matched, likely due to an empowered, context-rich team with executive sponsorship.
The CTO role: technologist + bureaucrat
CTO is where technical and managerial tracks converge; Will keeps ICs (4–5 of 14 directs) reporting to him to stay in technical details—he did 500+ PRs in 1.5 years at Imprint.
Effective executives need both: deep technical judgment (what to build, how) and bureaucratic skill (running functions you don’t know, incentive design, process allocation, org structure).
Line managers make better executives than middle managers because they stay close to execution; middle management in the 2010s selected for bureaucratic skills at the expense of technical depth.
Today’s flattening orgs (directors managing tech-lead managers, EMs with 12–14 reports) make it harder to learn bureaucratic chops; the best hires are experienced managers who can do bureaucracy but choose to write code.
Middle management trap and the reskilling imperative
Middle managers (EMs managing EMs) are in a career trap: the industry no longer values pure bureaucracy without technical depth; two paths forward—go back to line management/hands-on building, or accept declining relevance.
Will deliberately “stepped back” from 250-person org at Carta to 25-person at Imprint to reskill; the tools for line management + coding are excellent, while headcount planning/performance review tooling is terrible.
Hires like Jasmine (ex-VP at Mux) who want to line-manage and code are the highest-value profile; interview for EM competence, then filter for frustration at not writing software.
TLM (tech lead manager) remains a trap but a demanded one; flattening orgs make it the only option in many companies.
Writing, influence, and AI content
Will has written for 20 years (Irrational Exuberance blog, 4 books); writing is how he thinks and changes industry discourse (e.g., “staff-plus” concept from Staff Engineer).
He refuses AI-generated content: it would discard two decades of built trust and distinctive voice; if he has nothing to say, he publishes nothing.
Most “content strategy” is cargo-culting; one high-effort piece that gets traction beats 200 AI posts—visibility comes from impactful ideas, not volume.
AI slop in candidate portfolios signals poor judgment (running a recipe without tasting the product).
Recommended mental models and books
Thinking in Systems (Donella Meadows): the mental model that shaped Will’s view of management and organizations.
TLA+ (Hillel Wayne): formal specification for verification—critical as agents write more code and cheap verification becomes essential.
Type systems and formal methods: not daily tools, but the ideas (verifiability, constraint modeling) are transferable to AI-era engineering.
