Watch Me: The Defiance-to-Data Pipeline

I have a friend who plays strategy games the way some people approach religion — with absolute conviction and zero tolerance for doubt. Risk. Civilization. Alpha Centauri. The kind of games where you’re building empires while everyone else is still figuring out the rules. His signature move, whenever someone suggested he couldn’t pull off some audacious play, was a two-word response: “Watch me.”

Not defensive. Not angry. Just a quiet declaration of intent. A verbal line drawn in the sand, followed by stepping over it.

I didn’t realise until years later how much that phrase had rewired my brain. “Watch me” became my default response to doubt — my own and everyone else’s. It turns out this is both a superpower and a time bomb, depending on what you do after you say it.

The Psychology of Productive Defiance

There’s a name for what happens when someone tells you that you can’t do something and you immediately want to prove them wrong. Psychologist Jack Brehm called it psychological reactance back in 1966 — an unpleasant motivational arousal that emerges when people experience a threat to their free behaviours. When someone says “you can’t,” this motivational state kicks in, aimed at re-establishing whatever freedom was threatened.

“Watch me” is reactance weaponised into action.

Here’s the thing: this isn’t a bug in human psychology. It’s a feature. The economist Albert O. Hirschman, who studied entrepreneurs and development projects across decades, observed that “creativity always comes as a surprise to us; therefore we can never count on it and we dare not believe in it until it has happened.” The “watch me” mentality is what gets you moving before you have proof that moving is the right call.

In product engineering and startups, this matters enormously. Every significant technical bet I’ve made — migrating architectures, adopting new frameworks, pushing back on “that’s how we’ve always done it” — started with some version of defiance. Someone said it couldn’t be done, or shouldn’t be done, or wasn’t worth doing. And something in me responded: watch me.

The Fuel That Burns Out

But here’s what nobody tells you about running on spite: it’s rocket fuel, not diesel. Brilliant for escape velocity. Terrible for the long haul.

I’ve watched engineers — talented ones — burn themselves out trying to prove doubters wrong. I’ve done it myself. You ship the impossible feature. You hit the deadline everyone said was unrealistic. You prove them all wrong. And then you wake up exhausted, with nothing left in the tank, wondering why victory feels so hollow.

The writer Anne Lamott, who wasn’t talking about software but might as well have been, put it perfectly: “Lighthouses don’t go running all over an island looking for boats to save; they just stand there shining.” Pure defiance is the opposite of this — it’s running around the island, frantically proving to every passing boat that you can save them.

Rand Fishkin, who built SEOmoz into a major platform after being rejected by over forty venture capitalists, was honest about this trap: “When I analyse my motivations in those years, there’s little else that kept me ‘in the game’ apart from that incessant need to prove the doubters among my friends and family wrong.” That need got him started. But he’s also written about how staying in that mindset leads to exhaustion and poor decisions.

The research backs this up. Founders who remain in a “prove them wrong” mentality and don’t mature past the negativity eventually fatigue. Defiance alone isn’t sustainable. You need something else.

Enter the Data

Here’s the insight that changed how I approach technical risk: the sustainable model pairs fearless follow-through with systematic data collection.

Think about what actually happens when you take a leap based on “watch me” energy:

You make a bold betSomething happensYou learn somethingThe problem is that most of us stop at step two. We either succeeded (vindication!) or failed (time to find someone else to prove wrong). We don’t systematically capture what we learned. We don’t use the outcome to calibrate the next leap.

The result? Each risk feels just as terrifying as the last. You’re gambling blind every time, relying on pure emotional fuel to push through the fear. No wonder it burns out.

But when you add data collection to the loop, something shifts:

You make a bold betSomething happensYou capture the evidenceYou use that evidence to inform the next betNow each subsequent risk is more informed than the last. Fear becomes manageable because you’re not gambling blind — you’re gambling with better odds each time. The defiance gets you moving; the data keeps you moving.

Peter Thiel’s famous advice to Mark Zuckerberg captures one half of this: “In a world that’s changing so quickly, the biggest risk you can take is not taking any risk.” True enough. But Thiel built PayPal with obsessive attention to fraud metrics, user acquisition costs, and transaction data. The risk-taking was bold. The follow-through was methodical.

What This Looks Like in Practice

We talk a lot about data-driven decision making in engineering. But that phrase usually means “wait for the data before deciding.” That’s not what I’m describing. I’m talking about collecting data because you decided — using your bold bets as experiments that generate evidence.

Here’s a concrete example. A few years back, we had a service that everyone was afraid to touch. Classic entropy case — the original authors had moved on, the documentation was fiction, and the last three engineers who’d attempted changes had spent weeks in debugging purgatory. The safe play was to work around it forever.

“Watch me” energy said: we’re going to refactor this thing.

But instead of just charging in, we set up instrumentation first. Response times, error rates, dependency call patterns. We documented every assumption we were making about how the service actually worked. Then we started refactoring, capturing what we learned as we went.

Six weeks later, we had a cleaner service and a playbook for tackling similar situations. The next scary refactoring project took three weeks. The one after that took one. We’d converted defiance into a repeatable process.

The statistician George Box wrote that “all models are wrong, but some are useful.” The same is true of bold technical bets. They’re all uncertain. But some of them generate useful information that makes subsequent bets less uncertain.

The Gambler’s Edge

Here’s something counterintuitive: research suggests that entrepreneurs aren’t actually bigger risk-takers than the general population. They’re just better at managing and assessing risk. The willingness to act isn’t about having less fear — it’s about having better calibration.

This maps directly to the “watch me” framework. The defiant leap isn’t reckless gambling. It’s the willingness to act combined with systematic learning. You’re not ignoring the risk; you’re accepting it as the cost of generating information you can’t get any other way.

In engineering terms: sometimes the only way to know if an architecture will work is to build it. Sometimes the only way to know if a team can hit a deadline is to commit to it. Sometimes the only way to know if a refactoring is worth it is to start. The question isn’t whether to take the leap — it’s whether you’re capturing what you learn when you land.

Sometimes you need to not only risk failure, but actually fail to learn.

Converting Defiance to Discipline

If I could distill this into actionable advice, it would be:

Keep the “watch me” energy. It’s what gets you moving when analysis paralysis would keep you stuck. When someone tells you that architectural change is too risky, that deadline is impossible, that refactoring isn’t worth it — let that spark of defiance push you forward. Just don’t let it be the only thing driving you.

Build the evidence loop. Before you leap, decide what you’re going to measure. Not to justify the leap — you’re doing it anyway — but to learn from it. What would success look like? What would failure teach you? What assumptions are you testing?

Use the data for the next leap. This is where most teams fail. They take the risk, they collect the metrics, and then they file it all away and approach the next decision as if they’ve learned nothing. The whole point is to make each subsequent bet more informed than the last.

Recognise when you’re running on empty. Pure defiance has a half-life. If you find yourself taking increasingly aggressive risks just to feel something, that’s not courage — that’s desperation. The data loop should be making your bets smarter over time, not just more frequent.

The Bottom Line

The physicist Richard Feynman, who knew a thing or two about bold intellectual leaps, described his approach this way: “I have approximate answers and possible beliefs and different degrees of certainty about different things, but I’m not absolutely sure of anything.” This is the opposite of blind conviction. It’s confidence calibrated by evidence.

“Watch me” gets you started. Data keeps you going.

The engineers I respect most have both. They’re willing to make bets that others won’t, to push back against “that’s impossible,” to draw lines and step over them. But they’re also relentless about capturing what they learn, using each outcome to inform the next decision, building a body of evidence that makes subsequent risks less risky.

Your codebase, your architecture, your team’s velocity — they’re all products of decisions made under uncertainty. You can’t eliminate that uncertainty. But you can get better at navigating it. You can convert spite into signal.

So the next time someone tells you you’ll never be able to do that, reply with “mate… Just watch me”

Just make sure you’re taking notes.