It’s Not Speed That Makes You Win — It’s How You Think About Speed

Photo by Lorenzo Lamonica on Unsplash

An Irony in Silicon Valley

In the early 2010s, a health-tech startup named Theranos became the star of Silicon Valley. They claimed they could run hundreds of blood tests from just a single drop of blood. Their team moved incredibly fast — recruiting stars, doubling the company’s size every year, and reaching a valuation of $9 billion. Speed was everything.

But by 2018, it all collapsed. Their technology never worked. A Wall Street Journal investigation revealed that their speed was nothing but pacing without direction. Elizabeth Holmes and her team built an empire too quickly, yet validated the most fundamental question too slowly: “Does our device actually work?”

Ironically, around the same period, another company moved slower in terms of visibility but faster in terms of learning: Instagram. When Facebook bought them for $1 billion in 2012, Instagram had only 13 employees. They didn’t rush to copy Snapchat or add new features every month. Yet when they launched Stories in 2016 — right after Snapchat popularized the format — they could move extremely fast because their infrastructure and feedback loop culture were already mature.

Two companies, two approaches to speed. One died. One dominates.

“The real competitive advantage is not speed — it’s how you think about speed.”

Case One: The Classic Mistake of the Burning Startup

Let’s look at a hypothetical but very real case.

Fast Innovation Inc. is an app-based logistics startup. In their third month of operation, the CEO detects that competitors are starting to steal market share with lower prices.

What does the team do? “We must go faster!”

They do three things. First, they accelerate hiring: within two weeks, they recruit 15 new salespeople without in-depth interviews. Second, they accelerate product launch: they release an “instant pricing” feature without sufficient testing. Third, they accelerate marketing: they buy ads on five channels simultaneously.

The results three months later are devastating. Twelve out of 15 new salespeople fail to meet their targets and actually damage client relationships. The instant pricing feature miscalculates shipping costs, causing a 30 percent loss per transaction. The untracked ads burn through cash without improving customer retention.

They are fast. But fast into the ground.

This is not an isolated oddity. John Boyd, a fighter pilot and U.S. military strategist, created the concept of the OODA Loop — Observe, Orient, Decide, Act. Boyd discovered that in aerial dogfights, the winner is not the fastest aircraft, but the aircraft with the fastest decision cycle. Here’s the crucial distinction: a decision cycle includes feedback from previous actions, not just blind execution speed.

The logistics startup failed because they eliminated two steps: Orient and Decide. They jumped straight from Observe to Act. That’s not speed — that’s chaos.

Case Two: Lessons from Toyota — Speed Built Through Slowing Down

Now let’s go to a very different story.

In the 1950s, Toyota’s factory in Japan was struggling. They couldn’t compete with the Detroit giants like Ford or General Motors, who could produce thousands of cars per day with super-fast assembly lines.

What did Taiichi Ohno, the architect of the Toyota Production System, do?

He slowed down the production line.

Not slow in the sense of laziness, but Ohno introduced the andon cord — a rope that any worker on the assembly line could pull whenever they saw an anomaly. When the cord was pulled, the entire production line stopped.

Imagine this: your competitor produces 1,000 cars per day, and you choose to stop every time there’s a problem. Sounds like business suicide, doesn’t it?

But the effect was extraordinary. By pausing briefly to identify the root cause — through root cause analysis and kaizen — Toyota eliminated defects at their source. The result? Over the long term, Toyota became the most reliable and most efficient car manufacturer in the world. Their net speed — speed without rework, without fixes, without customer complaints — far exceeded Ford’s.

Ryan Holiday, in his book Stillness Is the Key, captures this philosophy: “Slow at the start, fast at the finish.”

Modern applications are easy to find. Basecamp, a software company, only works four days a week (32 hours) during the summer. They don’t “sprint” every day, yet their feature launch hit rate is very high because there are few revisions. Google mandates 20 percent time for free exploration, which gave birth to Gmail and AdSense. They don’t go full throttle every day — they create spaces of deceleration that produce massive acceleration.

Case Three: The Feedback Loop as the Only Speed That Matters

In 2001, a small team in Idaho, USA, was trying to assemble radios from cheap spare parts. They weren’t rocket scientists — they were tech enthusiasts in a rented garage.

Every time they built a radio prototype, they didn’t wait for board meetings or vendor approvals. They took the radio to an open field, plugged it into a laptop, and measured immediately: how many stations could it pick up? How clear was the sound?

They could complete this cycle several times per day. Each iteration took only two to three hours. Within a year, they had created a long-range radio wave system that was cheaper and better than military products worth hundreds of thousands of dollars.

That small team eventually became Spectrum Wireless, which was acquired, and their technology was used for disaster communication and military purposes.

What did they do differently? They weren’t faster in terms of working hours. They were faster in their feedback loop.

Eric Ries, in his book The Lean Startup, offers a simple formula: “The only unit of progress that matters is validated learning per unit time.”

In other words: how much proven-correct learning can you obtain per day, per week, per month?

Ries even provides a mental comparison. Startup A does one iteration with customer feedback per month — that’s 12 validated learnings per year. Startup B does one iteration with customer feedback per week — that’s 52 validated learnings per year. Startup B will win, even if Team B works at a more relaxed pace with less overtime. Because they learn four times faster.

Cross-Disciplinary References to Strengthen the Argument

So we’re not relying solely on anecdotes, let’s connect this to authoritative research and thinking.

First, Daniel Kahneman. The Nobel Prize-winning psychologist, in his book Thinking, Fast and Slow, explains that the human brain has two systems. System 1 is fast, intuitive, and good for routine matters. System 2 is slow, analytical, and necessary for important decisions. Competitive advantage lies in the ability to switch consciously between the two systems — not being trapped in System 1 all the time.

Second, Jeff Bezos. In Amazon’s 2016 shareholder letter, he wrote: “We are stubborn on vision, but flexible on details.” This is a statement about selective speed: never change your big vision quickly, but change tactics that aren’t working very quickly.

Third, Atul Gawande. The surgeon and author of The Checklist Manifesto conducted a hospital study. Teams that slowed down for two minutes to perform a checklist before surgery reduced complications by 36 percent and deaths by 47 percent. This micro-slowdown paradoxically accelerated overall patient recovery — because there were no repeat surgeries.

Fourth, the concept of Slack from Tom DeMarco. In his book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, DeMarco found that organizations operating at 100 percent capacity continuously — no free time, everyone busy every minute — actually have the slowest response time to surprises. Why? Because no one has any room to think, investigate anomalies, or respond to unexpected crises. Conversely, organizations that intentionally leave slack — 10 to 20 percent of total capacity as free time — are actually faster at adapting.

So, How Should You Think About Speed Correctly?

Based on the narratives and references above, let’s build a practical framework.

Principle 1: Distinguish Between Execution Speed and Decision Speed

Execution Speed applies to tasks with clear parameters — like coding from a finalized specification, sending routine emails, or manufacturing goods with standard operating procedures. Here, fast is good. The shorter the execution time, the more efficient the team.

Decision Speed, in contrast, applies to ambiguous or high-consequence matters — like strategic pivots, hiring a new VP, or setting product prices. Here, fast is dangerous. Strategic decisions made in haste will create technical and psychological debt that takes months to repay.

The risk if you reverse them: A team that treats strategic decisions like execution tasks will move quickly into a ditch. A team that treats execution tasks like strategic decisions will be paralyzed by analysis paralysis.

Principle 2: Use an 80/20 Ratio for Accelerators and Brakes

Twenty percent of your time should be allocated to deliberate slowdown — activities like retrospectives, assumption validation, and cleaning up technical and psychological debt. The remaining 80 percent goes to stable execution at a sustainable pace, not maximum speed that leads to burnout.

Principle 3: Measure Speed with Feedback Metrics, Not Output Metrics

Stop measuring “how many tasks were completed per week.” That metric is deceptive. Instead, use three metrics.

First, Cycle Time. This is the duration from when an idea emerges until it is successfully deployed and receives real user reactions. A team with a one-day cycle time will learn 30 times faster than a team with a one-month cycle time.

Second, Learning Velocity. This is the number of hypotheses successfully validated — whether proven true or false — per week. Validating that a feature isn’t wanted by the market is actually a win, because the team stops wasting resources on the wrong path.

Third, Correction Cost. This is the cost — in time, money, and team morale — to fix a wrong decision. A team that is “fast” but has a high correction cost is actually slower on net.

Principle 4: Imitate a Digital Andon Cord

Create a mechanism in your team to halt work when there’s an unexplained data anomaly, when team members feel they’re building the wrong feature, or when three consecutive revisions fail to reduce customer complaints. A one-to-two-hour pause for root cause investigation will save one to two weeks of future fixes.

Closing: One Real-World Story That Changes Everything

Let’s close with the most iconic example of misunderstood speed.

Kodak invented the first digital camera in 1975. Steve Sasson, a Kodak engineer, built a 4-kilogram device that captured black-and-white images at 0.01 megapixels. Kodak’s management asked only one question: “When will this be ready to sell?”

They wanted speed — to jump straight to a commercial product. But they never asked the more important question: “What can we learn from this prototype? How can we speed up feedback from the market?”

Kodak buried their invention. It took 20 years for competitors — Sony, Canon, and eventually smartphones — to eat away at their core business until they went bankrupt.

On the opposite path, Fujifilm — Kodak’s eternal rival — saw the digital era differently. They didn’t panic about being “the fastest to launch a digital camera.” Instead, they made a slow strategic pivot. They asked: “What expertise do we have — chemistry, materials, coating — that is relevant to a world beyond film?”

From there, they moved into cosmetics (sunscreen based on antioxidant technology from film chemistry), LCD screen protective film, and pharmaceuticals. They survived. Kodak did not.

So, the final question for you, your team, or your company is not: “How fast are we moving?”

But these three questions.

First: How fast do we learn? — Do we know within days or months that one of our assumptions was wrong?

Second: How brave are we to slow down for clarity? — Do we have a mechanism like the andon cord that stops production when there’s an anomaly, or do we force ourselves to keep walking on cracked foundations?

Third: How smart are we at choosing what to speed up — and what to stop entirely? — Do we keep building features that nobody uses, or are we brave enough to kill projects that show no signs of success?

Because the true competitive advantage is not being the fastest at the start of the race. It’s being the smartest at managing your rhythm — so that when your competitors run out of breath at kilometer 30, you’re just beginning to step on the gas.

“Fast is not a pace. Fast is a feedback loop.”