# Revised rules of engineering leadership.

DevFeed: [Revised rules of engineering leadership.](<https://devfeed.tech/articles/revised-rules-of-engineering-leadership-35690.md>)

Original publisher: [Read original article](<https://lethain.com/revised-rules-of-engineering-leadership/>)

Published: 2026-06-15T13:00:00Z

Content type: article

Language: en

Sources: [Will Larson - Irrational Exuberance](<https://devfeed.tech/sources/will-larson-irrational-exuberance.md>)

Topics: [engineering-leadership](<https://devfeed.tech/topics/engineering-leadership.md>), [migration](<https://devfeed.tech/topics/migration.md>), [Development](<https://devfeed.tech/topics/development.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [ci-cd](<https://devfeed.tech/tags/ci-cd.md>), [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [engineering-leadership](<https://devfeed.tech/tags/engineering-leadership.md>), [leadership](<https://devfeed.tech/tags/leadership.md>), [migration](<https://devfeed.tech/tags/migration.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

An engineering leader revises their approach based on experience in hypergrowth environments and recent AI-tooling changes. The article argues that individuals can own much larger migrations, while the quality and speed of working code depend heavily on development harnesses such as tests, CI/CD, validation environments, and change previews. It also discusses designing processes so agents can handle common cases with appropriate controls and context.

## Source excerpt

From early 2014 through late 2020, I was working in hypergrowth environments, which are challenging, but also educational. The most valuable feature of hypergrowth is that your mistakes reveal themselves next month rather than next year, because things go wrong very loudly when you're moving fast. I've been thinking a lot about hypergrowth recently, because Imprint's business is growing quickly and we did a large batch of hiring last year, but also because the AI-tooling shift has changed the pace at which it's possible to work. This post documents the new rules I've revised my approach to engineering leadership around, and then talks through the specific projects I've worked on over the past year that caused me to believe in these rules. Revised rules Migrations can be done by an individual rather than a team. Even complex, large changes can be 95% owned by the driving individual or team, and done in 10% of the time. As the initial cost of migrations goes down, the reward/penalty of each migration's quality goes up: even small sharp edges will break your colleagues' mental models about the software you co-maintain. The impact of individual judgment on your company has never been higher. While 1st-pass code is nearly free, the cost of working code depends on your development harness, and is not free. We're in an era when many companies say that everyone should be writing code, however our experience is that writing code that works well, while avoiding messy edgecases, remains difficult. Just how difficult remains a factor of your development harness, e.g. your tests, CI/CD, validation environments, preview-ability of changes, and so on. While I personally don't imagine it's valuable for most folks at a company to be contributing code, I suspect that most disagreement about that topic is actually a miscommunication: even at a company where "everyone codes", the marketing team isn't reducing allocations in your servers, instead it's about whether there is a safe bound