How To "Move Fast & Break Stuff" by Managing Risk Optimally

Hello 👋

Martin here. Welcome to the first Guest Edition of Founders’ Hustle!

Today I’m sharing something very special with you — a guest essay by a super smart, talented, and experienced founder and operator… Seppo Helava. 🤩 

Seppo has incredible B2C pedigree—specifically in gaming—where he has been involved with many amazing companies including as co-founder of Self-Aware Games (acquired by Big Fish) and as an advisor and investor in Huuuge Games (upcoming IPO).

You can check out Seppo’s LinkedIn profile to get the full rundown. And, he said feel free to get in touch if you’d like to talk! What an offer! 😮

Below Seppo shares real first-hand practical insights on such a critical subject for startups—how to move fast as a team through optimal risk management.

Highlights:

• Why you should make failure normal and how to do it. ⚒️

• The difference between dumb and smart failures. 🤔

• Why you need to minimize inertia and understand different perspectives of risk tolerance. ⚠️

Not subscribed? Let’s fix that now 😉👇

by Seppo Helava

People often talk about how Silicon Valley’s “Move Fast & Break Stuff” ethos is one of its secret weapons.

This idea can be implemented in a huge variety of ways, from the wildly unethical, to the ill-considered, to just using the phrase to handwave away chaos and poor leadership.

But at its core, there is a secret weapon in that phrase. 🔫

If you can do it right, the ability to move fast, and the willingness to break (the right) stuff can result in learning massively faster and more effectively than your competition.

But there’s a huge challenge in implementing a culture that can move fast and break stuff in a positive way.

Why should you listen to me?

I co-founded Self Aware Games and ran it from 2009-2013.

In that time, we competed in the most competitive market in videogames - mobile casino games - against the most hyped, best-funded opposition, and we beat them with a team a tenth the size with a hundredth of the budget because we iterated faster, and were willing to make bigger changes than they could.

I believe that if you can build a team whose core skill is to learn quickly, no one can beat you. At anything. 🥇

So why doesn’t everyone just build a team that iterates quickly and learns from those iterations? Well, it’s harder - and more importantly, *weirder* - than it looks.

We’ll start with the more obvious and larger-scale, and work our way to the more subtle, and more individual bits. So let’s start with mitigating risk.

Managing Risk

You might hear about teams that “celebrate failure”. 🥳

That failure is an inevitable and important part of iteration and learning. That you should learn to “fail fast”. I get it.

But failure isn’t the *point*. The point is *learning*, and problem with failure is that the stigma of failure causes people to be too risk-averse to try new things.

My point is that failure isn’t the thing you should be focused on.

Failure comes in all kinds of different sizes - smart failures, where people make great decisions and try bold things but it doesn’t work out, and dumb failures, where people make stupid mistakes.

Saying all failure is positive doesn’t hold people to account in your culture. Failure isn’t *good* in itself.

One of the problems of adopting a “fail fast” mentality is that in that case, the “dumb failure” example would be a good example of failing fast.

They bypassed some normal review or discussion or design process to get a concept out quickly, and they failed fast. But did they learn anything useful or interesting from it? I doubt it.

What you want to do is make failure *normal*. It’s just a consequence of doing stuff.

Sometimes it’s good, sometimes it’s bad - but you evaluate the failure the same way you do anything else.

• How did decisions get made? 🧠

• Were there mistakes? ☢️

• What can you learn from it? 💡

If there are things people need to be accountable for, you handle that in the context of failure the *same way you do in the context of success*.

It’s not the *failure* that drives things, because failure is just a normal state of affairs.

This may sound odd. But if you’re running a team that’s trying to make something new, you’re going to fail a LOT.

As a leader, you will likely understand that you’re taking a lot of shots at something, and not everything will stick.

But one thing that’s going to come up again and again in this discussion is this:

As a leader, empathy is critically important. Because you can better understand that to an individual contributor (IC) - let’s say a new, junior person on your team, failure sucks.

And the ICs aren’t necessarily the ones making the decisions to “take a bunch of shots”. The team may distribute risk, but the IC is executing on one thing, and pouring their heart and soul into it. If it fails, it’s crushing.

So how do you teach someone that failure isn’t crushing? 🎓

You make it normal. You destigmatize it. You talk about the failures you have and the successes you have in the same general tenor.

And this is hugely important — I can’t understate how important it is — you have to talk to people who fail without being angry or upset. It’s just a thing that happened, and you talk about it in a completely normal, neutral fashion.

You’ll need to address why, you’ll need to figure out what went wrong, how to learn from it, and how to not have it happen again.

But all that discussion needs to happen without vitriol, anger, frustration, etc. ☮️

Because — and we’ll talk about this more later — people will remember how you responded, and will work to avoid negative responses.

How you respond to this will dictate how your team responds to risk. This is one of the most important things you can do as a leader.

Next, you talk about failures with the same general frequency as you do successes (if not more so, because you’ll probably have more failures than successes).

You can also put failures into the larger context of the company’s goals - we tried X, and here’s why it didn’t work. Here’s what we learned from it. Here’s how we move forward.

You make sure that the consequences of failure aren’t fatal, for the company or the individual’s job. ☔

And that leads straight into the next point…

Systemic Robustness & MVPs

Failure can be crushing, both to individual morale, and to the company’s fortunes.

As a leader, you have to address both, and make sure that systemically, your team ensures that failures do the least possible damage to morale, and don’t create unsustainable risk for your company.

A lot has been said about Minimum Viable Products. You can read all about it in other articles. But one thing I want to reinforce here is that the most important part about MVP is something people often gloss over: Minimum Viable.

What you need to build is the least you need to answer a specific, focused question. That’s what an MVP is for. That’s all an MVP is for.

Why? 

Because one of the most valuable things that an MVP does for you is that it minimizes risk. Not just to your company’s budget or timeline, but also to employee morale. 🎉

If you’re building something genuinely new, you’ll fail a lot. Each of these failures hurts morale, no matter how much you’ve normalized failure.

Because you have to change direction, which results in work that gets discarded, and throwing out work is always frustrating.

Think of a car going around a corner, and then needing to suddenly change direction.

If you have a tall truck, loaded with lots of stuff, when you suddenly change direction, there’s a lot of inertia. The truck wants to keep going in the same direction because of that inertia. Changing direction suddenly makes the stuff in the truck fall over, fall off, and in some cases, tip the truck over entirely.

Instead, what you want to do is build a low-slung, lightweight sports car. Chuck it into a corner, and you can go faster and be more stable because you’re carrying less weight. Instead of tipping over, the car gracefully changes direction, and you’re off to somewhere new. 🏎️

You need to minimize inertia. You need to make changing directions cost the least. A genuine MVP approach means you’re building the least you need to answer a question.

If you answer it positively, you add more to the product. If it’s answered negatively, you change direction. And the less stuff you have to discard or change, the less morale impact, it has, the less $ you’ve spent, and the less time you’ve consumed.

So in order to go fast, build a sports car, not a truck.

One note that’s important here — if you’re making truly minimum-viable MVPs, you will likely feel uncomfortable releasing these things to the public.

That’s correct. ✅

Because an MVP is not polished and refined — it’s not the best work you can put out into the world. It’s a question you’re asking the audience.

If you wait until you’re comfortable, you’ve added too much weight. If you’re comfortable now, ask yourself what you can get to get to minimum viable. It’s likely a lot more than you think.

Perspective, Empathy, and Fear Inform Risk Tolerance

To go back to the point of empathy and understanding, one of the things I found to be really surprising when I became a leader, was that peoples’ perspective on risk was not just tied to their personal risk tolerance, but their perspective — which was highly informed by how much information they had, and how safe they felt.

At one point, we were revamping the critical purchase flow for the game we were making. This was after our company had been acquired, and new “oversight” had been put in place by the acquiring company.

In order to minimize risk, there were a lot of reviews of the purchase flow changes. 🧐

Senior managers wanted weekly updates, which resulted in a lot of meetings. A-B tests, focus tests, and all kinds of testing was put in place to really understand the differences between the old and new flows, and whether there was any possibility that things would be broken.

This was not how I would have approached it, but because the acquiring company felt strongly about this, we did it their way.

After four months of weekly reviews and dozens of tests, the new purchase flow was rolled out, and the resulting change was… nothing.

Now, many companies would see this as a ‘no-op’. Nothing was gained, but the purchase flow was now prettier and more modern, but most importantly, we didn’t lose anything. By being careful, we preserved the status quo.

My perspective was a little different. 👀

We’d spent literally hundreds of thousands of dollars in time in review meetings.

Important peoples’ time was consumed for months. PMs prepped reports, and did tests. UI/UX folks did and re-did flows. Senior managers, all the way up to the new General Manager for the product were involved in hours-long reviews every week.

Work was created and discarded, which resulted in a morale hit across the team, and in the end, when the results were essentially nothing, confidence in the team leadership took a hit, because all this time and effort was for naught.

Here’s the thing: We had a robust release infrastructure. We could deploy changes, observe those changes, and roll back code at the push of a button. ⏪

I realize a lot of people say it’s that simple when it’s not, but for us, it was. What we’d done in the past, and what we should have done here was simply make a change, test it internally, and roll it out.

At the time, if the entire purchase flow failed, it would have cost the company about $100K/hr. At worst. It would take us about 15 minutes to see that there was a problem and roll it back.

So let’s say we did a *terrible* job, and it took us a full hour. We’d lose $100K.

But, we knew how to message players and let them know when we’d made mistakes, and usually, we’d recover revenue a few hours later. So the cost of making this change and completely bungling it was $0.

We could have iterated the purchase flow every week on our regular release schedule, which means over the course of the four months it took to get manager approval, we could have released sixteen iterations of the purchase flow.

And instead of relying on managers’ intuition or judgment, we’d be relying on player behavior and data.

The failure here is that to almost everyone, the “safe” path made sense. 🚨

To the new managers, they wanted to make sure that the numbers didn’t dip under their watch. Mission accomplished.

To an individual contributor, no one wants to be responsible for costing the company $100,000 per hour.

Because in most jobs, a mistake like that gets you fired.

Two things:

First, when I talk about perspective, what I mean is that to any IC, they see the $100k/hr cost, and are scared of it. 🙀

But they don’t see the cost of meetings. That time is literally money in salary costs, overhead, etc. And that doesn’t count opportunity cost. A lot of that is often invisible to ICs, and usually, rightly so.

But it means that a leader needs to understand the differences in perspective when it comes to risk tolerance, and why an IC wouldn’t propose risking breaking the purchase flow, but a manager should.

Second, we made mistakes like that all the time. ⏰

That’s why we had robust infrastructure to roll changes back. That’s why we’d developed a way to reach out to users when the game went down or had problems, and make sure they’d come back when things were fixed.

We made those investments because failure is normal, and infrastructure is necessary to make sure normal things aren’t fatal.

Unfortunately in this situation, even team members who knew we had all these tools at our disposal went along with the “safe plan”, because new management was in place, and they were trying to understand how to roll with the changes that came from acquisition.

And most people won’t risk their job over something like this. Nor should anyone expect them to.

This was, in essence, the beginning of the end — when a company gets acquired, things often change, and to me, this difference in management philosophy was a fatal mismatch, and it was at this moment when I knew my time with the company I’d started was up.

It was, uncoincidentally, also the moment that the game stopped growing at the rate it used to, and settled into a slow decline that’s lasted to this day. 📉

Never Get Caught

There are myriad reasons you want to iterate fast and maximize your ability to learn.

It’s the best way to build new things. It’s the best way to carve out a space in the market.

But one of the more interesting benefits, in a world where a lot of your competition relies on competitive analysis and watching what you’re doing — if you learn faster than anyone else, you’ll never get caught. 🚀

You don’t need software patents. You don’t need to keep secrets. You can do everything out in the open, because no matter how diligently your competition watches what you’re doing, they can never beat you to where you’re going.

You will always be multiple steps ahead, and your competition will always be scrambling to catch you.

—

Thank you Seppo for sharing your wisdom! 🙏

Remember, Seppo said feel free to reach out on LinkedIn if you’d like to talk!

Until next time, Martin 👋

To receive more newsletters like this, subscribe below. 👇