Kill It with Fire

Bellotti spent years modernizing legacy systems at the US Digital Service. This book is what she learned. The short version: the technology is almost never the problem. The people are.

Talk about value, not technology

A big red flag is raised for me when people talk about the phases of their modernization plans in terms of which technologies they are going to use rather than what value they will add. This distinction is usually a pretty clear sign that they assume anything new must be better and more advanced than what they already have.

I see this constantly. Roadmaps organized around technology swaps instead of problems solved. “Phase 1: migrate to Snowflake. Phase 2: implement dbt.” Okay, but what changes for the business?

Communication is an essential part of keeping modernization on track. Teams tend to move in the direction they are looking. If we talk about what we’re doing in terms of technical choices, users’ needs get lost.

If you’re thinking about rearchitecting a system and cannot tie the effort back to some kind of business goal, you probably shouldn’t be doing it at all.

Will modernization make things faster for customers? Will it improve scaling so you can sign bigger clients? Or, will it just mean that someone gets to give a conference talk or write an article about switching from technology A to technology B?

Familiarity beats elegance

Systems that feel familiar to people always provide more value than the systems that have structural elegances but run contrary to expectations.

Execution mattered, and anything that lowered the barrier to using computers to execute their goals was preferable to more powerful tools that were harder to learn.

I’ve watched well-designed data platforms collect dust because the team that needed to use them didn’t recognize anything about how they worked. The superior solution that nobody uses is worse than the messy one everybody knows.

Momentum kills more projects than complexity

The number-one killer of big efforts is not technical failure. It’s loss of momentum.

To be successful at those long-term rearchitecting challenges, the team needs to establish a feedback loop that continuously builds on and promotes their track record of success.

In truth, what works when rebuilding a system is not all that different from what worked to build it in the first place. You need to keep the scope small, and you need to iterate on your successes.

Being strategically narrow-minded to demonstrate value and build momentum is not a bad idea.

“Strategically narrow-minded.” Most teams do the opposite. They scope big so the investment feels justified. Then they lose six months and have nothing to show for it.

Suppress the elegance impulse

Good modernization work needs to suppress that impulse to create elegant comprehensive architectures up front. You can have your neat and orderly system, but you won’t get it from designing it that way in the beginning. Instead, you’ll build it through iteration.

Restrict the scope by defining one measurable problem we are trying to solve. Building a modern infrastructure is not a goal.

Hard advice for technical people. We want the clean architecture. You get there eventually, but through ugly, working iterations. Not by designing perfection on a whiteboard.

Incentives shape technical decisions

During a normal team conversation, individual members are looking either to increase or to maintain their status among the group. And, what increases their status? Shooting down the ideas of others. Demonstrating their ability to see some critical flaw everyone else has missed. Developing a brilliant solution. Of those options, developing a brilliant solution is the most difficult to accomplish.

That’s the value of design. When we design our conversations, we turn them into games. We redirect the energy of team members into providing more and better answers instead of simply being right and their colleagues wrong.

The default game in any meeting is: find the flaw. It’s easier than creating a solution, and it makes you look sharp. So that’s what people do.

Bellotti’s point is that structure changes the game. Instead of “what should we do?” (where the loudest critic wins), you run something like “everyone write down three options, then we score them against these criteria.” Same people, same energy, different output. The format does the work.

When an organization has no clear career pathway for software engineers, they are incentivized to make technical decisions that emphasize their individual contribution over integrating well into an existing system.

Organizations end up with patchwork solutions because the tech community rewards explorers.

Patchwork systems aren’t built by lazy or incompetent people. They’re built by people responding rationally to bad incentives. People build what gets them promoted. If promotion comes from external reputation rather than internal integration, you get a zoo of technologies instead of a platform.

Start with what’s failing

When both observability and testing are lacking on your legacy system, observability comes first. Tests tell you only what won’t fail; monitoring tells you what is failing.

If you have a good monitoring strategy, have a good testing strategy, and can roll back changes quickly, you will be able to change almost anything about your legacy system with confidence.

Get visibility into what’s happening before you start changing things. Teams rush to rebuild systems they don’t understand, and the new version ends up with the same problems because nobody diagnosed the root cause.

The takeaway

Modernization is a change management problem that happens to involve technology. Getting time and resources, maintaining momentum, fixing incentives, keeping people focused on value instead of novelty. That’s the work.

Her 15 percent rule stuck with me. When a team is stuck, have each person list actions they can take right now to make the situation 15 percent better. Not solve the problem. Just move it forward. That’s how real modernization happens. Not in grand architecture reviews, but in small wins that compound.