Engineering Wants to Rewrite!

Marty Cagan argues that when engineering demands a halt to features for a full rewrite, the root cause is usually product management, which has pushed teams to ship features while neglecting infrastructure until the codebase can no longer support new needs. Such rewrites tend to take far longer than estimated, leaving customers free to defect to competitors, and many companies never recover. His remedy is to reserve a fixed share of engineering capacity, around 20% and more in troubled systems, for 'headroom' that keeps the architecture scalable. He also urges realistic schedules, incremental rewrites that preserve user-facing progress, and careful feature selection, using eBay's repeated rewrites as an example. The message matters because it reframes technical debt as a product responsibility to be planned, not a surprise for engineering to absorb.

01Key takeaways

• Treat infrastructure health as a product responsibility, not something engineering should absorb silently.
• Reserve roughly 20% of engineering capacity as headroom for scaling, refactoring, and architecture work.
• Raise the headroom share to 30% or more when the codebase is already struggling.
• Scrutinize rewrite schedules line by line, since their estimates tend to be far too optimistic.
• Break rewrites into incremental pieces so users still see forward progress during the transition.
• Choose a small set of user-visible features carefully when capacity for new work is limited.

02Key sections

The dreaded rewrite request

Cagan opens with examples like eBay, Friendster, and Netscape to show how engineering demands for a full rewrite often nearly end companies. He notes most never fully recover from them.

Product management's responsibility

He contends the blame typically belongs to product managers who relentlessly pushed for features while neglecting infrastructure, letting the software eventually hit a ceiling.

Reserving headroom

The core prescription is to give engineering around 20% of capacity, or more when a system is in bad shape, to spend on refactoring, re-architecting, and scaling work.

Managing a rewrite when you are already stuck

If the situation has already arrived, build realistic timelines since rewrite estimates are often optimistic, and split the work into incremental chunks that keep shipping user-visible value.

Lessons from eBay

eBay rewrote its site proactively and repeatedly, even translating millions of lines to a new language, while still delivering record functionality without disrupting users.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.