Civic tech: Things I've Learned From A Thousand Failures

My lightning talk about civic tech called: «Things I've learned from a thousand failures» was watched by hundreds of people at Code for All Summit on September 20th 2022. Now the video is available to all.

Summary

In this lightning talk, I share three key challenges that cause civic tech projects to fail:

  1. Solutionism: The naive belief that technology alone can solve complex social problems
  2. Bikeshedding: Wasting time arguing about trivial details, which drives volunteers away
  3. Lack of Documentation: Failing to document project goals and technical details

I also discuss how user research and ethnographic interviews can help teams build solutions that truly meet user needs, avoid unnecessary debates, and create more sustainable projects.

Full Transcript

Introduction

Hello, I am Martín and I have failed.

What do I mean by that? Stick around and you'll discover why many of my civic tech projects failed and some easy tips and tricks I learned that can help developers, designers, managers and funders of civic tech projects increase their chance of success.

Because either in a hackathon, in a community project or in a startup, a bit of good mentoring for junior teams can really help them to accomplish their goals.

But before... allow me to properly introduce myself.

My name is Martín Szyszlican, and I like creating websites that solve important problems. I was born in Buenos Aires in the 1980s, I learned to code before finishing high school. Then I studied graphical design, user experience and accesibility testing.

I have been a civic tech developer for more than a decade, I've participated in great projects across Latin America, Europe and Asia. I currently live in México where I'm part of the Codeando México community.

I'm a fan of really simple hacks that unlock new powers and also of big multi-year projects that continue to provide sustainable solutions to entire communities. During this talk I will be reflecting on some challenges from projects like those.

If you hear something that resonates with you and want to talk about it, there will be a way to do that at the end of the talk.

Ok, that's it for the introduction, we now go straight to: Things I've learned from a thousand failures (and how they can help you) in less than 7 minutes. Challenge 1: Solutionism

So the first challenge I want to share with you. And this is something I'm personally going through right now.

What to build?

What is it that brings civic tech developers together? It's a common goal... a problem we all want to solve for someone, right? So we create pool of resources to solve it.

Once you have gathered... what do you do? How do you agree with your colleagues on what the app should be?

One of the ways I have failed to achieve consensus is through the ideology of solutionism. Solutionism is the idea that tech can solve everything.

It's an iPhone app where people from the slum can find temporary housing when they don't even have a data plan. It's a deforestation map that no one will ever see.

I'm sure you know many examples, we can laugh about them later.

If this hasn't happened to you, it's not because the engineering education did not point you in this direction, it certainly did, and that's why we need more people with "soft skills" and real world experience in our teams to help us adjust our expectations and understand that there are issues that are governed by greater trends that cannot be fixed by a website.

So yes, if you suspect solutionism is happening in your team, what do you do? You have to quickly raise the issue and question the direction you are going.

That is the right thing to do. Except... some people (like this guy) really like contradicting people and that can lead to... Challenge 2: Bikeshedding

Bikeshedding. This is the second challenge I want to share with you today.

Bikeshedding is when you argue about things for so long, that people end up no longer wanting to do them.

So, take everyone's opinion? Yes! But, give place to irrelevant questions? No! This is a way to lose volunteers.

I know I have failed this way many times, I love endless vanity contests, don't you? Bikeshedding is a serious topic with its own website at Bikeshed.com

So, you ask, how can I question our direction while avoiding bikeshedding?

The Solution: User Research

User research. Before starting to code, before doing anything, before you even decide what to do, you need to talk to the people you intend to help. When we fail to study our target audience we can't be sure our implementation will be beneficial for them.

If you have an engineering background, you can think of this as an expanded requirements gathering stage. I like to recommend this technique called ethnographic interview to create profound knowledge of the people you're trying to help and their general needs.

Anyone who reads these interviews will have an elevated sense of empathy with the users when designing the solution. Make sure all the team knows about this, it will be much easier to agree on things afterwards, and it will also be easier to avoid making things people don't want, don't need or don't understand. Challenge 3: Lack of Documentation

The final challenge I want to share with you is something that led many of my best ideas to failure, and it's lack of documentation.

There are important things to document and establish in a civic tech project, like the ones I already mentioned: who is it for, what is the expected outcome, you'll discover that this is very easy to forget a few months in. Especially if new volunteers or workers come into the project regularly.

We should not let our team forget what is the positive impact we want to make in the world and how we plan to achieve it. So there should be a document explaining what is our solution and everyone in the team should read it once in a while.

Also for developers, it will be very hard to come back to the project in a couple of years and remember how to use all these little scripts that we are writing, how we were able to make things work in our terminals...

This single piece of advice has had to be reminded to me so many times by so many different people and it was so valuable every time that, in the end, this is what made me want to become a mentor to support the success of technology teams and with your help I might be able to do that.

Invitation to Collaborate

So, if you had any of these challenges and want to talk about them, or if you had a different set of challenges I haven't mentioned, I want to invite you to a chat group for collaborative consulting, this is a type of mentorship.

So, if you liked this short talk, please do get in touch on my website and I will be adding you to the chat group. I will be available to give free advice in my spare time, and hopefully you will be there too, to help others in the group.

And don't worry, we have a strong code of conduct to create a safe space for all types of inquiries without bikeshedding, without misgendering or other infantile online interactions.

So that's it, thanks for watching and we'll chat soon, Bye!