Skip to content

Why falling is difficult.

Software developers have an unusual relationship with falling – or better yet – failing. At Lobster, our integration platform sits between systems that were never designed to talk to each other, and process around 22 billion operational workflows a year.

When a mapping breaks in production, a start-up waits for payment, or a hospital waits for an order that never arrives. The tolerance for error at that point is close to zero.
That shapes how engineering teams in this space behave, and not always in a good way.

When every change feels like it could stop a customer’s operations, the natural response is to change as little as possible. Teams get very good at maintaining the status quo and struggle to push boundaries.

Where I learned to fall forward.

And I get it – I’ve been there. Things only changed when I became a CTO at a start-up with this brilliant mission statement:

We are all entrepre-nerds and we put our customers' needs and relationships above all. We do that by outsmarting everyone with the best people, latest technologies and commitment to the limit. Innovating by experimenting and learning, and we thrive in an open culture.

Our CEO at the time, Erik Gouka, lived that last line. He always focused on learning. He encouraged us to experiment and to fail, as long as we learned from it.

It taught me that a failure is a gift. It's an opportunity to learn, an opportunity to explore the unexpected – and this realisation is probably why my kids now count their falls on the piste.

The upside to failing.

Because a missed goal doesn’t mean you achieved nothing.

My daughter loves the quote: “Shoot for the moon. Even if you miss, you’ll land among the stars.”

As engineering advice, it is surprisingly useful.

Take a team that sets out to fully automate onboarding a new trading partner: upload a sample file and the connection builds itself. The first attempts will probably fail, because real partner data is messy, and edge cases pile up faster than automation can handle them.

But along the way, the team builds a format detector that recognises most incoming files, and a test harness that replays a partner’s historical traffic in minutes.

Neither was on the roadmap, but both discoveries save hours on every onboarding project for years.

That’s the moon and the stars in practice.

The ambitious version misses. But the failed experiment still leaves the team with several wins worth celebrating.

They found things they wouldn’t have discovered if they’d played it safe.

Pick where you fall.

This is not just a nice theory about giving engineers permission to play. Research into software delivery has repeatedly pointed towards the value of team experimentation and fast feedback.

DORA, which studies software delivery performance, explicitly identifies experimentation as a capability that helps teams test ideas and learn during development. They also flag small batches as a key contributor.

In other words: small, frequent falls beat one big crash.

It’s obvious if you think about it: Nobody learns a new jump at the edge of a cliff. You try it where a fall means a mouthful of snow, not a helicopter ride.

You don’t need more failures in production. You need more opportunities to discover failure before production.

Software teams need their own practice slopes: prototypes, sandboxes, automated test environments, synthetic traffic, feature flags and small experiments. The exact tools vary, but the principle is the same. Create somewhere safe for the unknown to be explored.

Why fear is holding your team back.

A child who gets laughed at every time they fall soon stops trying anything difficult. Teams are the same.

You probably don’t tell people not to experiment. But teams pay much more attention to what happens after an experiment fails than to what their manager says about experimentation.

That’s why I’m explicit about it: in my teams, nobody will ever get fired for making a mistake, as long as they learn from it.

That holds even when something goes wrong in production. When we have a critical issue on our platform, we run a Root Cause Analysis and document the findings. Those findings are turned into concrete action items, each with a named owner so every failure leaves us stronger.

The question goes from: “Did it work?”

To: “What do we know now that is new?”

As a leader, I think the job is to make the learnings from failures explicit and celebrate them as wins.

That unlocks the real advantage of a culture of exploration. It’s not that you get more ideas. It’s that you find out which ideas are worth pursuing before you’ve spent six months building them.

So, how many times did you fall?

On the slopes, falling is simply the price of getting better. Engineering is no different.

Next time you review your team’s quarter, try asking the question I ask my kids.

Not to count mistakes, but to find out whether anyone was pushing hard enough to make one.

If the answer is zero, ask them to push further. Pick a safe slope, aim for something just out of reach, and see what you learn on the way down.

Because if you never fall, you might get down the mountain in one run.

But you’ll never get any better at skiing.