How to Define Success in Civic Tech

A few days ago, I came across a LinkedIn post by Tait Chamberlain (written seven months ago, so I’m a bit late to the conversation). In it, he traces the “collapse” of civic tech, from the early optimism that open data could fix government to the realization that lasting reform requires working within institutions.

...First, the premise was deeply insular. A particular kind of Silicon-Valley optimism, mostly from well-paid technologists with time and skills to spare, assumed that government reform was a supply problem: if you just released the data, the public would demand change. Apps would bloom, corruption would wither. Not so much.

... Another problem: most “open” data isn’t released under pressure or through hard-won FOIA requests. It’s what governments already have on hand and feel comfortable sharing — data that’s safe.

... I think I’ve made my biggest difference in civic tech from within government at the department of Education, working on very unsexy projects like improving the FAFSA form contributor invite process, or removing barriers to loan rehabilitation. Reform can happen, it just has to move beyond a published spreadsheet.

This sparked a LinkedIn discussion, and in response, civic tech veteran Joshua Tauberer wrote a piece acknowledging the challenges in civic tech but arguing that it didn’t collapse; it evolved. He points to the ways civic tech helped change how government works, even when those contributions weren’t always visible or credited to the movement itself.

I don't want to minimize the problems in civic tech...[but] the movement was wildly successful anyway...

There are plenty of other durable successes from the open data / civic tech movement. Marina Nitze, Erie Meyer and others paved the way for the government tech innovation vision to take root within the federal government, and the vision did take root. Congress is still holding yearly "hackathons" (a branding gimmick that stuck) and other open data events thanks to Stephen Dwyer and Daniel Schuman's persistence, and Stephen seems to have managed to pass on the hackathon to the next generation of organizers (a difficult feat).

This stuff actually worked. We changed how government works, permanently, at multiple levels. There are countless more examples. 

As someone running Civic Tech DC, this debate made me think about how we define success for our own organization. While both perspectives raise important points about civic tech’s relationship with government, I also wonder whether we’re defining its success too narrowly.

How Civic Tech DC Has Evolved

In tracing Civic Tech DC’s history, I see a shift in how the organization approaches its work. In its earlier years, Civic Tech DC (then Code for DC) had strong ties to government, frequently collaborating with DC agencies on open data initiatives. Over time, especially after the pandemic hiatus, the model evolved toward its current form of distributed, project-based work with community partners.

While community-building has always been central to Civic Tech DC, it feels like our focus has shifted to bringing together people with different skills and interests to explore public problems. Government partnerships remain part of our work, but they’re now one of several ways we engage with civic challenges.

That shift raises an important question: If we’re not measuring success primarily through government partnerships or the adoption of our tools, what should we be measuring instead?

Is Civic Tech Solving the Wrong Problem?

Some might argue that civic tech’s real challenge is a misunderstanding of the problem. In the context of government modernization, the actual constraint is often government capacity, not simply data availability. From this view, civic tech focuses too much on external solutions like open data and not enough on workflows and administrative burden. Hackathons were often symbolic, and prototypes rarely survived the realities of implementation.

I would somewhat agree with this critique. In some ways, civic tech became a performative layer of innovation sitting on top of a structurally unchanged system. Real change is often found in the unglamorous work of fixing forms and maintaining infrastructure.

But I also think this critique assumes that civic tech’s primary purpose is to reform government. Civic tech is much broader than that. It can involve making public information more accessible, helping nonprofits serve their communities, or creating tools that address problems residents face in their everyday lives.

And even outside government, we run into similar challenges. It’s far more appealing to build an app than to spend time on the “unsexy” things. I know a lot of Civic Tech DC participants value having a tangible product at the end of a project. There’s nothing wrong with that. Building something is exciting, and having a concrete outcome can be an important part of learning. But a working prototype and a lasting solution are two different things.

This is where the conversation about civic tech’s success becomes more complicated. If the goal is to solve a public problem, then usefulness and sustainability matter. But if the goal is also to help people participate in their communities, perhaps we’re overlooking another kind of impact.

The Value Beyond the Tools

I believe Civic Tech DC creates value, just not always in the ways civic tech has traditionally been measured.

It’s a place to build civic and technical skills, but also a space for people to get involved in issues they care about. Someone might join a project night because they want to learn to code or contribute to an open-source project. But along the way, they might learn about the challenges a local nonprofit faces in delivering services to its community.

That experience could shape how they think about public problems and where they choose to contribute next. Some might go on to work in government, while others might bring those skills to nonprofits or become more engaged in their own communities.

And there’s also something valuable about having a space where people from different backgrounds can come together around a shared public problem. A developer might understand how to build a tool, while someone working in policy or community organizing might understand the problem it’s meant to address. Neither perspective is sufficient on its own, and bringing them together creates opportunities to learn from one another. In that sense, I see Civic Tech DC less of a production pipeline for tools and more of a form of civic community infrastructure.

The challenge is that these outcomes are much harder to measure than the number of projects launched. We can count how many people attend project nights or how many tools are built, but it’s harder to track how those experiences shape someone’s understanding of civic issues, the relationships they form, or the work they pursue years later.

Civic Tech as Community Infrastructure

Civic tech organizations have an interesting position. They can bring together people who might not otherwise work with one another, from technologists to researchers. They can also provide a place to experiment with ideas that may not fit neatly within an existing organization.

Of course, I don’t think that means every project should be considered successful simply because people learned something. If we’re building technology intended to serve communities, we should care whether it’s actually useful, whether it responds to a real need, and whether someone can sustain it.

But I also don’t think we should dismiss the value created along the way. A project that doesn’t survive might still introduce someone to civic tech, help a nonprofit better understand its technical needs, or bring together people who go on to collaborate elsewhere.

Perhaps that’s what makes defining success in civic tech so difficult. We’re trying to measure several different things at once: the tools we build, the problems we help address, the people we bring together, and the opportunities that emerge from those connections.

I feel that civic tech is often judged by its most tangible outcomes, especially whether a tool creates measurable change. Those outcomes matter, but they don’t capture the full picture. Rather, we need a broader definition of success that accounts for both the work and the community capacity.