Let it burn - Why the best organizations choose what they don't fix

We all know this moment. You step back from your organization and list the problems. There are ten of them. Instinct says tackle them all. You launch six in parallel. Three months later, each one is 15% done, none are finished, and everyone is exhausted.

That's usually when someone suggests a reorg.

In product, the key to a good roadmap is knowing what you won't build. Same thing for organizations. Pick your battles and own what you leave untouched. Iterate every month instead of restructuring every two years.

Three projects. The rest burns.

A recent situation in a data team. An engineering manager who wouldn't delegate. He reviewed every deliverable and signed off on every decision. All information flowed through him. The team was slowing down, and everyone could see it.

The decision was to not address it now.

Not out of neglect. Because at the same time, two other teams were in the middle of restructuring their delivery. Stabilizing their process was the priority. Coaching that EM would take months and a level of presence I didn't have yet. Spreading across all three fronts meant treating none of them properly.

But "not going there" doesn't mean "doing nothing." I set up a temporary framework to contain the effects. I monitored the signals (satisfaction, turnover, pace) to make sure the situation wasn't deteriorating. And above all, I set a review date. Not an abandonment. A time-boxed choice.

It's still the most uncomfortable move in the job. Seeing a problem, understanding it, and deciding now is not the time.

The asymmetry is brutal. When you let something burn, the team sees it and holds it against you. When you spread across six projects and nothing gets done, nobody identifies the cause. Targeted inaction is visible. Scattering is invisible. People always blame the first, never the second.

On the product side, same logic. In a context where delivery capacity was struggling, the temptation was to push the roadmap features to avoid losing time. The opposite of what was needed. Whatever you build, if the team can't deliver properly, the product impact will be zero. The roadmap can wait. Delivery capacity cannot. I first tested the organizational and delivery changes on smaller scopes before extending them. The ambitious roadmap burned in the meantime. It resumed when the team was ready to carry it.

The longer you work with a team, the more this choice matters. Starting a project without the bandwidth to see it through creates an unkept promise. And an unkept promise does more damage than silence.

There's a WIP limit that isn't just cognitive. It's emotional. Every organizational change touches people, their habits, their sense of security. Carrying that takes attention. And attention has a ceiling.

"There is nothing so useless as doing efficiently that which should not be done at all." — Peter Drucker (1)

Understanding what's actually burning

Letting it burn doesn't mean looking away. It means knowing exactly what's burning and why. And it means coming back to check, regularly.

Triage demands diagnosis. And diagnosis, like debugging, starts with separating the symptom from the root cause.

A tool I use consistently: the knowledge map. You ask the teams, all teams, not just engineering, to map out who knows what. Not the managers. The teams themselves, because otherwise blind spots stay blind spots. Human SPOFs surface quickly. The dev who's the only one who understands an entire chunk of the architecture, the PM who alone grasps the business domain.

In a company of about forty people where I was supporting the CTO, this mapping revealed the real issue. The CTO was delivering a huge amount. He'd been there from the start, technically strong, involved. But on the knowledge map, his name showed up in almost every box. Technical decisions, architectural knowledge. Every trade-off went through him. The system around him had never evolved to distribute that load. The symptom reported by the team: "we're slow." The root cause wasn't this CTO. It was the organization that had never built autonomy around him.

Different context, same pattern. Sprints consistently slipping. The reflex would be to blame estimation or dev velocity. Digging in, I found that teams were rotating between products every two weeks. Nobody had time to master a scope before switching. The problem was the rotation.

Ron Westrum showed that the highest-performing organizations share one trait: when something goes wrong, the error opens the investigation instead of closing it (2). You look for the bug in the system. Not someone to blame.

People describe what they experience very well. What they describe is rarely the root cause. To find it, you have to go see them. At every level, not just managers. Skip-levels aren't a luxury reserved for large companies. Beyond the initial diagnosis, they let you challenge your own choices: the project you decided not to take on six weeks ago, is that still the right call?

Teresa Torres formalized this idea for product with continuous discovery (3): you don't interview your users once to build a roadmap, you interview them on an ongoing basis to keep adjusting. The same discipline applies to organizations. You don't run an audit then execute a plan. You listen continuously and reassess what you've chosen to let burn.

Iterate instead of restructure

A reorg promises to fix everything at once. It takes six to nine months to produce anything. According to McKinsey, 80% fail to deliver the expected value; 60% reduce productivity (4).

Iteration works differently. One change. Measured. Adjusted. Then the next.

In a recent context, the sequence looked like this. The first project was bringing dev and product together around a shared understanding of how we work together. Why that one first? Because as long as tech and product didn't share the same understanding of what we were delivering and why, nothing else could move forward. It was grinding at every sprint, not on execution but on direction. Once that framework was set and stabilized, I tackled how we selected which opportunities to pursue. Then delivery itself. The first weeks were uncomfortable. Stabilization. Observation. Then a new cycle: retrospectives were redesigned so continuous improvement came from the teams, not from above. The documentation and specification process was reworked. Some technical issues could finally be addressed, because the bandwidth was there.

Each change had its moment. None arrived before the previous one was digested.

You don't ship a feature without a spec. You don't change an organization without the same discipline. Each change was accompanied by a short doc: the identified root cause, the proposed solutions with their risks, and the success indicators.

A reorg would have tried to do everything at once with a six-month plan. Iteration produced visible results within weeks, and each stabilized result freed up bandwidth for the next (5).

And the fires we'd let burn? You come back to them. When the current projects are stabilized, you rotate the org backlog and pick up the next one.

Triage makes iteration possible. And iteration ends up treating everything, project after project.

So what ?

Letting it burn isn't comfortable. People will hold it against you. You'll doubt yourself. Some evenings, you'll wonder if you made the right call.

There's a warning signal not to miss. When a fire you chose to leave starts triggering departures, burnout, or an irreversible loss of trust, the triage has failed. Letting it burn has a limit, and that limit is when the fire spreads beyond what you can recover from.

But the question isn't "is everything okay?" The question is "is what we chose to work on actually moving forward?" If the answer is yes, the triage is working. If the answer is no, it's time to reassess.

The perfect organization doesn't exist. The one that knows what it's letting burn, why, and for how long, moves forward. The others run reorgs.

I recently discussed these topics on the Développeur Experience podcast from Donatien. We talked about team efficiency, decision-making, and navigating uncertainty as a tech leader.

Sources

Peter Drucker, The Effective Executive (1967)
Ron Westrum, A Typology of Organisational Cultures
Teresa Torres, Continuous Discovery Habits
McKinsey, Good Decisions Don't Have to Be Slow Ones
Will Larson, How to evolve an engineering organization