How to Fail When You’re Used to Winning
A guide for managing morale while pushing for innovation
Innovation is a buzzword for our era. It evokes the promise of profiting tomorrow from today’s changes in technology. The word innovation implies a clean, crisp path. That’s a lie.
In fact, innovation requires enormous amounts of failure — which then presents leadership challenges.
Some organizations, like startups and corporate ‘innovation labs’, are set up to have high failure rates. The pattern is embedded in the high-risk, uncertain nature of the work. But any team that must experiment constantly will fail a lot, and repeated failure almost always depresses people.
This problem is serious, but not just because you don’t want your staff to feel awful. At least as important is this: when your team equates project failure with defeat, many will intuitively address the problem by narrowing the scope of new projects, in order to make them more likely to succeed.
In an entrepreneurial environment, this is exactly the opposite of what you want. Narrowing problems at the beginning of projects or implementing “best practices” will produce more predictable results, not more surprising and useful insights.
I see this often. For example, a few years ago, I ran a company where we wanted to test five different trainings with our clients.
The first few trainings went poorly, and our customers were unhappy. Nobody asked for refunds, but the experience was unpleasant. As a result, several people on our team argued that we should go back to our original training. Their impulse was to avoid disappointing and possibly losing clients if we failed to deliver good results.
That impulse is natural and normal — which is why you need to be ready to lead in a different direction.
Of course, there’s a lot of advice suggesting that companies should celebrate failure. For at least fifteen years, the phrase “fail forward fast” has been a rallying cry of tech-sector companies. Until recently, Facebook famously implored employees to “move fast and break things.” But human nature (and most company cultures) doesn’t reward failure at all. For many executives, the idea of celebrating failure feels like you aren’t holding anybody accountable. Indeed, shame and blame are much more common responses to miscalculations.
That combination is a rocket ship to low morale, which might more accurately be described as a silent directive to “move cautiously and take few risks.”
If failure is inevitable, how do you move beyond shame and blame — or avoid those sinkholes altogether? What’s a realistic version of celebrating failure?
When I was running the aforementioned training programs, it was my job to study and amplify how other people drove innovation. I found that early-stage startups tended to be relatively comfortable with the fail-often ethos — in part because they didn’t have much to lose. But young companies that were becoming more established, or established companies that were starting new divisions, often lost (or never learned) the skill of learning from failures, and tended to get debilitatingly depressed by them. The ideas in this article come from my own experiences, and from observing how others have taught their teams to be enthusiastic experimenters in the face of repeated failure.
These ideas will get you started. But — let’s not to get too meta — a recipe for failure in overcoming failure’s effects is to try all of the advice below at once. Instead, experiment thoughtfully with one or two ideas. Adapt them for your organization. Talk with staff about what you’re doing and how it’s going. Adjust to improve outcomes. Layer in new ideas. Set expectations properly: Maintaining morale can be tricky and positive change will likely be slow, but resilience is a solid foundation you’ll need to build something extraordinary.
Develop a written vision and mission statement — and refer to them often.
While some people consider mission statements to be words you frame and forget about, everyone wants their work to matter. A written mission statement, carefully crafted with staff input, helps the whole team see where you’re collectively trying to go. With that kind of framework, it’s easier for people to understand how even failed projects contribute. The lessons you learn help you home in on a bigger shared goal.
If you’re a small organization, it might take just a few days to develop a vision and mission statement. If you’re a larger organization, it may take you a few months.
Either way, what you’re shooting for is a statement that’s broad enough to encompass your ambitions, narrow enough to distinguish your organization from others, and pithy enough for people to remember. The good news is that you don’t have to get it 100% right from the start. Draft a few sentences that resonate, but don’t quite get people to run out to tattoo the phrases on their arms. Over the course of six months or a year, keep a sharp ear out for the pieces of the statement that people tend to repeat. Then use those to revisit and refine the statement.
When I worked for O’Reilly Media, we had a mission statement that was at least a paragraph long. Everyone referred to the mission regularly in deciding whether to accept book proposals, develop additional conferences, or invest in new divisions — except they used only one phrase in the paragraph: “spreading the knowledge of innovators.” In fact, I don’t remember any of the other language from the statement. I’m not surprised that over time, the company distilled the mission to that one phrase.
The magic of a mission statement emerges not from having written it, but from discussing it regularly when you make decisions. When you use it as a guiding force, it helps to make your decisions more consistent. That, in turn, helps everyone understand your organization’s purpose, and how their work, including their failures, are useful. Put another way: A series of failed experiments can feel like flailing. A mission statement helps package those failures as progress toward success.
I’m currently on the senior team for a young organization in the federal government. We took four months to draft a one-sentence vision statement and three-sentence mission statement. Although our organization was under 150 people, it took a while to get input from staff, including ideas on how we could measure our success in meeting the mission. While we weren’t able to reach consensus on perfectly wording the statements (a lot of people like to tinker with text), we did put a stake in the ground around a pretty good version of both — and agreed to revisit them in six months. We’re four months in, and already, a few phrases have emerged as beacons that help us make recognizable decisions. We know it’s working, because staff increasingly refer to the mission when talking about the consistency of our direction and how their contributions, including missteps, help advance us.
Incidentally, you can absolutely create a mission statement for a single division or team to help frame your work. But in most cases, it will read as strategic priorities, rather than a standalone vision. For example, let’s say your company consults on initial cryptocurrency offerings (ICOs), and you run the communications team. You work with leadership to determine the most important work your team can do to support the organization. Then you can codify whether your priority is sowing long-term seeds by making “ICO” a household phrase, is drumming up business by educating leaders at other companies about the potential value of an ICO, or is drawing in job candidates by showcasing the interesting problems your company solves.
Make failure an opportunity for learning, rather than for blame.
When things have gone wrong, everyone’s first impulse is either to say, “I made a mistake, and I won’t do that again” or “somebody else made a mistake, and you should tell them not to do that again.” My brother has been a student of failure while leading engineering teams at companies like Hubspot and Wayfair. He likes to point out that a better approach is to “plan for a future where we are all as stupid as we are today.” Which is to say: a certain amount of failure is inevitable. Accountability lies not just in individuals taking responsibility, but in teams having a consistent way to learn from those episodes.
A great way to do this is to regularly run postmortems and 5 Whys, which are sessions that depersonalize failure and focus on continuously improving your team’s approach. To facilitate these meetings effectively, you need a good set of questions, a way to capture lessons you can remember and share with others, and a sense of humor. If you train a small cadre of people to become good at facilitating these sessions for teams across your organization, you can create a culture that finds it useful — rather than terrifying — to review failures.
To ensure that people remember to hold these sessions, ask all projects to set dates ahead for postmortems (they can, of course, move the dates out as needed). And, when specific failures crop up mid-project, ask teams to hold a 5 Whys.
You’ll know it’s time for such a session when you’ve been asked to help troubleshoot a serious or repeated problem on a project team. I suggested one recently when several people from a project team mentioned that a client had been unaware of a key step they needed to take. They wanted to ensure that the software we were building with them could be deployed in their technical environment. The oversight cost them a few months in launch time, and is a preventable problem we wouldn’t want anyone else to go through.
Make the most of these sessions by asking project teams to write down the lessons, tag the components in meaningful ways for future readers, and systematically refer back to the knowledge base when starting new projects. Facilitators can help make sure the first two steps happen. Project leads can be responsible for referring back to notes at the outset of new projects.
When staff give internal demos on projects, ask them to include a substantial section on lessons learned.
Successes are good, of course, but when people help others by sharing their hard-won knowledge, it can go a long way for morale. Regular discussion of lessons learned makes it normal, not taboo, to talk about problems that have emerged. Teams that have done postmortems, 5 Whys, or regular retros will be primed to share this sort of information.
Set a regular time when teams can raise a challenge they’re facing, and individuals can step up to offer relevant expertise or knowledge.
This is useful both for making difficult patches a normal part of conversation and for giving individuals a way to help others. It can also help ensure that people share lessons across projects.
While it seems like a simple thing to do all the time, it’s easy for folks to forget (or never realize) that asking for help is great, and that their colleagues around the organization may have useful answers. You might start the practice by having somebody neutral (i.e., not a member of the project teams) interview a few teams for places they could use help, and then write up those questions to share with the organization. That person might also reach out to a few internal groups likely to have helpful ideas. Then set a time — perhaps a portion of your All Hands meeting or a standalone session — where you ask the project teams to review their questions, and then open them up for others to address.
This sort of meeting runs best with a facilitator who can help shape the conversation. Because it’s likely that not everyone who has ideas will have a chance to contribute (or will feel comfortable doing so in front of everyone), the facilitator can encourage people to follow up one-on-one after the meeting.
Use a spreadsheet, database or repo to track notes, code, and other assets from failed projects that can be reused in future projects.
The app never launched. The blog post went unpublished. The presentation was never given. Few things depress staff like work that doesn’t get used.
The first rule here: don’t build things for which you aren’t sure there’s demand. But the nature of failure is that often, you’ll invest time in something that never sees the light of day. Plus, in an effort to forget about it and move on, you’ll want to 86 the results. But if you take the time right away to document and file the things you did create, you’ll often be able to glean gems in the future from that scrap heap. This not only saves time down the road, but it also helps staff see that their work was not done in vain.
When I was trying to fill a role on my team last year, I put significant time into cultivating a relationship with a very good candidate. At the very last minute, the deal fell apart due to circumstances neither of us could anticipate or control. After yelling into a pillow for a few minutes, I cleaned up the notes I’d taken about the candidate and filed them away. Last week, when I needed advice about an usual matter, I ran some Google Drive searches to see if I had existing notes on the topic. My document about the candidate popped up, reminding me that they had relevant expertise. A quick call later, I had the info I needed — and I felt a lot better about having spent so much time developing the relationship earlier.
Publicly celebrate incremental progress.
When you’re in management, one of the hardest things is keeping in mind what other staff know (or think) about activity around the organization. So it’s easy to get out of sync when they’re participating in projects that get shut down while you’re also seeing projects that are working, the contracts you’ve signed, the job candidates who have accepted offers, and the positive feedback from customers. Help balance out what everyone knows — and ensure that people can see progress — by making time each week, in a regular meeting and/or a written note, to share a few small wins that not everyone knows.
You can make this practice easier on yourself by keeping a running list and updating it after senior team meetings and at the end of each day. Set calendar reminders for this activity (which can literally take as little as a minute a day), or you’ll tend to forget it each afternoon.
You can also bubble up good feelings from around the organization by asking people to share something small that they’re excited about on a current project. Have people comment in meetings or in writing; to get a range of contributors in meetings, announce ahead of time what you’re looking for, and share an example or two of small things you’re excited about. (“One of our biggest customers tweeted yesterday about how much they like our new product.” “We received a short, unhappy email from a customer last week. I called them, and it turned into a really productive conversation that generated some good ideas for us to try.” “OMG our new accounting software is saving me at least two hours a week.” )
Encourage staff to occasionally take up small, quick projects that are likely to be wins.
The longer and more complex a project, the less likely it is to succeed. Nobody wants to experience 100% failure at work. Help people stay buoyant by giving them opportunities to mix in smaller projects, where their expertise is likely to lead to some quick successes. Single-domain projects (rather than cross-functional projects) are well suited to this approach, because it’s easier to ramp them up.
For example, ask a UX designer or two to help a line of business with a user-research discovery sprint part-time for three weeks. Ask a content specialist to spend a few hours helping edit a presentation for senior team member.
Model the behaviors you want.
This is a truism of leadership, of course: model the behavior you want to see. It’s no more important than for weathering failure and maintaining morale. Without positive models, most people will assume that failure is something they should suppress. Platitudes about fast failure will not change that instinct. Instead, work with your management team to test out some of these ideas — and do it publicly within your organization.
When you make strategic decisions, explain to staff how you used the mission statement to rule out different paths. That grounds everyone, so when you’re reviewing a handful of invalidated experiments, you can credibly talk about how they’ll help you get closer to your goals. When you’re facing project or process failure, ask another team member to run a postmortem — and then post the notes. Share bits of progress in a weekly meeting or note.
Your path to succeeding at failure and maintaining morale will not be linear. You’ll stumble along the way and find yourself wanting to pretend you didn’t just trip. But stick with it. Teams that can maintain good spirits during hard times tend to win, and nothing feeds morale like success.