▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=Prl858_AovM
• Original title :: The revised rules of engineering management with Will Larson

Gergely Orosz interviews Will Larson, CTO of Imprint and author of Staff Engineer, An Elegant Puzzle, The Engineering Executive's Primer and Crafting Engineering Strategy, previously CTO at Carta and Calm and an engineering leader at Stripe, Uber, Digg and Yahoo. The main argument is that the management habits of the 2010s, shaped by zero interest rates (ZIRP), no longer fit. Managers were told never to make technical decisions, shielded engineers from the business and handed out interesting work, and are now expected to be in the technical details again. Larson argues that a good engineering executive needs both technical judgment and the ability to run a function as a bureaucrat, that line managers are often better future executives than middle managers, and that middle managers should either reskill hands-on or accept their expertise may lose value. Along the way come war stories from Yahoo, the Digg v4 launch, hypergrowth Uber and Stripe, views on career ladders, AI and junior engineers, durable ownership teams, and writing without AI.

Early career and the Digg v4 launch

• Larson started at Yahoo in 2009 as a remote contractor after writing blog tutorials on Yahoo BOSS. Yahoo ran its own forks of everything (Y Apache, Y PHP, YUI, Yinst). David Filo personally approved every server, which created a black market of servers swapped for favors.
• At Digg (2010), 60-70% of traffic came from search to permalink pages, and Google algorithm changes (Panda) were destroying it. A rewrite (v4) on Cassandra was launched with a launch party, caterers and champagne while engineers wiped old servers with no rollback. The site stayed down for about 24 hours.
• Cassandra had never been load tested. Two days before launch, Larson and a colleague were asked to do it and found that reads and writes could not work at the same time.
• A month-long memory leak turned out to be a Python mutable default argument that accumulated user IDs. After the fix, the company was largely laid off within a year. Larson does not think keeping the old site would have saved it either.
• Digg's team was acquired by Social Code. Larson, managing about 12 engineers, realised that to get a large leadership role he needed to join a fast-growing company.

Path through Uber, Stripe, Calm, Carta and Imprint

• Uber (2014): joined a roughly six-person infrastructure team (databases, Kafka, provisioning) when the company had 200 engineers. The team reached 70 two years later, with headcount doubling every six months. Hiring was the main skill learned there.
• Uber culture was "solve it yourself" with no dependencies and almost no management support. Larson once signed a multi-million dollar purchase order for Uber China because nobody else could.
• Stripe (2016-2020): few managers at first, one with 40-50 reports, following the Google no-managers model. Larson later led about 250 people. He stayed one step from the CEO, then moved to Calm as CTO to see whether he could lead better from the top seat.
• A CTO is the one role where the technical and managerial tracks converge. Larson keeps both ICs and managers as direct reports (14 reports, 4-5 of them ICs).
• At Imprint he leads product, design and engineering as one unit. He argues a single decision point helps while agents change how software is built, though he does not see it as a long-term trend. He has made over 500 pull requests in a year and a half.
• Moving from a 250-person team at Carta to a 25-person team at Imprint was a deliberate step back to relearn software in the AI era.

How management changed since the 2010s

• Early management was nearly absent. Larson had two one-on-ones in two years at Yahoo, and the manager's job was to find impactful opportunities, not to develop people.
• During the ZIRP era, hiring and retaining engineers was the differentiator, which pushed leverage to engineers. Companies pitched career development and interesting work, and some let engineers skip on-call, which Larson sees as a priority shift.
• Managers were told never to make technical decisions, so the only levers left were headcount, process, scheduling and people. This produced bloated orgs and people-pleasing managers who shielded engineers from the business.
• Survey scores and headcount filling became goals in themselves. Larson says hiring is the least interesting way to solve any problem and that discussions of headcount should be rare.
• Staff engineers were framed as working on fun problems. Larson needed them on the business and scalability problems, and told his best engineers he had "only suffering to offer" that would make the business succeed. Gergely notes that this stance is now the default.

Career ladders, staff engineers and junior roles

• Rubrics still produce fairer decisions than none and keep glue work from being undervalued, so Larson remains a believer in ladders. Off-the-shelf ladders are outdated and the next version does not exist yet.
• For staff and principal levels the key marker is decision-making under ambiguity: making trade-offs, building conviction and prototyping. A Stripe multi-region project stalled because engineers waited for product to decide CAP theorem trade-offs. Agents often miss trade-offs that live outside the context window.
• Eng 1 versus Eng 2 distinctions are mostly time and role. Overly precise rubrics get gamed (for example collecting "mentees"), and promotions always involve judgment.
• At Carta, cost pressure led to a fixed ratio of staff engineers, which forced hiring to be less senior. Larson prefers being honest about the constraint (managing costs) over a perfect description.
• Fifteen years ago senior was the top role at most companies. Today's extra levels are more time and role titles than clear capability jumps.

How the software engineer role is changing

• Larson says the profession is changing more than at any point since 2008. Implementation time is approaching zero, but decisions, scale, user expectations and unit economics remain hard.
• Engineers now run ahead of PRDs and high-fidelity designs, which strains design teams. Imprint is trying a model where engineering handles the base case with the stock design system, and product design handles exceptions and extends the design system. It is not working smoothly yet.
• Gergely has heard of few cases where designers or PMs push production code, despite expectations. Possible reasons are accountability, specialization and limited attention.
• Domain-heavy businesses (Carta's cap tables, accounting, law firms) have kept their defensibility. The "AI engineer" is mostly a product engineer using AI.
• Some people lose the flow state they loved and are retiring, while Larson, who is outcome-oriented, finds it the most fun period of his career.

Revised rules of engineering management

• Durable, high-ownership teams with domain context are the only way to scale. Moving 15 people onto a late project mostly provides optics and breaks the pods that work.
• Larson splits large teams into pods that own areas and then largely leaves them alone. For crunches, he protects the critical-path team from meetings and recruiting, asks for a short push, and offers time off afterward. Rotating people between daily crises burns them out.
• Gergely cites Slack's coding-agent integration as evidence that teams with accumulated domain context keep reinventing the product while competitors do not respond.
• Good products usually need one or two empowered sponsors close to the executive team who make unpopular trade-offs. Imprint moved from Jira to Linear in under four weeks, with about three of 230 people in favor beforehand, so agents could see and pull tasks. Sponsors then need to be held accountable for the risks they impose.

Becoming an engineering executive

• The old path was engineer, then middle management, then CTO. It selected for operators, not technologists. Running a function means being a bureaucrat: understanding incentives, process and structure (Larson recommends Seeing Like a State).
• A good executive needs both technical judgment and the bureaucratic skills. Pure bureaucrats do not know how software gets made, and pure technologists cannot run a function.
• Line managers often make better executives than middle managers because their judgment on technology and the business is stronger, but they still have to learn bureaucracy. Middle layers that taught it are now disappearing.
• C-level roles often involve running functions one has never done, such as customer operations or support engineering at Imprint and Stripe.

Advice for middle managers

• It is a hard time in middle management, especially for those trained in the 2010s empowerment and bureaucracy model. Larson sees a choice between reskilling and retiring.
• He advises being open to a lateral or backward step, such as line management or hands-on engineering. Tools for writing software are strong, while tools for headcount planning and performance reviews are poor.
• He would hire experienced managers who want to write software, such as a former VP who now line-manages and ships a lot of code. He recommends telling people openly that this is what is wanted.
• Many people feel the industry betrayed them, but the industry has always been volatile and the 2010s stability was an exception. Humility matters because pay is for work the company values.
• The tech lead manager role is still a trap but highly demanded. Management is flattening into managers with 12-14 reports or directors managing tech lead managers. The ideal hire has the capability for bureaucracy but not the desire for it.

Writing and AI

• Larson has blogged for almost 20 years and credits writing with changing the industry, for example the Staff+ concept. He does not use AI to write because his ideas and 20 years of accumulated trust would be wasted on slop.
• Gergely uses writing to think and says AI voices flatten millions of different voices into one.
• Visibility requires one or two pieces that get traction, not volume. Mass AI-generated content signals poor judgment.

Book recommendations

• Larson: his own Crafting Engineering Strategy, Thinking in Systems by Donella Meadows, and a book on TLA+ by Hillel Wayne, for the verification of AI-written software.