One of the most overused and misunderstood phrases circulating around my organization right now is: fail fast.

Everyone says it but no one can define it. Oh but they might try: “It’s, you know, skunkworks, pilots, hackathons. It means we have to be agile.”

Pardon me while I roll my eyes audibly over here.

If you want to fail fast, it means you have to do one thing. No, really. It means you have to actually do one thing. 
Something. 
Anything. 
Deliver.


We work in a culture that rewards waiting for approval. For example, there’s a service strategy, but all it really says is: you should have service standards. And it’s so vague that very few people are actually developing service standards for their services. No, they’re waiting for the policy interpretation which will give them some minimal compliance requirements by which they can do the minimum and say, gravely, “Yes, we have service standards.”

We have standards for our websites, but where at one time we were capacity building in the domain of user experience, suddenly all of that stopped as the organization reduced its efforts to minimum compliance. And now there is a lack of UX capacity across the organization, and minimum effort to actually produce services that are user-centered.

Waiting for standards, policies and permission means that we reduce our risk taking. We stop our doing. We don’t deliver. We are paralyzed by our fear of failure. Instead of just doing it, failing, learning, adapting and getting better.


So it’s time for a little kick in the pants. If you are stuck trying to figure out how to fail, here are a few handy examples to help you stop waiting for permission and start failing successfully:

• Take a semi-formed policy (e.g. service, digital, etc) and apply it to your project. On my project, we are developing better KPIs by developing clear and measurable service standards that are centered around the user’s experience of the service. And then we’ll take them to the service people as a sanity check: hey, is this what you had in mind when you wrote that policy? Yes? No? Help us tweak it. Let’s make it better. And when we’re done, feel free to use us as a reference project.
• Build a prototype and put it in front of users. Study the old service, research the hell out of what users want from the new one, use industry heuristics (not those made-up organizational ones), make it good enough and then put in front of real people. Then tweak, test, tweak, test. Look at you being agile!
• Stop talking about shiny tech and just use it. Does your service have a real problem that needs a shiny tech solution? No? Then don’t try to force one! Yes? Lucky you! Stop talking about it, and just apply it. Pilot it. Test it. Tweak it. Put it in front of users and learn from them (see last point).
• Only measure things that matter. Execs making you measure vanity metrics? Fine, do it. And then show them real metrics that mean something. Tell them how it makes your service better to know this info over that info. Show them how it makes them better at reporting and knowing what’s going on with the service they oversee. Teach them to ask for better metrics. Maybe they’ll bite, maybe they won’t. (How good are your storytelling skills? Can you convince them?)
• Do the same thing in a totally different way. Maybe you work in operations and you could try a different approach at delivering the same results. Maybe you’ll find efficiencies. Maybe you’ll reignite the passion in your dead-eyed staff who’ve been following antiquated processes just because that’s what they’ve been taught. Maybe you’ll fail and learn something. At least you learned something. When is the last time you did that?
• Stop looking for giant solutions to everything. Stop innovating. Look for small wins. Things you can do right now. Without permission. Watch progress happen. Re-steer your Titanic under your own power.