14. Build Systems, Not Heroics¶

The deadline was inside 72 hours and the delivery was not ready.

Two engineers were staying late. One of them had been at it through the weekend. Someone else was patching a piece of the integration nobody had owned cleanly for weeks — the kind of dependency that lived between two teams and had quietly become nobody's. Another person was translating business requirements that had arrived in the last 48 hours into something the team could actually build, because the spec that should have existed two weeks earlier did not. The chat channels stayed loud past midnight.

It got across the line. Barely. But it got there.

The next morning, leadership celebrated.

Not subtly. Publicly. The team that scrambled was called out for handling pressure. The weekend rescue was held up as proof of commitment. The people who saved the delivery were named. Everyone saw the recognition.

That was the part that bothered me.

Because it was not the first scramble. It was not even the third. Different projects, different timelines, different people — but the same shape every time. Deadline closes in. Someone heroic. Late-night save. Round of applause. Next project starts. Same pattern.

The room had stopped asking why the delivery needed saving in the first place.

The celebration was closing the loop.

What bad leadership usually does¶

When a team pulls something off under pressure, the default move is to celebrate it.

Thank the people who worked the weekend. Acknowledge the commitment in front of everyone. Treat the rescue as proof the team is strong.

That feels like good leadership. It feels like serving the team.

But it is also a message. This is what we reward here. This is how value gets demonstrated. This is the path to being seen.

So the next time the system breaks — unclear scope, late requirements, unrealistic timeline, ownership nobody pinned down — the team already knows the route. Survive it. Scramble through. Save it at the end.

The celebration is not neutral. It is instruction.

The deeper failure is quieter. Leadership sees a team that handled pressure well and assumes the team is strong. They never ask what created the pressure. They close the loop without fixing the cause.

A near-miss treated as a win is a near-miss that will happen again.

The principle¶

If success depends on heroics, the system is still broken.

Why it matters¶

Heroic effort is useful in an emergency. Sometimes you need someone to stay late and carry the team across a line. That is real.

The problem is when heroics stop being the emergency and start being the operating model.

If every project needs a rescue, the system is broken. If every deadline needs a weekend, the system is broken. If every delivery depends on one person knowing the thing that was never written down, the system is broken.

The cost is not only the tired team. The cost is that nobody can see the cracks anymore. Heroics paper over them. Ownership stays vague because somebody always saves it. Estimates stay unrealistic because somebody always closes the gap. The system never has to be honest with itself, because the next scramble is already covering for the last one.

And the people who scramble the most burn out the fastest. The ones who quietly hold the system together leave first. Then the next crisis arrives without them, and there is no system underneath.

What better leadership looks like¶

When the next delivery came in on a scramble, I did not praise it.

I acknowledged the effort. That part was real. People worked hard. I did not pretend otherwise.

But I made the next conversation different. We got it done. Why did we get here? What broke before the last 72 hours?

That was not popular. The team had been rewarded for exactly this kind of save. Asking about it felt like moving the goalposts.

The question still had to be asked.

Then came the structural work. And this is the part where it would be easy to write that I designed a new operating model and rolled it out. That is not what happened. That would not have worked.

The fix was to bring back what should already have been there — a normal, sensible product and tech operating structure — and rebuild it through the team, not over them.

It started with a two-way conversation. What did the team think the structure should look like? Where did ownership actually break? Where did the estimates go wrong? Where did scope arrive too late? I came in with a point of view, but I tested it against theirs. We worked it out together.

Then the mindset. The team had been optimized for heroics. Saving things. Moving fast under pressure. Demonstrating commitment through last-minute rescue. That had to shift. Clarity first. Scope before speed. Ownership over scramble.

Then a clear target. Not "ship faster." Not "fewer crises." Something the team could point at and ask, honestly, are we moving toward that or not.

Then shared understanding. Not compliance. The team had to understand why the rules existed. Because if the rules only held when I was watching, I had built another bottleneck. The point of the system was that it could run without me standing over it.

The work was not heroic. It was methodical. It was slower than a top-down mandate would have been. But the team owned it.

The deliveries got quieter. Not perfect. Quieter. The scrambles became rarer. The late-night escalations became less routine.

The tool — the question that replaces the applause¶

After any near-miss, before any celebration, run one question through the team.

What system would have prevented this?

Not "who should we thank." Not "who failed." The mechanism.

Where did ownership break? Where was scope unclear? Where did the estimate miss reality? Where did the escalation arrive too late? Where was the dependency invisible until it was urgent?

Write the answer down. Assign the fix. Set a review date.

Then, and only then, acknowledge the effort it took to save the delivery. The order matters. If the applause comes first, the diagnosis never comes at all.

The ethical boundary¶

This principle can be misread as dismissing effort. It is not.

The people who stayed late were not the problem. Their commitment was real.

The point is not to reward commitment. The point is to build a system where commitment is not the only thing standing between the team and failure.

That responsibility belongs to the leader, not the team. A leader who builds the system so the team does not have to be heroic every sprint is not removing autonomy. They are removing unnecessary suffering.

This is not the same as saying every failure is the system. Sometimes people fall short on their own, and accountability still applies. The point is to ask the system question first, not last.

Simple rules¶

After a near-miss, ask why the rescue was needed before you thank the rescuers.
Treat repeated scrambles as a system signal, not a personality trait of the team.
Build the structural fix through the team, not over them. Conversation first.
Set a target the team can measure movement against.
Make sure the team understands why the rules exist, not only what the rules are.
Acknowledge effort. Do not celebrate it as the operating model.
If the system only works when you are watching, you have not built a system. You have built a dependency.

Reflection questions¶

The last time my team pulled a delivery across the line at the last minute, did I ask why?
What pattern keeps producing near-misses on my team, and what have I done about the cause?
Am I rewarding the rescue or the reliability?
If the strongest person on my team left tomorrow, what would break?
Is the structure I have actually a structure, or is it one person carrying the gaps?
Did the team help build the system, or am I the only one who understands why it exists?

Reminder¶

If one person saves the day once, that is commitment.

If the same type of crisis keeps happening, that is no longer commitment. That is a broken operating system.