The trick is figuring out how and when to fail.
The minds at Pixar Animation Studios, responsible for an almost unprecedented string of original hit movies, believe in failure. The philosophy of the studio's heads is to get all the failures out of the way early, and keep polishing. As President Ed Catmull has written, "Management's job is not to prevent risk but to build the capability to recover when failures occur."
That's not the way things have worked in government. Failure has not been an option. When America's greatest government bureaucracy was built up in the 1940s, it was wartime and the consequences of mistakes were dire. Often processes were conceived and executed by military veterans who associated imperfection with laziness, recklessness and death. After all, you can't make a mistake with an atom bomb, or planning an invasion, or sneaking a rocket scientist over the Berlin Wall.
You can, however, make a mistake with a government website or other technology system, and there are times when you should. Whether at the city, state or federal level, there's an increasing realization that failure is essential to the eventual success of a complex technology project. The trick is figuring out how and when to fail.
The reasons for accepting small amounts of risk have to do with the ways government is changing. We're seeing government agencies adopt a customer focus, moving to prioritize citizens and businesses who use public services. We're also seeing a breakdown of walls between agencies and between higher- and lower-level employees. And we're seeing modular, agile approaches to procurement and development.
These approaches make sense together. Customer-centric design requires regular testing and updates to refine the user experience. Agile development, with small, modular gains, permits the kinds of fast improvements that customer-centric design assumes. Changes in governments' approaches, however, will require their managers and rank-and-file employees to adopt a new mindset. They will have to learn to fail well.
That won't be easy. Anne Rung, administrator of the federal Office of Federal Procurement Policy, remarked that one of the key obstacles to procurement innovation is the mindset in government that failure is not an option: "We don't tolerate any kind of perceived failure. And people immediately walk away and resort to the old way of doing things."
There are obvious reasons to fear failure. Bureaucracies notice and reward metrics. Failure appears on a record, but quiet mediocrity is safe. The bias is toward invisibility, documentation and taking credit. And perfectionism has merit. There is value in getting things right the first time. Theoretically, avoiding mistakes is cheaper and prevents a tangled mess when minor imperfections compound into systemic failure. Even in the risk-praising world of software development, it's known that fast and messy approaches function temporarily, but that excellent design lasts.
The conflict is over how to create that excellent design - or, rather, whether excellent, enduring systems are something you design or something you find. Designing a system in its entirety as Step One implies that a team can predict a user's requirements. But requirements change. Often, it's difficult to anticipate how actual users will react to or repurpose a product -- think of Twitter inadvertently facilitating citizen journalism. Testing becomes essential. Prototypes permit testing.
In some ways, embracing risk is a small change of mindset, from never crossing the line into failure to being willing to tiptoe over it in service of a better end. Detail-oriented execution is still crucial to a project's success. But in a mindset inspired by agile development, painstaking execution comes on tighter deadlines. Under this pressure, flaws are more likely but are not catastrophic. They'll just be revised in the next release.
Taking risks and welcoming mistakes can create robust products, but that's not the only reason for a new mentality. The calculus of risk itself is changing: The costs are lower and the rewards are higher.
First off, technology has made change cheaper. So failure is cheaper. Even processes we don't think of as technological, such as the organizational structure of a team, can be changed without the expense of typing up and distributing memos.
And we now have the public cloud. Ten years ago, a large IT project might require procuring servers and building a data center to store them before the first line of code was written. Now, the existing remote servers that make up the cloud can simply be repurposed as needed. "We can [use] them, and turn them right off again-and we have spent almost nothing," says Mark Schwartz, CIO of U.S. Citizenship and Immigration Services. "It's a huge enabler for breaking things down into small pieces of work and delivering them quickly into prduction, so that we can then start immediately tweaking it."
Not only is failure cheaper these days, it's more necessary. With the fast pace of change, it's nearly impossible to predict what citizens will be demanding from their governments in five years. To keep up with those changing needs, an ethic of constant iteration has become essential. For complex projects with a digital component, flaws are just plain more likely -- and a key ingredient for success.
This story was originally published by Governing.