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 describes the “collapse” of civic tech in its evolution from the optimism of the early 2010s, when many believed open data could fix government, to the realization that data alone doesn’t create reform, and finally to a more mature understanding that lasting impact often comes from working inside government.

...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 did not collapse but evolved. Civic tech worked more than people give it credit for in leading to real institutional reforms that were gradually absorbed into government systems.

....I don't want to minimize the problems in civic tech

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

As someone personally invested in civic tech and running Civic Tech DC, what does this mean for the organization?

In tracing the organization’s history, I see a shift in its center of gravity. Earlier phases were more directly embedded in government-adjacent work, with frequent collaboration with DC agencies and open data initiatives. Over time - especially after the pandemic hiatus and organizational transition - the model evolved toward its current form: distributed, project-based work with nonprofit and community partners. It feels like Civic Tech DC’s “impact model” shifted from institutional proximity to ecosystem-building.

Some might argue that civic tech’s real challenge is a misunderstanding of the problem. That the actual constraint is government capacity, not data availability. From this view, civic tech focuses too much on external structures like open data, transparency, and tools, and not enough on workflows, staffing, and administrative burden. Things like hackathons were often symbolic, and prototypes rarely survived the realities of procurement.

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, improving workflows, and maintaining infrastructure. It’s far more appealing to build an app than to sit with a broken administrative process, and I know a lot of Civic Tech DC participants value having a tangible product at the end of a project.

Yet Civic Tech DC does create value just not in the way civic tech has traditionally been measured. It’s a place to build civic and technical skills, and I believe the real value lies in inspiring people to eventually work within the institutions of systemic change. It also functions as an awareness space in helping people understand how systems are supposed to work versus how they actually operate. This echoes what the U.S. Digital Corps promotes: civic tech as a pathway into public service, where the real outcome is a generation of people who’ve learned to work across the divide between government and technology. As such, I think Civic Tech DC is an entry point into public service identity and civic community infrastructure, a space where relationships often matter more than tools.

In this framing, Civic Tech DC is less a production pipeline for tools. I see it as a translation layer as part of a larger stack:

• Outside (startups, civic groups, open source): Prototype and explore problems, generate ideas, and surface pressure points in systems.
• Middle (civic tech, nonprofits, Civic Tech DC): Build community, translate across sectors, develop skills, and create pathways between civic interest and institutional work.
• Inside (government and institutions): Own infrastructure, set rules, and implement systems at scale.

I feel that civic tech is often judged from the wrong layer. It’s evaluated as though it should produce government change directly, when in reality its role is earlier and more indirect in inspiring those who enter the system, and which pathways into institutions feel possible.