4. Decide Fast, Learn Faster¶
The CEO ordered the feature killed.
The stated reason was simple. No one uses it.
I knew the premise was wrong. The feature had real users. Not many, but real ones. The team knew it too, and they pushed back hard against the kill.
I read their pushback as biased. Sunk cost. Attachment to work they had built and did not want to throw away. That read was not unfair. It also was not the whole story.
To make the call cleanly between the CEO's read and the team's read, I wanted data.
So I went to look for it.
The data was not there.
Product analytics had been half-built for a long time. The instrumentation was incomplete. Trust in what existed was already low because the setup had never been finished. Anything I pulled from it would have been arguable on both sides — the CEO's read could be defended from the numbers, and so could the team's.
The fix had been on my list for a while. I had been deprioritizing it. Other priorities. There were always other priorities. Each quarter when the question of finishing the analytics came up, there was a more urgent thing in the room, and the more urgent thing won.
The data was not there because I had not built the system that would have given it to me. I called it a priority problem at the time. From here it looks more like an avoidance problem.
The same way technical debt accumulates when you do not refactor, decision debt accumulates when you defer the foundational calls. The interest is paid later, on every decision that needed those foundations to move.
The deferred analytics call was foundational. The kill-the-feature call needed it. One had compounded into the other before I noticed the connection.
Each deferral was defendable in isolation. Read together, I had been rationing decision-velocity at exactly the wrong moments — slow on the foundations, then stuck on everything that depended on them.
What I did next was not a decision. Not really.
I did not kill the feature. I also did not push back to the CEO with a defended counter. I held.
The non-decision became a decision. The feature stayed alive. The team kept giving it attention. The question stayed open.
For multiple quarters.
The realization, when it came, was not sharp. It landed in a CEO conversation somewhere around the third quarter — the recognition that the team's velocity on the broader mission had been costing more than the question itself was worth.
The cost of being slow was always too distributed to total up. I never had the moment where someone showed me a number and I felt the damage. The realization came in pieces, in CEO conversations, over quarters. Most slow-decision damage looks like that.
Not a crash.
A leak.
Naming the structural lesson is the easy part.
The harder part is that there were two moves I should have made, and I did not make either.
The first move: fix the analytics. Make the data trustworthy enough to decide on. When the data is the problem, the leader's job is to call the fix. Decide to fix the data. Then decide on the feature.
The second move: decide without it. Leaders often have to call it without enough data — that is what decide fast, learn faster actually means in the room where the foundations are still missing. Use what is available. Build a counter-plan. Set a review date. Move.
I did neither.
I held.
That is the failure. The decision-debt frame helps me understand it.
I still carry that one.
Two universal alibis show up inside that story. Both are real principles. Both can become covers.
"I have other priorities." True for every leader at every moment. There is always something more urgent. The honest test is whether the call you are deferring is actually less important — or just less uncomfortable.
"I need data." A real principle. Until the leader is the reason the data is not there. Then it stops being data discipline and becomes data dependence.
Neither sentence is wrong. Each one was earned by a real leadership lesson somewhere in the past. The trouble starts when they are used to defend the call the leader does not want to make.
The diagnostic that catches it is borrowed from the first chapter. Is the principle serving the call, or is it shielding the leader from making it.
If it is shielding, the principle has stopped working as a principle.
What bad leadership usually does¶
The default move is to treat every decision the same way.
Some leaders default fast. They decide quickly on everything to look decisive. The reversible calls work out. The irreversible ones leave damage that does not show up for months.
Other leaders default slow. They wait for more information on everything. The irreversible calls eventually get the depth they deserved. The reversible ones rot in the meantime.
Both are the same mistake.
Speed is not the problem. Depth is not the problem. The problem is treating every call as if it sits in the same category.
When everything moves at one speed, the leader is not deciding. The leader is performing a posture.
The principle¶
Move fast when reversible. Slow down when irreversible.
The skill is the match.
Why it matters¶
A leader who decides slowly on reversible calls pays in team velocity. The team waits. The opportunity ages. Foundational fixes get deferred for the next more urgent thing. Decision debt compounds.
The damage from this kind of slowness is the kind in the first story. It does not arrive as a crash. It arrives as a leak. The leader cannot point at a single moment and say that is what it cost us. That is what makes it dangerous. By the time it can be named, it has already been carrying for a long time.
A leader who decides quickly on irreversible calls pays differently. People-related calls, ethical calls, calls that change the company's structure or its commitments — those do not give back what they cost. The bill is paid by someone other than the person who made the call. Usually a team member. Usually quietly.
The cost of mismatch is not symmetric.
But the cost of consistent mismatch — the leader who is slow on the small calls and fast on the big ones — is something else again. That leader has decision-making backwards. The team feels stuck on what should have been quick and unprotected on what should have been careful. Trust corrodes from both ends.
What better leadership looks like¶
Different team. Different scene. Same skill, used the other way.
A small marketing experiment came up. The team was paralyzed analyzing potential impact, running models, asking each other for sign-off, building decks for a decision that did not need a deck.
I ran the math in my head, in the meeting.
The budget was small. The kind of campaign budget that, if it fails, the company will not notice. Worst case, we lose roughly half of it.
If it fails and the CEO asks for accountability, the answer is ready. This was experimental. The cost was bounded. This is how we learn what works.
Downside ceiling, small. Upside ceiling, a working campaign and learning we did not have before.
So I said yes.
I did not announce it upward. I did not pre-align stakeholders. I did not stage it as a proposal. I executed in silence within my domain.
The campaign worked. In the post-mortem, I gave the team credit for initiating it. The math posture had been mine. The execution had been theirs, and that was the part visible to the rest of the company.
That phrase — execute in silence within my domain — needs a fence around it. Without one it reads like governance-skirting. With one it reads like the leader using the room they have been given.
The fence is three conditions. They have to all hold.
One. The cost is genuinely bounded and small. Worst case is small enough that pulling executive attention to it would be overkill. Not small as defined by me. Small as defined by the company.
Two. Real accountability. If it fails, the leader takes the hit. Honestly. No rewriting the story afterward. No hiding the failure when asked.
Three. Within the leader's authority and domain. This is the leader's call to make. Not someone else's call being quietly absorbed.
When all three hold, this is what good autonomy looks like — a leader using the room they have been given without making theater out of using it.
When any one fails, execute in silence is a cover. A bounded cost that turns out to be not that bounded. Accountability that quietly disappears when the result is bad. Authority that was never the leader's to begin with.
The phrase has heat. The fence is what keeps the heat from burning the wrong thing.
The point is not control. The point is responsibility.
A practical tool¶
The Reversibility Match¶
Before deciding, classify the call. Most sit cleanly in one category. Some sit between two — pick the closer one, hold the line until new information changes the category.
1. Reversible and low-risk. Decide fast. Move and adjust. Most decisions live here. Most leaders treat them like irreversible ones.
2. Reversible and medium-risk. Decide with what you have. Build a counter-plan. Set a review date. If the signal goes the wrong way, you already know what you will do next.
3. Reversible and high-risk. Decide, but monitor closely. Pre-define the signal that means roll back. Roll back is not failure. Roll back is the plan.
4. Irreversible. Slow down. Sleep on it. Get the data even if it costs time. People-related calls, ethical calls, structural commitments — these usually live here. These do not give back what they cost.
5. Crisis. Contain first, analyze later. Speed is the principle, but only on containment. The diagnosis still needs depth — just not before the fire is out.
The five categories are the work. Most leaders do not need a more sophisticated framework. They need to stop treating category 1 like category 4, and category 4 like category 1.
The marketing campaign was category 2 — reversible and medium-risk. Bounded cost, counter-plan ready, review date built into the experiment by definition. It moved at category 2 speed because that is the speed it deserved.
The feature kill was category 2 the whole time — also reversible, also medium-risk. Technically reversible because the code, the design, the learnings were all still there. Operationally medium-risk because real users existed, and a kill-then-revive would land on them, not only on the team. I treated it like category 4 — irreversible. The mismatch is what cost the team multiple quarters. By the time the cost became visible, it had already been paid.
The Bounded-Cost Test¶
Three checks before executing inside your own domain without broader announcement.
1. Is the worst case small enough to defend as experimental?
Not small as you would like to define it. Small as the company would define it if asked.
2. Will I take the hit honestly if it fails?
Including the version where you are asked about it months later, in a context that is no longer friendly.
3. Is this within my authority to call?
If the answer requires a reach, the answer is no.
If yes to all three: act, do not ask. If no to any: surface it.
This is the fence. Use it before the phrase, not after.
Simple rules¶
- Match the speed to the reversibility. Do not default to one speed.
- Decide fast on reversible calls. Build a counter-plan. Set a review date.
- Slow down on irreversible calls. People, ethics, structure — these need depth.
- In crisis, contain first. The diagnosis can wait until the fire is out.
- Pre-calculate the worst case before deciding. Speed without a worst case is luck.
- Watch the foundational calls. The deferred analytics, the deferred ownership map, the deferred decision record — those are where decision debt accumulates.
- Test "I have other priorities" and "I need data" against the diagnostic. Are they serving the call or shielding the leader from making it.
Reflection questions¶
- For the call I am sitting on right now — is it reversible or irreversible? Am I treating it as the right category?
- What worst case have I actually calculated? Or am I guessing?
- Is there a foundational call I have been deferring — analytics, ownership, decision records, system clarity — that is making my current calls slower?
- When I say I have other priorities, what am I actually deferring? Is it less important, or just less uncomfortable?
- When I say I need data, is the data missing because of how the world is, or because of a call I have not made yet?
- If I executed this without announcing it upward, would the worst case still be defensible? Would I take the hit honestly?
- What part of my decision-making is moving at the wrong speed for what it is?
Reminder¶
Move fast when the cost of delay is higher than the cost of being wrong.
Most slow-decision damage does not arrive as a crash. It arrives as a leak.