How not to create a civic tech organization and what to do instead

As the COVID-19 pandemic sent shockwaves around the world, the civic tech community responded by deploying various technologies to support efforts to confront the crisis.

For example, in Italy Associazione Nazionale Pubbliche Assistenze (ANPAS) used Ushahidi, a free open-source platform for crowdsourcing crisis information, to ensure a steady supply of food, medicine and other subsistence goods to vulnerable communities that were impacted by the restrictions brought on by the pandemic. In a period of thirteen months, Ushahidi was deployed 1,684 times, across 130 countries.

BudgIT, a civic organization that applies technology to intersect citizen engagement with institutional improvement in Nigeria, launched CovidFund Tracka. The portal tracks Covid-19 related donations given to the federal and state governments of the country to enable the monitoring of resources and advocate for accountability.

How can we learn from these examples to create civic tech projects in the future?

In a new how-to guide, Luke Jordan an MIT Governance Lab (MIT GOV/LAB) practitioner-in-residence, offers guidance on building civic technology. In an accessible way, the guide codifies some of the lessons Jordan learned from founding Grassroot, a civic technology platform for community organizing in South Africa.

The guide encourages civic tech practitioners to not start with technology as the departure point for their projects. Instead, they are invited to make political and social considerations to really understand what problem the technology is meant to solve, before building anything.

Here are three key lessons from the guide:

The guide’s first lesson, “don’t build it,” may seem counterintuitive, but is important.

It echoes a key finding of a study that looked at how organizations in South Africa and Kenya select technology tools in their transparency and accountability initiatives, “think twice before you build”. The study found that not only are organizations often dissatisfied when they build technology, but also that “most organizations did very limited research to understand their intended users, the technology options available and the problem the tool was expected to solve”.

In my experience, organizations are simply not asking themselves the right questions before building technology. It is too often done to address complex, systemic problems or misdiagnosed problems or because funding is available for technology projects, so this advice resonated with me

Instead of immediately turning to technology, organizations should attempt to understand what the problem is. This includes making considerations like whether people are already trying to do what the technology is supposed to and it is not working? Whether there is already technology that exists that can do what is desired or, as is often the case, that the problem cannot be solved by technology.

An important part of any civic tech project is team structure. According to Jordan, “if you have to build it, hire a chief technology officer (CTO), essentially a full-time senior tech lead because outsourcing is great as a tactic, but a terrible strategy”.

Most organizations do not hire a CTO, as the assumption is that it saves money to not bring on a full-time employee to the organization. Unfortunately, organizations building technology often do not get it right the first time and must take the lessons from failures and be ready to adapt. Building technology is not a one-off event.

Without a technology lead most organizations do not do a good job of choosing a contractor. This is because most other team members are simply not equipped to “judge the technical merits of proposals, or to break down a project into its abstract technical components”, Jordan explains.

Vanity metrics, metrics that make individuals feel good or present projects in a good light, reveal very little about whether or not a project is having the intended impact. The most common example of this is organizations citing the number of downloads an app has. While the large number of downloads may look impressive, this does not mean that those who have downloaded are actually using the app and that it is making the intended impact.

In an interview, Jordan notes that too often “we think technology will help a community or help people when it doesn’t work”.

For example, consider the case of contract tracing apps, which have been deployed by 50 countries. Despite the significant investment of resources in their development, they have faced questionable success, poor uptake, privacy concerns and criticisms for not addressing the digital divide. In Australia for example, while the government hailed the $2 million COVIDSafe tracing app a success owing to the number of people who downloaded it, it later emerged that the app worked “as few as one in four times for some devices”.

Other examples include an app in South Africa touted as "first of a kind" that was supposed to address infrastructure problems but then failed to address the faults that users flagged; and a surveillance system in the US that was promised to improve response time to shootings but instead was found to escalate encounters between police and civilians.

In the former instance, the fact that it was the “first of a kind” was hailed as a measure of success, even though the app did not achieve what it was meant to and is now seemingly defunct. In the latter example however, the alerts received by police are often hailed as a measure of success, despite 85% of the alerts being dead ends in Chicago for example.