Win or lose? I prefer experiment and learn.
3 things occurred:
1. CTO Coachings on “Bets” – Learning to break work into plays (business cases) that I can sell to the business. Every initiative falls into one (or more) of four categories:
- Momentum Builders (iterative improvements, process gains)
- Debt Paydown (tech debt, foundational work)
- Revenue Plays (directly impacting growth)
- Risk Reducer (reduce chances of losses)
2. David Heinemeier Hansson (DHH) tweeted: “Enjoy being at the table”
3. I read Satya Nadella’s autobiography ‘Hit Refresh’. In it Nadella describes Microsoft’s survival as a series of big bets. The company had to place them to stay in the game.
All of this reinforced an idea I have held for some time: engineering is not gambling; it is science.
Bets vs. The Scientific Method
The Scientific Method is about learning and refining through experiments.
• A failed experiment isn’t failure, it’s progress.
• A failed bet? The house always wins in the long run.
When I was applying to study Computer Science, an interviewer at Cardiff University asked me: “What is science?”. It turned into an intense 15-minute discussion that shifted my entire way of thinking.
Science doesn’t prove things, it only disproves. You can’t prove a theory; you can only test it, refine it, and disprove past assumptions. Experiments allow us to progress and evolve our understanding.
That mindset is critical in engineering and product development.
Engineering is not a casino, nor is it risk-free
I’m not advocating for moonshots and endless experiments. It’s about balance:
- If everything is a moonshot, nothing gets done.
- If everything HAS to work, you kill creativity, risk-taking, and ultimately innovation (and culture).
I’ve seen teams paralysed by an over-focus on error reduction, to the point where no one wants to take risks. That’s when products stagnate, engineers disengage, and the culture turns sour.
Complexity, uncertainty & the business’ perspective
Complexity and unknowns in tech do not translate well to the business. From a leadership perspective, it can look like writing blank checks for uncertain outcomes. The skill of an engineering leader is partnering with the business, translating engineering reality into a language they understand, trust, and can influence.
That means:
- Explaining the impact – What does this work achieve?
- Demonstrating progress – Where are we in the journey?
- Connecting to business goals – Why does this matter?
- Offering Options – What else could be done?
Iteration, feedback loops & not fearing failure
In tech, you rarely get everything right on the first go. The best engineers, leaders, and teams iterate. They adapt based on what they’ve learned. Given the space and trust to develop. Held accountable but not fearing failure.
A good mechanic often knows the issue before even opening the bonnet; experience, pattern recognition, and repetition build that instinct. The same is true in engineering. The more you experiment, learn, adapt and take accountability, the better your estimates and judgment on when to push forward and when to pivot.
The key takeaway? You need both structure and freedom
- Alignment upfront gives teams autonomy to execute without micromanagement.
- Failing fast and learning fast creates a culture of continuous improvement.
- Engineering leaders must bridge the gap between complexity and clarity.
Ultimately, the goal isn’t to win every time, it’s to keep getting better at the game.
What do you think? Are you a gambler or scientist?
Follow up post: Not all experiments succeed
Olly Brand 
2 thoughts on “Gambler or Scientist”