Delete-First Lean Engineering
On a small team, deleting code beats writing it — audit for features whose maintenance cost exceeds their gain.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 3
- Confidence
- 85%
When a team is forced to stay small, the discipline of removing code becomes more valuable than adding it. Every incremental feature that won a short A/B test carries a hidden, permanent maintenance burden. The practice is to periodically audit your systems and delete anything whose ongoing maintenance cost outweighs its measured gain — keeping the core lean enough for a few people to run.
Origin
Jay Baxter's reflection after X's post-acquisition layoffs (roughly 80% headcount cut), when teams were forced to audit and slim their systems.
Core principles
- 01Incremental A/B wins hide a long-term maintenance cost that isn't visible in a one-month test.
- 02Promotion incentives and human tendency bias engineers toward adding, not removing.
- 03A forced-small team surfaces which features aren't worth their upkeep.
- 04You don't have to rewrite everything — delete the cruft and keep the core.
How to run it
- 1
Audit systems for cost vs. gain
Go through parts of your system and honestly weigh each feature's ongoing maintenance burden against the value it actually delivers.
Watch out A small A/B win can look significant while quietly adding maintenance cost 'for the rest of eternity until you turn the thing off.'
- 2
Delete where maintenance outweighs the win
Remove features whose upkeep costs more than their gain, rather than accumulating incremental additions.
Pro tip Deleting code is often more important than writing it — treat removal as first-class work.
- 3
Keep the core, don't rewrite everything
Preserve the core system and strip the unnecessary cruft, so fewer engineers can maintain and improve it.
Watch out Don't over-interpret 'rewrite it all' — mostly you delete the unnecessary parts and keep the working core.
In the wild
After the large layoffs, teams across the company were forced to audit their systems and delete features whose maintenance cost exceeded their benefit.
→ Systems became leaner and workable by far fewer engineers, contributing to a faster pace of launches and experimentation.
Common mistakes
Shipping incremental wins without counting upkeep
A feature that wins a one-month A/B test can still be a net loss once its permanent maintenance burden is counted — a cost invisible in the original test.
Assuming lean means rewrite-from-scratch
The goal isn't to rebuild everything; it's to delete unnecessary cruft while keeping the core system intact so a small team can run it.
Is it for you?
Best for
Engineering leads on deliberately small teams who need their systems maintainable by a handful of people.
Not ideal for
Well-resourced teams where a feature's marginal value is real and maintenance capacity isn't the binding constraint.
From the transcript
“deleting code is more important than writing it a lot of the time”
“Engineers have a a tendency to add these little incremental wins that actually H add you know more of a long-term maintenance cost than is…”
“auditing auditing parts of your system and deleting the things where the maintenance cost is worse than one than the gains”
From the episode
An inside look at X’s Community Notes
Keith Coleman (VP of Product) and Jay Baxter (ML Lead)