Plenty of tech companies tout a cultural value of “fail fast”: Accept that you will make mistakes; make those mistakes as promptly as you can; and learn from them so that you don’t make them again. It’s a liberating concept and great value.
But to truly succeed at a “fail fast” culture, it’s not sufficient to simply sit back and appreciate this value. You must also identify, and then root out, the causes of slow failure.
What things might you find in an environment that is failing too slowly?
Too much risk aversion
Failing to take risks may be the top contributor to teams not failing quickly enough. That’s because mitigating risk almost always involves slowing things down, investing elsewhere, and generally moving more cautiously.
And there are a lot of places you can do that:
- Spending months looking for a mythical “perfect” hire, versus pulling the trigger on someone who’s nearly there today.
- Being excessively consultative and adding more internal stakeholders and reviews, versus letting an owner run with, and live or die by, their judgement.
- Delaying or failing to make a hard but clear decision, like firing someone or killing a product, for fear of the (inevitable) negative reactions.
- Creating approval processes to avoid making a major mistake, versus creating a culture of strong autonomy paired with clear accountability.
- Investing too much, too early, in defense against risks that aren’t yet likely enough to hurt the business.
Fundamentally, each of these mitigations tries to get everybody comfortable. But comfort of everyone isn’t the main goal; rapid execution and learning is. We are trying to fail fast, not succeed slowly. It will be uncomfortable.
My number one antidote to risk aversion is to acknowledge the risk. Say and validate that it exists, and ensure that someone is accountable for it. “Yes, this could be the wrong hire — in which case, my job will get more difficult since I will need to replace them and manage the fallout. But I am comfortable owning that risk. I think they’re worth the bet, and we’re ready to start building.”
Managers and executives have the greatest responsibility here. This is because they have an invisible power which ICs usually do not have: risk-assumption privileges. Leaders can and must say, “I’ve got this if it doesn’t work”, establishing any conditions that need to be met in failure. A leader who is not regularly assuming risk in order to simplify their team’s mission, is failing at an essential role.
Low accountability
“Fail fast” simply does not work without a culture of accountability.
When an objective fails, the organization must learn why and respond with a correction. When there is no individual who understands it as their job to own that recommendation, no worthwhile nor shared lesson will be learned. After all, it’s not like a postmortem or roadmap change will materialize on its own. A human must bring the change.
Let’s think about a product launch for a major new software feature. Regardless of the type of software and feature, almost any kind of failure should have a short path to an accountable individual:
- If the product was buggy, unstable, or didn’t meet the agreed upon requirements, it’s the engineering team’s fault, with the engineering manager/lead as accountable.
- If the product’s features don’t meet customer needs or don’t gain enough adoption, it’s the product manager’s fault.
- If the customers buying the product were oversold or misled on its capabilities, cost, or benefits, it’s the salesperson’s fault.
This is of course a simplification. The point is that it should almost never be necessary to blame a product failure on some shapeless confluence of conditions, an act of god, or just bad luck. An organization unwilling to create accountability around a failure will therefore be unable to learn from it.
Finally and perhaps most importantly, if the spectre of future accountability isn’t looming throughout development and decision making, little more than hope ensures the team will execute well.
Empty-calorie goals
Worse than setting no goals is to set pyrrhic or “empty calorie” goals: Goals which fill you up with activity, but whose successes do not create the durable, lasting impact your business needs most.
Perversely, achieving such a goal looks and feels like a success—you hit the goal, after all!—but it diverted critical energy and focus which could have been better spent. You end the quarter with a one-off on-paper success when you could have had, at worst, a powerfully instructive failure.
The most general anti-pattern here is to set product scale goals before reaching product-market fit. Getting 100 new customers will feel good, but if they all want something a little different out of your product—in other words, you haven’t yet found fit—this “successful” goal is very likely to be setting you up for future churn rather than durable value. You’ve wasted precious time during which you could have been iterating on product functionality.
Good goal-setting takes scrutinizing the goal carefully against the future impact it will create. Look out for goals which, in their “success”, don’t accelerate you in the future.
Feel-good distractions
When you’re rich in feel-good moments that come from less important areas of the business, it could distract you from seeing slow failure on the much more important battlefronts.
A company whose corporate blog is chock full of news about trade show appearances, hosted events, fundraising rounds, and industry awards, comes off as one not laser-focused on their product. Internally, the product could be completely stagnant, but everyone at the company is fired up by all the fun exposure. Attrition is low and morale is high.
I am a big fan of companies with unique brand identity, and a disruptor’s market presence does matter when selling. But it only matters to a point. The question to ask is, how many purchasing decisions does all this investment change? Is it measured, even coarsely so?
As difficult as it may be to measure the positive return-on-investment of feel-good distractions, it’s also difficult to measure the negative effect that all this hubbub has on team focus.
My simple rule of thumb is that the product itself—its capabilities, new features, and success stories—should be talked about more than all the other stuff combined. Modeling this ratio starts at the top, with leadership reserving the highest forms of praise for things which level up the product, and scrupulously limiting investment in non-critical functions.
On a hunch, I took a look at the blog of one company I’ve admired as extremely product-focused, Cloudflare. In 2011, just about 2 years into their existence (and a full 8 before going public), it’s chock full of launch announcements and product features dominating the discussion. Healthy sign.
It’s not just management who can latch on to feel-good distractions. Imagine a technical team focusing on releasing an open source library, or a design team building a new collection of HTML form widgets, all while the company as a whole is straining to achieve escape velocity. Large and successful companies can afford to invest here because the business is already successful. It’s a mistake to model those behaviors too early.
It’s healthy and worthwhile to enjoy and appreciate the feel-good wins, and your culture must have pockets of fun. But don’t let them dominate your attention.
Turning things around
If an organization wants to embrace failure, it must be equally comfortable rejecting bad goals, eliminating distractions, and demanding accountability in failure.
As an individual in such an environment faced with pushing for this kind of change, “we can fail faster” should be your battle cry. And if in so doing—if you push and do not succeed—you have found your own fast failure to learn and to move on from.