The Executive Twitch
Respecting the Lag
Welcome to the season finale of our “Linear Thinking” sub-series.
If you’ve been following along, we have covered a lot of ground. We named the Hamster Wheel, exposed the Whack-a-Mole trap, dove into the Iceberg to see why we reward failure, and dismantled the Happy Path delusion.
Today, we tackle the final enemy. The reason why smart teams panic, pivot, and burn cash. We are going to talk about Delay, and a phenomenon I call The Executive Twitch.
An industry acquaintance once shared a story with me about a high-growth fintech that was scaling fast. The CEO was a brilliant, high-energy founder who treated his company like a Ferrari. He wanted instant feedback. If he turned the steering wheel, he expected the car to turn now.
But a company with millions of transactions is not a Ferrari. It is an oil tanker.
Every Monday, the “Risk Dashboard” was projected on the screen. The drama always unfolded the same way.
One week, the CEO would scream that fraud loss was up. “We are bleeding money!” he’d say. “Tighten the risk rules immediately!” The Risk VP, under pressure, would block any transaction over $50 from a new device.
Three weeks later, the dashboard would show that transaction volume had crashed. Support was drowning in tickets from angry users who couldn’t pay. “We are killing growth!” the CEO would yell. “Loosen the rules!” The Risk VP would loosen the rules.
Two weeks after that, chargebacks would skyrocket again. The order would come down: “Tighten the rules!”
The Risk team was getting whiplash. The problem wasn’t their competence; it was System Delay.
They didn’t realize that Chargebacks have a 30-day lag. The fraud occurring in Week 1 doesn’t show up in the bank data until Week 5. By tightening the rules in Week 1, they killed the good volume immediately (Instant Feedback). By loosening them in Week 3, they invited the fraudsters back in, but wouldn’t see the damage until Week 7.
They were driving the car by looking out the rear-view window, swerving wildly to avoid obstacles they had already passed.
The Physics of Oscillation
To understand why entire organizations oscillate, panic, pivot, panic again, we have to look at the physics of feedback loops. The classic metaphor is the Hotel Shower.
Imagine you are in an old hotel. You step into the shower and turn the knob. The water is freezing cold.
Naturally, you turn the knob to HOT. But the hot water has to travel through 50 feet of rusty pipes. For ten seconds, nothing happens. The water remains freezing.
Your perception is that you didn’t turn it enough. So, you react. You turn the knob all the way to SCALDING.
Five seconds later, the hot water finally arrives. It is 150 degrees. You scream. You panic. You slam the knob back to COLD. Five seconds later, you are freezing again.
This is System Oscillation. It occurs mathematically when your Reaction Time is faster than the system’s Response Time.
If you react to the data faster than the system can process your previous action, you become the source of the instability. In Product Management, we call this “Agile,” but it is often just “Twitching.”
The Three Zones of Lag
A System Architect does not treat delay as a vague annoyance. They map it. In any product delivery loop, there are three distinct zones where time is stolen from you.
The Perception Delay
Management loves “Real-Time Dashboards.” They are a lie. Almost all significant metrics are lagging indicators. A user rarely wakes up and churns on a whim. The “decision to churn” usually happens 30 to 60 days before the “act of churn.”
If you manage your team based on today’s Churn Rate, you are reacting to ghosts. You are trying to fix a relationship that died eight weeks ago. The veteran move is to stop steering by lagging indicators like Revenue and Churn, and start steering by leading indicators like Login Frequency and Support Sentiment.
The Response Delay
You probably think your “Turning Radius” is your two-week sprint. It isn’t.
Audit the real chain. You prioritize a feature on Day 1. The sprint ends on Day 14. QA kicks it back on Day 17. It merges to Staging on Day 21. App Store Review holds it until Day 24. It goes live on Day 26.
Your turning radius is roughly a month. If the market shifts every two weeks, and it takes you four weeks to turn the ship, you are mathematically incapable of catching up.
The Impact Delay
This is where the “Flatline Panic” happens. You ship a new feature. You check the stats on Day 2. Zero growth. You check on Day 5. Zero growth. The PM concludes, “It’s a dud. Roll it back.”
This is the most common error in product. Humans suffer from Inertia. When you change an interface, the first reaction is confusion, not adoption. It takes multiple exposures to a new feature before a user builds the neural pathway to use it. If you kill a feature on Day 14, you are aborting the baby. You are turning the shower handle back to cold before the hot water has arrived.
The “Worse-Before-Better” Phenomenon
There is a sinister variant of delay that veterans know well: the Worse-Before-Better curve. In complex systems, the most effective long-term solutions almost always degrade performance in the short term.
Think about Refactoring Code. To speed up velocity in the long run, you have to stop building features today. Velocity drops to zero. Bugs increase as you break the monolith. Stakeholders get angry. But eventually, velocity doubles.
Think about Moving Upmarket. To sell to the Enterprise, you have to stop feeding the SMB quick-wins. Revenue drops because Enterprise deals take six months to close. You enter the “Valley of Death.” But eventually, revenue 10x’s.
The “Everyday Product Person” sees the dip, panics, and reverts to the old way. The “System Thinker” anticipates the dip. They warn the stakeholders: “We are entering the tunnel. It will get dark before it gets light. Do not grab the wheel.”
The Discipline of Strategic Patience
So, how do you operationalize this? You cannot simply tell your CEO to “chill out.” You need a protocol.
First, Define the “Time to Impact” (TTI). Never launch a feature without defining its Gestation Period. Do not say, “We are launching on Monday.” Say, “We are launching on Monday. The TTI is 45 days. We expect metrics to be volatile for the first two weeks. We will not draw any conclusions until Day 46.”
Second, enforce a “Pact of Silence.” Before a high-stakes release, make your stakeholders sign a verbal contract. Agree that between Launch Day and TTI Day, you are in the Observation Zone. You will fix critical bugs, but you will not change the strategy, you will not change the copy, and you will not pivot based on Day 3 data. You bind their hands to the mast so they can’t steer the ship during the storm.
Finally, Dampen the Feedback. If your system is oscillating, like the pricing or ad-spend examples, the solution is not to react faster. It is to react slower. If metrics are reported Weekly, move the strategy meeting to Monthly. Force the team to look at the trend (Stock) rather than the blip (Flow).
The Monday Morning Exercise: The Graveyard Audit
Take 20 minutes to look at your “Graveyard”, the list of features you killed in the last year because they “didn’t work.”
For each failed initiative, write down two numbers.
The Duration: How long was it live before we killed it?
The User Cycle: How often does a user naturally use this part of the product? (e.g., Monthly invoicing = 4 weeks).
The Verdict: If the Duration was shorter than the User Cycle, you didn’t run a test. You ran a panic drill.
Is there an initiative in the graveyard that was technically sound but killed by impatience? Resurrect it. But this time, set the TTI. Give it the time it needs to travel through the pipes.
The Golden Rule:
In a complex system, patience is not a virtue. It is a physics requirement. You cannot make a baby in one month by getting nine women pregnant. Stop trying to rush the lag.