This article was written by Will Sullivan for MIT News . The guide was also featured in posts by Tiago Peixoto on DemocracySpot, Koketso Moeti in iAfrikan and the World Economic Forum, Rustam Khan in The Tech, and ICTworks, and by Lwazi Maseko for the Civic Tech Innovation Network.
People frequently try to participate in political processes, from organizing to hold government to account for providing quality health care and education to participating in elections. But sometimes these systems are set up in a way that makes it difficult for people and government to engage effectively with each other. How can technology help?
In a new how-to guide, Luke Jordan, an MIT Governance Lab (MIT GOV/LAB) practitioner-in-residence, advises on how — and more importantly, when — to put together a team to build such a piece of “civic technology.”
Jordan is the founder and executive director of Grassroot, a civic technology platform for community organizing in South Africa. “With Grassroot, I learned a lot about building technology on a very limited budget in difficult contexts for complex problems,” says Jordan. “The guide codifies some of what I learned.”
While the guide is aimed at people interested in designing technology that has a social impact, some parts might also be useful more broadly to anyone designing technology in a small team.
The “don’t build it” principle
The guide’s first lesson is its title: “Don’t Build It.” Because an app can be designed cheaply and easily, many get built when the designer hasn’t found a good solution to the problem they’re trying to solve or doesn’t even understand the problem in the first place.
Koketso Moeti, founding executive director of amandla.mobi, says she is regularly approached by people with an idea for a piece of civic technology. “Often after a discussion, it is either realized that there is something that already exists that can do what is desired, or that the problem was misdiagnosed and is sometimes not even a technical problem,” she says. The “don’t build it” principle serves as a reminder that you have to work hard to convince yourself that your project is worth starting.
The guide offers several litmus tests for whether or not an idea is a good one, one of which is that the technology should help people do something that they’re already trying to do, but are finding it difficult. “Unless you’re the Wright brothers,” says Jordan, “you have to know if people are actually going to want to use this.”
This means developing a deep understanding of the context you’re trying to solve a problem in. Jordan’s original conception of Grassroot was an alert for when services weren’t working. But after walking around and talking to people in communities that might use the product, his team found that people were already alerting each other. “But when we asked, ‘how do people come together when you need to do something about it,’” says Jordan, “we were told over and over, ‘that’s actually really difficult.’” And so Grassroot became a platform activists could use to organize gatherings.
Building a team: hire young engineers
One section of the guide advises on how to put together a team to build a project, such as what qualities one should want in a chief technology officer (CTO) who will help run things; where to look for engineers; and how a tech team should work with one’s field staff.
The guide suggests hiring entry-level engineers as a way to get some talented people on board while operating on a limited budget. “When I’ve hired, I’ve tended to find most of the value among very unconventional and raw junior hires,” says Jordan. “I think if you put in the work in the hiring process, you get fantastic people at junior levels.”
“Civic tech is one exciting area where promising young engineers, like MIT students, can apply computer science skills for the public good,” says Professor Lily L. Tsai, MIT GOV/LAB’s director and founder. “The guide provides advice on how you can find, hire, and mentor new talent.”
Jordan says the challenge is that while people in computer science find these “tech for good” projects appealing, they often don’t pay nearly as well as other opportunities. Like in other startup contexts, though, young engineers have the opportunity to learn a lot in an engaging environment. “I tell people, ‘come and do this for a year-and-a-half, two years,’” he says. “‘You’ll get paid perhaps significantly below industry rate, but you’ll get to do a really interesting thing, and you’ll work in a small team directly with the CTO. You’ll get a lot more experience a lot more quickly.’”
How to work: learn early, quickly, and often
Jordan says that both a firm and its engineers must have “a real thirst to learn.” This includes being able to identify when things aren’t working and using that knowledge to make something better. The guide emphasizes the importance of ignoring “vanity metrics,” like the total number of users. They might look flashy and impress donors, but they don’t actually describe whether or not people are using the app, or if it’s helping people engage with their governments. Total user numbers “will always go up except in a complete catastrophe,” Jordan writes in the guide.
The biggest challenge is convincing partners and donors to also be willing to accept mistakes and ignore vanity metrics. Tsai thinks that getting governments to buy into civic tech projects can help create an innovation culture that values failure and rapid learning, and thus leads to more productive work. “Many times, civic tech projects start and end with citizens as users, and leave out the government side,” she says. “Designing with government as an end user is critical to the success of any civic tech project.”
Illustration by Susy Tort.