What Geeks Can Teach Government
Technology development works very differently from the way government programs are launched, managed — and ended. There are lessons for government in the way the gadgets we use are created.
Most of us expect increasing sophistication in our technology. And generally, over time, we've gotten it. We've gone from large mainframes to today's smartphones, which carry more computing power than NASA used to send a man to the moon.
In getting to this point, we've abandoned outdated technologies. Music is a perfect example: We abandoned eight-tracks for cassettes and cassettes for CDs, and then left CDs behind for MP3s.
This sort of pruning comes naturally in free markets, through what economist Joseph Schumpeter called "creative destruction." It helps technology evolve and provide the services and functions we expect.
But what if markets didn't evolve in this way? Imagine a world in which a new smartphone is delayed because it has to integrate with a mainframe computer from 1980. It sounds ridiculous, but that's essentially how government too often works.
Promoters of innovative models in government must battle antiquated regulations and bureaucratic inertia. Governments almost never do the pruning needed to make room for new growth.
What would happen if we applied the principles of technology development to government programs? How might government operate differently?
Plug and Play
Today, all too many programs outlive their usefulness. Dismantling or redesigning large government programs is a Herculean task — one that prevents an efficient response to rapid shifts in society, technology and the economy. What we need is a way to rapidly disassemble and rearrange elements of government programs that no longer make sense.
The software world calls this "modular development." All the parts work together, but at the same time any piece can be added or removed without rendering the full system unusable. Salesforce. for example, is a customer-relationship-management software system that offers more than 3 million customers different product modules to help them boost sales. As the customers' needs change, they can add and remove the different modules quickly and easily, without handicapping the other modules.
A similar approach could be adapted to government programs. Large efforts such as homelessness prevention could be broken into smaller, loosely coupled initiatives, with the functions and goals of each clearly delineated. The components could be redesigned or jettisoned as needed to improve the overall effort.
For years, the "waterfall" development model dominated the world of software development. This process flowed steadily downward, from requirements to design to implementation to testing, and finally ending at maintenance. It worked well enough for a time, but it had a major drawback: Changes after the initial deployment often proved cost-prohibitive. Everything had to be accounted for in advance.
Ultimately, developers realized that this posed a critical limitation, simply because people rarely get a design right on the first try. To overcome this, developers shifted to an "iterative" development model that allows for constant evolution through recurrent testing and evaluation, an approach called "agile development."
Agile development is all about rapid delivery, regular adaptation and unyielding attention to design and technical excellence. It explicitly assumes that we rarely get the design right the first time.
Google takes the idea of constant refinement very seriously. Gmail launched in 2004 to an invitation-only group of users. The email system remained in "beta" for more than five years, despite garnering more than 100 million users. Google felt the label conveyed the constant refinement it was pursuing.
Why not try doing more "beta government"? It would mean rapid iteration and scaling to meet shifting needs and demands — small prototypes and pilots, staged rollouts and allowance for small failures in an attempt to avert larger failures down the road. When Michael Bloomberg was elected mayor of New York City, education reform was at the top of his agenda. Through the use of charter schools, the city has been able to run essentially 99 different beta versions of education reform. As new models are tested, they can be tweaked, and ones that excel can be expanded.
Click Here to Uninstall
To achieve iterative improvements, however, government must be able to adapt and, in some cases, end programs that no longer provide value for the taxpayers' money.
Winamp, a freeware/shareware media player, was released in 1997, when MP3s began to replace CDs, and by 2002 had become common on PCs. But the launch of Apple's iTunes store, as well as legal proceedings against Napster, made file-sharing sites less attractive and shut many of them down altogether. Suddenly, many PC users had shunned Winamp in favor of iTunes.
What did they do? They found Winamp's uninstall link and removed it from their computers.
But for government programs, shutdown mechanisms often are inadequate or simply nonexistent. As one former federal CFO told us: "I can't stress enough the importance of being able to cancel programs."
In many jurisdictions, programs last until legislators vote to end them, which is always politically difficult. In contrast, in Texas, Florida and several other states with "sunset" laws, the legislature periodically must act to continue existing programs. This mechanism encourages elimination, reform or merger — in other words, an "uninstall." Fifty-four Texas state agencies have been abolished under that state's sunset law since its inception.
Mechanisms such as sunset laws can bring some of the vibrancy and adaptability of the world of technology to the hidebound business of government.
To meet citizens' expanding expectation of sophistication and functionality, government needs to find ways to create room for innovation and growth. In the free market, "creative destruction" is achieved through the invisible hand. In government, it can be achieved by following the model pioneered by software geeks.