Revisiting the Origins of Civic Tech
In an era of DOGE, what can we learn from a different approach to tech and government
Right now, DOGE is running key parts of government, and doing so in a way that destroys a lot of state capacity, breaks laws, and hurts the public. It did not have to be this way. DOGE replaced the US Digital Service, which existed for a decade. I am fascinated by the USDS as an example of civic tech — public-spirited technologists who tried to make government work better. Civic tech still offers an alternate and to my mind superior vision for how to integrate tech into government.
So I interviewed Emily Tavoulareas and Kathy Pham. They were founding members of the USDS, and are now thinking through its origins and evolution. They have compiled an oral history of the origins of the USDS that, in their words, “pieces together a larger story and vision of technology in government, and the realities of creating something new in an environment that is often paralyzed by inertia.” I wanted to understand what they and the 50 other people they had interviewed had learned as they looked back. Be warned: this is a bit of a wonky interview, but also reveals some pretty fundamental insights about what is and is not possible in American government, and how technologists who can really improve the public sector.
What does civic tech mean? What did the people starting these organizations think it meant?
Emily: To me civic tech is shorthand for the work of designing and delivering technology that improves access to and use of government programs and services. It is ultimately about implementation and the touchpoint(s) with the public. Sometimes the target audience is the public, sometimes it is employees who manage programs.
From my vantage point, civic tech began outside of government in the mid-90s at the local level, aiming to improve the touchpoints with their public institutions through technology and design. Often they seemed to be identifying needs that the government had failed to address, and created interventions of various kinds. Projects like OpenStreetMap, FixMyStreet, Frontline SMS, and Ushahidi come to mind. There are a few great timelines that provide a lot of color to the chronology of civic tech, including the Civic Tech and Design Timeline, and the Civic Tech Timeline for a more global perspective. Any way you slice it, the work itself was often hyper-local, but the collective energy and community were global — and that community grew through convenings like the Personal Democracy Forum (est. 2004) and Gov 2.0 (est. 2009).
Over time, somewhere around the 2010s, we started seeing civic tech practitioners becoming interested in the underlying operations and infrastructure that those public-facing interactions are built on. This took civic tech into government itself, where people saw firsthand how deep-rooted and systemic the problems were. This was different from the more visible, user-facing civic tech applications that was the original focus of civic tech, but there’s only so much you can do to improve the public touchpoint if the system it’s built on is dysfunctional or unstable. The real change required invisible work within the public institutions themselves.
I have to say, there’s something about civic tech that at this point feels to me like more of an ethos than a field — like a mode of operating. The work is centered on the needs of people, and is driven by a focus on a desired outcome, not a preordained output or “solution.” While the substance of work may differ, I see a shared belief in the potential of technology to improve public service, along with shared methods, and principles of decentralization and transparency.
Kathy: As with everything I do with tech, I think about historical context and the non tech versions, and technology often is just one part of our lives and society. So the “What does civic tech mean?” relates to “What is civic duty?” A common definition of this is an individual’s responsibility to actively participate in and contribute to the well-being of their community, government, and society, especially in ways that support the well-being of our society. So by extension, civic tech is both the use and understanding of technology to promote people's participation and engagement with government. We now see civic tech encompassing many aspects of technology and government: technology for delivery of better governments, like our veterans’ access to healthcare; the understanding of technology for policy and lawmaking, like new laws in Congress or new enforcement with the Federal Trade Commission; and the use of technology to engage with our governments, like with voting.
For those who started organizations like Code for America, 18F, the UK Digital Service, the United States Digital Service (now US DOGE Service), and state and local digital services, civic tech has meant understanding and using the best technology for each specific government scenario to provide the best outcomes for the public. This means a combination of human centered design, efficiency, and better services. One of the early guiding principles of the US Digital Service was the most good for the most people who need it the most. The US Digital Service was inspired by precedents from Code for America, partnerships with 18F and other global digital service organizations.
What did the movement learn as it evolved?
Emily: The most fundamental to my mind: that technology is neither the problem nor the solution, and that if we really care about fixing a problem or improving something, we must take the time to both understand and address the conditions creating the problems. If we don’t, nothing really changes.
A few others:
Network-building and information-sharing are powerful and critical, especially in a system of government that is highly decentralized.
The incentives of massive public systems are pointed toward visible outputs/solutions — not outcomes.
Keeping the focus on people and the reality of their lives is critical, but is a persistent uphill battle pretty much everywhere.
Understanding the problem you are trying to address is central to improving anything, and the people with the best understanding are those closest to it — the ones engaging with it every single day.
Procurement is at the root of many problems, and helping the government procure technology effectively must be part of any lasting change.
Kathy: Since Emily went broad, I’m going to focus in on a couple of the lessons from our recent oral history of the U.S. Digital Service.
Digital technology and public policy are entangled. The healthcare.gov rescue initiative showed how tightly coupled healthcare policy and technology were. Technology can be the vessel that makes the execution of policy possible. It can also be what limits the execution of our critical government policies like our veterans getting access to their healthcare and small businesses getting loans.
Invest in talent! The right small group of individuals in a large agency can be the bridge between broken tech systems and deep value sets of each agency and it’s purpose to service. These individuals need to span design, engineering, product acumen, procurement, data science, dev ops, and more.
Overall, the movement learned that it is a movement. The US Digital Service was inspired by Code for America and the UK Digital Service. Some state and local governments were inspired by the US Digital Service, and used Digital Services Playbook for their own launches. We need as many different versions as possible, but some are able to weather changes differently. For example, right now, because many of our most talented technologists have left or been forced to leave the federal government, state and local governments have been a landing place.
What is it that the public does not know how civic tech worked that it should know?
Emily: I’m not sure people understand that a shared starting point across civic tech was (and continues to be) that the status quo is not working, but it must work. We need our governments to understand the needs of people and communities, and be able to effectively respond to those needs.
While I think many people in civic tech understood the entanglements between tech and government, we didn’t really have the language for it at that time. As Jen Pahlka said in our interview with her for the USDS oral history: “People thought we were saying technology will fix it. We were not.” Civic tech has long been about people, not technology — outcomes, not outputs — effectiveness, not efficiency.
Kathy: Anyone can get involved and there are many ways to get involved! This can range from helping local town, city, state governments with setting up websites to completely transforming how taxes are filed online with the federal government. There are a lot of ways to get involved, and when one way seems no longer possible, look for other ways. Sometimes it makes sense to go into tech policy making in government. Other times those skills are best used at a state and local level, or a non-profit or think tank. It’s also possible to work for a non-government entity that interacts with the government (either a policy institution or a government contractor) and drive a lot of positive change too.
Civic tech is a way to find how technology fits into civic duty, an individual’s responsibility to actively participate in and contribute to the well-being of their community, government, and society, especially in ways that support the well-being of our society, and there are many avenues to get involved.
What were the main challenges the movement faced?
Emily: There are many, but I want to focus on the three I think about the most: institutional inertia, the deification of quantitative data, and the policy establishment.
1/ INSTITUTIONAL INERTIA.
“The government” is a massive system, and all of the incentives and energy of that system prioritize visible outputs and “solutions.” This kind of environment (intentionally or unintentionally) deprioritizes the needs of users in the interest of processes, procedures, and the general preservation of the institution.
Bringing people in from outside of government is really valuable precisely because they don’t ascribe to the same norms and incentives of public institutions. Whenthose people stay too long, they tend to adapt to the system they are in — not the other way around, and they can no longer push the envelope.
And yes, this is extremely uncomfortable to say right now, as we see the destruction DOGE has left in its path. But it’s true. I’m not quite sure what to do with that.
2/ THE DEIFICATION OF QUANTITATIVE DATA
The deification of data has led us to overlook reality. From what I’ve seen, only what is measurable is deemed valuable in policy circles — there is no room for observable reality. Quantifiable information is only a fraction of the picture, and provides little to no insight into how or why things are the way they are.
I have taught at a few different universities, and have been shocked to see the degree to which data is glorified in policy schools, where from what I’ve seen the focus is largely on what is measurable — not on understanding the problem space. This mirrors what happens in government. I’ve been weirdly fascinated by this, and wrote about it last year in case anyone wants to go down that rabbit hole.
3/ THE POLICY ESTABLISHMENT
When I say “policy establishment” I mean people working in, studying, and covering public policy: career employees, appointed officials, elected officials, journalists, scholars, etc.
The uncomfortable reality is that the problems with government are not technology — they are institutional and policy cruft and sclerosis that has built up over decades. However, over those decades, technology has become the spinal cord of government. Technical infrastructure is the infrastructure of *everything.* It can accelerate or obstruct policy goals. For some reason that continues to evade me, the policy establishment doesn’t seem to get this.
You know who gets this? DOGE does. Elon does. Trump does. They understand the degree to which technology and government (and power) are entangled. Tech journalists understand this too. It’s not an accident that Wired and 404 Media have been leaders in coverage of the second Trump administration. They have long understood the nexus between technology and power.
Just look at DOGE's approach. When they began cutting across the government, where did they go first? Not to policy offices, not to secretary suites, not to planning departments. They went directly to the levers of IT systems and operations. First the U.S. Digital Service, then OPM (government HR), then GSA (operations and tech contracts), and THEN Treasury. Even the money was the fourth stop.
That tells you everything about where real power—and real change—actually lies.
What were the factors that enabled it to succeed?
Emily + Kathy: This probably varies across teams, but there are a few factors that were valuable for the U.S. Digital Service that might resonate with others. We’ve drawn these from our insights from our oral history of the origins of the US Digital Service.
Small teams of cross-functional experts, with executive backing. The USDS believed that small, semi-autonomous, cross-functional teams of highly capable experts with top-cover from the highest office in the organization could drive change — not alone, but in partnership with key policy leaders and public servants. This structure was somewhat novel in government. It also enabled USDS teams to work on the front lines of products and services alongside people who rarely communicated directly with leadership. This gave USDS an unvarnished view of the issues.
Focus on the outcome, not an output. The goal was not focused on the technology alone; it was focused on delivering a better outcome and experience. The technology was a vehicle to addressing outdated policies, procurement and hiring issues, and convoluted business processes. For the most part, USDS teams did not arrive with a predetermined intervention in mind. They arrived seeking clarity on a problem, and then helped to identify a path forward to improve a specific outcome.
Prioritize relationships and deep understanding. Two consistent priorities in how USDS approached its work included (1) developing a deep understanding of the problem at hand, and (2) and building trusted relationships with those closest to the issue. These approaches paired well with USDS’s efforts to push the envelope and maintain focus on practical outcomes rather than just technical solutions. USDS teams worked most closely with the people who had their hands on the technology or the programs, whether they were government employees or contractors. More often than not, the technology was the easy part – the human element made the real difference.
Begin each project with a “discovery sprint.” USDS discovery sprints dedicated time, usually two weeks, to understanding the problem before identifying potential interventions. That understanding did not come in the form of lengthy research and studies, but in practical, hands-on exploration of problems and direct observation with fellow public servants and other stakeholders. This approach allowed teams to immerse themselves in the problem space and develop diagnoses before making recommendations. The tactic carried over from the technology and product worlds that many early USDS staffers came from, and was successful because it included both public servants and “users” – in this case, the American public – in the process. Read more about USDS’s approach to Discovery Sprints.
Embed within the system. Working side-by-side with peers in government played an outsized role in successes of USDS, especially when USDS engineers interfaced with agency or contracted engineers. This approach created a whole greater than the sum of its parts: Technology acumen from USDS combined with policy and organizational acumen from long-time public servants.
Invest in hiring and talent early on. USDS succeeded because of its people, and those people were able to join because of a novel government recruitment process that merged public and private sector approaches. Hiring was identified early on as mission-critical, and even became one of USDS’s values: hire and empower great people. A dedicated team, the USDS Talent Team, was created at the founding of the organization, to find talented individuals and create a pathway for them to join and serve in government. The talent team also created the core competencies of a successful USDS staffer across different fields and evaluated all candidates for both TQ (technical quotient) and EQ (emotional quotient), recognizing that how people worked was just as critical as their skills.
Civic tech, to all intents and purposes, has been displaced by DOGE in the federal government, a very different philosophy of tech and government. What do you see as the differences between the two approaches?
Emily: While the U.S. Digital Service was renamed the U.S. DOGE Service, civic tech is alive and well in many places. I’ll get to the differences I see in a moment, but I want to start with a somewhat uncomfortable reality:
The U.S. DOGE Service and the U.S. Digital Service start from the same basic premise: the government is failing to deliver on its promises to the public.
The foundational divergence is what you do with this premise, and from there it seems that goals, priorities, and the approach / mode of operating also differ.
To answer your question more directly, the three major changes I see are:
1. STRUCTURE. It moved from the office of the federal Chief Information Office to its own component, essentially making it a peer of the National Security Council. I think it’s worth saying that this is something that some in the U.S. Digital Service had advocated for during the second Obama Administration.
2. MISSION. Based on the executive orders establishing its remit and powers, the focus of the U.S. DOGE Service is, at least on paper: (1) efficiency, (2) cost-cutting, and (3) software modernization.
Of those, the only overlap with the U.S. Digital Service is software modernization: to “... improve the quality and efficiency of government-wide software, network infrastructure, and information technology (IT) systems.” Here the quality and efficiency of technology are the goal.
The mission of the US Digital Service was to deliver better government services to the American people through technology and design. The focus in that mission was on better government services, not tech. For the US Digital Service, the tech was a *vehicle* to fix those outdated policies, those procurement and hiring issues, those convoluted business processes. This may seem like a pedantic difference, but it is not — it is foundational. Focusing on technology centers the technology, the systems, and the institutions. Focusing on the service centers the outcomes and the people.
3. PERSONNEL. As the now famous adage goes: Personnel is policy. The overwhelming priority of the US DOGE Service has been engineers and developers, and while this was also a focus of the US Digital Service, design, product, and other roles were critical to shaping both the organization and the work. It is painfully clear that the hiring priorities have changed.
For more, check out the civic tech timeline, and key quotes from the interview archive. The Better Government Lab, which I co-direct, is interviewing civic tech actors forced out of the federal government to learn lessons from their recent experiences, so watch for future discussions about the evolution of this field.
Kathy Pham served as a founding product and engineering member of the United States Digital Service (USDS) at The White House, where her service spanned the Obama, Biden, and Trump administrations. Kathy is a Fellow and Faculty member at the Harvard Kennedy School where she created and teaches Product Management and Society.
Emily Tavoulareas co-founded the first agency-level team of the U.S. Digital Service at the Department of Veterans Affairs, and served as Senior Policy Advisor to the US Chief Technology Officer at the White House. Emily is an adjunct professor at Georgetown’s McCourt School of Public Policy, where she is focused on technology and public policy.





The article is full of golden nuggets - and this cold aisle creature is not even in the .gov or anywhere close to it - thank you!
"...technology is neither the problem nor the solution, and that if we really care about fixing a problem or improving something, we must take the time to both understand and address the conditions creating the problems. If we don’t, nothing really changes."
⬆️this! (tech for people vs. for the sake of it, or arbitrary KPIs or frozen SLIs or the C-suite! If only this could be codified into law and an army of incorruptible ninjas could enforce it...)
I so resonated with Emily's bullet points about information sharing, outputs vs. outcomes, the focus on people and the "boots on the ground", the broken procurement processes, and with Kathy's points about policy vs. tech and talent. All of it very much applies to my work in the private sector over the last 40 years. Makes me so happy knowing there are like-minded people out there!
Such a clear explanation of the area of civic tech. I've read other articles about USDS and was always impressed with an organization that had such a clear and successful mission, and that understood that the purpose was to improve things for the public. I thought that DirectFile was such a huge, successful step forward for taxpayers. I would like to suggest, in regards to the statement Emily wrote: "That tells you everything about where real power—and real change—actually lies." I believe instead that IT provides access to real power and real change but it is still directed by those at the top of the pyramid and when they are ignorant and/or corrupt, they focus on their own self-interested destruction instead of improvement.