Why Civic Tech isn’t Gold for Governments

In the aptly named “Shoveling for Civic Tech Gold”, Mark Headd explores the challenges that render segments of the civic tech community virtually powerless to have real impact. In particular, he speaks about innovative and noble-minded projects ultimately failing because they find no support from the very governments they aim to help. His observations align well with what I have seen during my time in government, participating on the fringes of the movement for many years now.

Why don’t governments support interesting civic tech projects? There are many smart people within government who truly want to make a difference and would be happy to support any viable option that came forward. However, they too are frequently frustrated by a excessive number of reasons to say no, and nearly all of them highlight the underlying issue — it’s risky. Both the policy-making and thing-doing wings of government aren’t well suited to take risks. Politicians get repeatedly and publicly torn apart when failure happens. All levels of government employees are subject to processes that inherently reduce the risk of failure and corruption, while simultaneously stifling innovation. There are no shortage of attempts to build new models that can tolerate risk, but few are sanctioned to shortcut or entirely skip the bureaucracy. If anything, they become experts in how to follow the rules so they know exactly where the loopholes are.

Perhaps, then, by resurfacing some of the specific risks and concerns about civic tech projects, we can eventually find a better path towards partnerships.

• When something goes wrong, who is going to fix it? Code breaks, servers and network connections fail, cloud computing bills don’t get paid, and architectures collapse under stress. If a government is going to publicly support a specific solution, everyone involved wants to make sure it works, and will continue to work for as long as needed.
• Who will support the customers? New solutions, particularly small innovative ones, don’t have teams behind them which can effectively handle and track the inevitable questions, no matter how intuitive the design of the interface.
• How long will the product/solution be around? The greatest tech solutions crafted by the worlds finest development teams aren’t sustainable if they built it over a few weekends in their proverbial garages in between their day jobs, families, and social lives. This is why hackathons are largely considered community-building practices, not solutions.
• If the solution captures data, who does the data belong to, who has access to it, and how will it be used? Plenty of freemium services trade access to data in exchange for providing free capabilities. How will a new solution use the data it collects, and what might the unintended consequences be?
• If the data is sensitive and gets stolen, who is liable? If the government has encouraged people to use a third-party tool, that same public will still hold the government accountable. That risk can’t be transferred to a group of civic hackers.

All of the above considerations get managed by formal agreement — often a procurement, but sometimes a memorandum of understanding can be substituted. That takes lawyers civic tech teams don’t generally have, and time from the army of lawyers that the government already has who are overwhelmed by other firefights. The agreements define rights, responsibilities, and liabilities on both sides — even if no money changes hands.

Once the possibility of a formal agreement comes into the picture, another major factor comes into play: fairness.

We can argue about its effectiveness some other time, but government procurement is generally designed to ensure fairness and ethical behavior, and those notions are deeply rooted in policies and practices. Even if the solution will be of no cost, those tenets of fairness and ethics will come into play. How can anyone be sure that the solution to be used is the best one, or even the only one? Is it possible that someone else will file a lawsuit because they didn’t have a chance to offer their own solution? Suddenly there are more risks to mitigate.

And, flipping over the coin of fairness, what guarantee is there that a particular solution will be fair and accessible to every customer? An agreement enabling an online application process for SNAP benefits won’t serve the full audience of eligible participants. Governments have to consider how each solution plays into the bigger picture, and fill gaps as they are recognized.

Reflecting back on this, a lot of the rationale here also explains why leveraging open source software can be a huge challenge for governments — one which is unlikely to be resolved without reframing risks or procurement. Until the civic tech movement can effectively grapple with these, it’s (unfortunately) likely to continue in a position on the sidelines.