Is civic tech creating problems while intending to provide solutions?
I don’t know how I feel about “civic technology.” I don’t know if that’s because I’m old (relatively speaking) or because I’m jaded (having spent 30-plus years in government) or for some other reason. A big part of me has embraced the movement, but a bigger part wants to make sure we think it through to avoid creating more problems than we intended to solve.
I recently attended the Code for America 2015 Summit in Oakland, where by my eyeball estimate of the main-stage area, somewhere between 850 and 1,000 mostly twenty- and thirtysomethings were raptly listening to sound bites of no more than 15 minutes. It was just long enough to generate enthusiasm for what seems like a well-intentioned mission: Use technology to solve problems in government. But perhaps not long enough to understand the nuances of longer-term impacts.
I don’t want to be a naysayer; it’s not really my nature. Certainly we want people to be interested in government, and we also want to encourage and harness disruptive change. And I’m the first to admit that a lot is broken in government, and some of what Code for America is all about could help provide solutions. But much of what I see presently is like oil applied to the hinge of a sticky, squeaky door. I worry a little that the sound bite nature of the apps is a bit (or maybe a lot) like treating symptoms and not the actual disease. Worse, civic tech possibly is creating problems while intending to provide solutions.
Maybe the more vexing government issues are not of interest to civic technologists. At lunch, I sat with five other attendees, folks who are extremely happy to talk to complete strangers about what apps they’re working on. They’re focused on providing “data for decision-makers,” but I don’t get a sense that they know much about the processes (right, wrong or indifferent) that government decision-makers use to actually make decisions, nor do they seem to appreciate the environments in which decision-makers work and what arcane rules govern them.
Civic technologists do exhibit a healthy level of pride in their contributions to “solutions” to social problems. But the broader social issues are problems of scale — huge, politically sticky problems that would be solved by now if the solutions were easy. Scaling the civic technology solutions still seems to be largely unaddressed, and I’m worried that we’re using civic technology on the wrong problems and therefore creating more harm to the “improvement movement” than intended.
I spent some time recently with chief financial officers working for cities and counties. They enlightened me that the electronic payment I send via my bank actually creates more work for their staff. The reason: My bank issues a check that is devoid of any identifying account information, so a staffer must research the check and why I might be sending it, a labor-intensive and time-consuming task. A time-saver for the citizen actually creates more work for the government employee. What is really needed is not a way for me to send government an opportunity to enter data by hand, but for the data to actually input into the systems without human intervention. As a civic technologist, I wouldn’t have gotten this view from talking just to the folks who are trying to pay their property taxes.
The civic technology movement is innovating in an environment free of constraints, and that’s an attractive possibility for government. How can this laissez-faire realm and the energy it has produced be harnessed more effectively and focused on some of the more infrastructural problems of government?
Historically, government technologists have not been encouraged to be broadly innovative; quite the contrary, governments are encouraged to establish sustainable enterprise architectures and then work within those infrastructures — incremental changes are realized with this approach. But there is no encouragement, financial or otherwise, to risk public funding on technologies that are considered “bleeding edge,” nor is there encouragement to color outside the lines, in spite of the occasional rhetoric to that effect.
Given the constraints that governments face, there is a healthy amount of skepticism about the supportability of civic technology applications and integration of these services into a public-sector enterprise. The rigid parameters are imposed by legislation, regulation and policy, and to remove them takes significant effort. Perhaps we should be focused on building the public and political will to eliminate outdated requirements that hinder service improvements.
Innovation in government isn’t free. Program performance that is specified in outputs (not outcomes) and is codified in regulation leaves little room for innovating and integrating new ways of doing business. Innovation efforts often are funded by nonprofit organizations because government can’t or won’t fund them.
And what about the public and political will inside of government to build and sustain a culture of innovation? I can only imagine what it feels like to have people outside your organization innovating, without your involvement, on behalf of the program you administer. There are other strategic questions that need to be considered: How might we be unwittingly endangering the development of internal political will? What kind of relationship are we creating between the civic innovators, government program administrators and IT (which is often already strained and/or precarious)? Are there unintended effects? Should government spending include an innovation office or fund that’s not revocable during times of economic contraction (when, arguably, we need it most)?
I am struck by an insert in my Code for America registration packet on “user needs.” It’s a clever fold-out pocket guide that walks the reader through the concept of what a user need is and how to articulate it, research it and test it. If you read the piece from top to bottom, the last thing you encounter is the idea of “talking to users.” There isn’t a clear articulation of who a user is, but I get the distinct impression from the pamphlet that the “user” is a citizen who is receiving or is eligible to receive government services.
I surmise there isn’t a lot of collaboration yet between civic and government technologists, and that is exactly where the conversation needs to head. I know each time I ask audiences, “Who is aware of Code for America and the civic technology movement?” I get only a few hands raised in recognition. Some of the audience usually associates Code for America with open data efforts and thinks that it’s not something they need to pay attention to — an outlook they probably should revisit.
The civic technology movement can provide a huge value to government, but government needs to see itself as a user — I’m certain Code for America would encourage this — and understand the power of the movement to innovate in ways that are difficult, if not impossible, inside government. Only then will we start solving some of the infrastructure issues that prevent the door of opportunity from swinging freely. We know government has to change, technology has to modernize and workforces desperately need infusions of younger blood. We also need to be mindful of the problems of scale and impacts of our actions in the longer view.
Oiling the hinge of a sticky, squeaky door will do little help when the door is sticking because the foundation has shifted over time so that the door frame itself is off-kilter. All that’s left is a slippery puddle on the floor that demands attention away from the structural issues left unaddressed.
This commentary appears in the Winter 2015 issue of TechWire magazine.