Modern software developers move quickly. They push out the door what they call "minimum viable products," revising as needed, based on their users' experiences. They often use "open source" software -- code that's more stable because it's free and therefore tested more widely by more users.
The company executives who employ these software makers are themselves knowledgeable about technology, and they track the progress of their own products and others' as well. They deploy elaborate quality-assurance testing and strong project management to make sure new software never cripples their businesses. When's the last time you saw LinkedIn stop working when it rolled out a new product?
The embarrassing rollout of HealthCare.gov shows how differently the government operates. It should also be taken as an unparalleled opportunity for public actors at all levels -- local, state and federal -- to fix the government's relationship with technology.
This isn't just about getting access to better software programs -- after all, the National Security Agency seems to have access to whatever it wants. The problem underlying the HealthCare.gov debacle is more cultural than technical.
Civil servants trained in policy know little about digital technology; as a result, they can't ask hard questions or pitch in to help. Many are risk-averse, too, and complacent when it comes to large technology projects. Government technologists, for their part, may have no experience with modern project management and design methods. They usually aren't at the policy-making table; instead, they're brought in after decisions have been made and left to interpret the shifting demands of the tech-blind lawyers and economists.
This is why, when faced with a big technology project, fear of failure and inadequate internal talent drive government agencies to call in giant contractors. These vendors may not be the best at managing software development, but they are the best at handling government contracts. They'll operate using antiquated models of project management that involve detailed, fully baked project designs rather than minimum viable products. And they'll use mainstream technologies because that's what they know decision makers will trust. Government policy managers, by and large, leave vendors such as CGI Federal, the contractor behind HealthCare.gov, alone to do the work, not knowing what questions to ask.
This is a shame, because if government could use technology responsively, it would increase public trust.
Now that the worst has happened to the most important policy initiative of the Barack Obama administration, skilled technologists from outside government need to brought in for short stints; many coders are interested in serving, and government agencies need to relax civil-service restrictions to let this happen easily. In turn, government technologists should be embedded briefly with private companies so that they can bring current knowledge back to their agency desks. Procurement rules governing purchased assistance need to be rewritten, so that civil servants are able to choose the best rather than the cheapest.
More fundamentally, it is no longer acceptable for policymakers and project managers to know so little about technology. Or for technologists to be treated as mere implementers. Government technologists have to be cross-trained in policy so that "data-driven policy making" can be more than a turn of phrase.
Here's the payoff: Digital technology, thoughtfully integrated into operations and responsibly overseen, can help governments be more responsive to citizens' needs. It should be a key element in every 21st-century public project.
The Department of Health and Human Services has summoned a "tech surge" in Washington to fix the bugs in HealthCare.gov. The next step is to change the government's whole approach to technology.
Susan Crawford, a professor at the Cardozo School of Law and a fellow at the Roosevelt Institute, wrote this article for Bloomberg News.