Because the field is new, and operating at the intersection of very different working cultures, you will be comparatively alone and in charge of organizing your own work on most civic tech projects, no matter your professional level. Even if you join an established team, each new engagement will bring questions of how best to partner, and how to shape a project for the biggest impact at each stage.
it’s important to understand from the start that creating a bridge between IT and program staff will be required in almost every civic technologist’s job.
Early volunteer civic tech efforts reflected the demographics of people who had the time and means to do free work, and in particular skewed toward engineers and open-source contributors. All of these categories tend to be whiter, more male, and more affluent than American society at large—and for a field that aspires to make technology for everyone, this is a problem.
Maybe you’re on the team that can create the multilingual-by-default, reading-level-checking, accessibility-baked-in prototyping suite that would give every civic project in the nation a boost in the right direction.
As you think broadly about your motivations, these questions may help guide you toward specific mission areas: ● What do you think of as “good” in society? ● What is currently in the way of that good happening? ● What change do you want to see in the world as a result of your and others’ civic work?
Much of the start-up ecosystem in this field is focused on city and county governments. This is a substantial market, as there are about three thousand counties and some twenty thousand cities and towns in the United States. Many cities and counties have procurement authorities that allow them to engage with (relatively) small companies for (relatively) small engagements, via request for proposal (RFP) processes that are relatively informal. You don’t necessarily need an entire department to win government business at these levels, but you do need someone in your company to become expert at it, and you need to be able to work with a slower sales cycle.
because it’s operating as a paid service, 18F priorities are those of government customers rather than the White House (though the White House is occasionally a customer as well). If you join USDS or one of the state-level digital services, you can guess based on administration priorities what you might be working on, but 18F works on needs agencies themselves identify and collaborates intentionally with agencies that want to advance their digital practices.
One of the strongest infrastructure plays we can make as civic technologists is to work on data projects. There are few useful services that don’t depend on data, and having it available in a convenient, machine-readable format is a precondition for all kinds of further building and action.[ 23] In many places within the public sector, valuable data is on paper in binders and file cabinets; many digital systems are merely containers for scanned, unindexed PDFs.
I would be remiss if I didn’t talk about forms as a major area of needed work in citizen-government interaction. An enormous number of interactions with government, certainly with executive-branch agencies or courts, involve filling out a form—and most of these forms are confusing, hard to read, and repetitive. Granted, it’s not the cutting edge of software innovation—but improving forms, either by better designing paper ones or creating great, accessible, mobile-capable web ones, can be a significant boost to people’s direct experience with government.
there’s a falseness to setting innovation as a goal. Newness does not closely correspond to fitness for purpose, and the latter is far more important in mission organizations. Newness in a technical sense may place a government or civic interface out of reach of many of the participants it is required to serve. The assumption that everything requires brand-new thought leads to ignoring many opportunities. Further, if our networks and knowledge of history are weak (and that applies to very many of us in civic tech at present), we may be completely mistaken about whether an idea is actually new.
The civil service that performs most of the actual work of delivering government to the public is designed to be a long-term institution. Its role is very specifically to provide continuity across the partisan shifts and fads of mere administrations, which come and go. This can be frustrating to changemakers, but as the saying goes, it’s a feature, not a bug. If it throws friction in the way of an administration you agree with rapidly implementing policies you like, it also throws friction in the way of an administration you disagree with rapidly implementing policies you don’t like.
Making it safe to move a little faster and fix things—with deliberation and with the public interest always in mind—doesn’t have quite the same ring, but it respects the central value of the public service environment.
A working, data-driven prototype offered for live testing to hundreds of agency staffers with an assumption that the team will learn enough to get a second phase funded can degrade during a long budget process, or end up as the only thing that is ever delivered due to an administration change. Often, in order to move beyond a prototype, a team has to confront the legacy systems in place. Helping move a government agency away from a costly and clunky database architecture (for example) can be one of the biggest possible wins, but it requires long-term focus, significant tech and organizational skill sets, and usually work with procurement and other bureaucratic processes too. As you build any live prototype, it’s worth exploring the current system and starting to think about how—in the best case where everyone is excited to make the prototype real—you will grapple with these challenges.
After a research project addressing the subject, we settled on the idea that a government agency is transformed when it chooses and manages technology effectively in the service of its larger mission, and when it’s capable of handling the inevitable next technological change on its own. In other words, an organization has only cleared the hurdle of digital transformation when it’s capable of continuous improvement. It’s very much worth pointing out that most private-sector organizations haven’t cleared this hurdle, either, and many start-ups haven’t been through enough changes to know whether their practices are sustainable or not.
if you’re working on immigration or criminal justice or disaster aid, it may help to think of yourself as part of a relay. Making these essential functions as good as we, the public, deserve them to be, is going to take a long time.
It may not be reasonable (okay, it’s really not) to spin up a multidisciplinary agile team and start development sprints if there’s still substantial strategic uncertainty.
If you want to make a significant positive impact on people’s lives as a civic technologist, at some kind of scale, and you are starting from scratch, you should plan on a minimum of two years to see it through. Three to five years is more realistic in many situations—and even if you put in five years, there’s no guarantee of success. This is as a core team member, where the work is your full-time job; you may also encounter some “spot” opportunities to consult with a team, where you can play a specialized role in a two-to-five year effort without spending the whole time in-house yourself.
If we know the process will keep going even if we as individuals get exhausted and take breaks, then the two years or five years become less of a source of anxiety. Whatever you’re able to contribute, for however long you’re able to spend, will be valuable—especially if you write it down. Documentation is how you pass the baton in the relay.
whether you succeed or fail in the short term, think of your work as part of the fifty-year project, and expect that your contribution will matter to some other person working on it. Make it easy to find, take a break if you need to, and come back when you’re ready again.
The best way to prepare for a civic tech career is to learn as much as you can about different methods, value systems, and types of constraints, and to refine your collaboration skills by working with as many different types of people as possible.
Cleaner, more modern software always seems desirable—but only to the extent that its champions also offer the capacity to maintain it and sustain continuous improvement into the future. Many technical people argue that cutting-edge software isn’t as useful as solid software built on one-generation-back architectures and languages.
Trained policymakers answer questions like these through a canonical process cycle encompassing development,[ 61] implementation, and evaluation. In many ways, the cycle is similar to the build/ measure/ learn feedback loop from Lean methodology, but more formal and with different assumptions about how and how fast changes occur. While policy development is something of a negotiation between legislative and executive branches, policy implementation and evaluation are largely the province of the executive branch, with oversight from the legislature.
Evaluation can reveal successes and failures, and may generate new problems to be solved with policy levers. If you’re a data scientist, a product manager, or a user researcher, make it an immediate priority to meet the nearest evaluation group and learn what they’re up to. They’re likely to be doing rigorous, academic-style research on questions related to the ones you’re looking at in a shorter-term, less formal frame. Their work can definitely inform yours, and yours might well be able to inform theirs.
In the 1990s, dot-gov domains were hard to use because of restrictive policies about outbound links to non-dot-gov domains. Many local governments preferred to avoid them because they wanted to link to private or NGO resources. (If your city or town has a dot-com or dot-org website, this is why.) In the 2000s, technologists advising the dot-gov registry changed this and standardized rules for local government web addresses in order to help “regular” people understand whether they’re on a legitimate government site.
it’s hard to design dashboards to make clear how reliable each data component is. Instead, they tend to confer an equally authoritative appearance on everything on the screen. Don’t fall into this trap if you’re working with data. You’ll do a huge service to your partners if you articulate the pitfalls of numerical metrics and how to check them against qualitative evidence like user research and open-ended constituent comments.
Solidarity with the public mission means you’re amplifying the needs of the public servants who are working in the same space, understanding and to some degree accommodating the pressures that exist in their working environment.
Plan to factor the political status of your executives into your thinking. If an election the administration isn’t certain to win is coming up, you do not want to be closely associated with elected leadership. It’s much better in this circumstance to pursue a quieter style of support in the more administrative leadership ranks, because when—not if—a new administration is elected, many heads of departments will be replaced with new appointments. Pet initiatives of the previous administration may no longer be favored, either. (This is part of why it can be hard to start new things close to an election.)
Executive alignment becomes easier when you can pitch your work in terms that people who aren’t passionate about technology for its own sake can understand. These leaders are looking for how your technology proposals align with policy goals and strategy. You’ll need to align your product, design, and technical goals with the language of mission achievement, efficiency, and risk management.
When we researched digital transformation at 18F in 2016, we discovered that a key factor in the sustainment of innovation initiatives was the active support of well-connected, mid-tenured career staff. These are people who have been at an agency for maybe ten or fifteen years and hold ranks like program manager, senior analyst, or manager. They are uniquely positioned to project credibility to everyone in the organization, both “up” and “down” the hierarchy, and they have a wealth of information about history. Frontline staff feel comfortable sharing concerns with them, and executives check in with them to see how new ideas will play or find out what the staff really think. Those who combine this position with strong social skills and interest can often be found serving on committees, taking “detail” assignments where they temporarily embed with another department or agency, and generally making friends. If you can get one or two people of this sort as active partners, everything becomes possible.
Compliance team colleagues can be underrated allies to multidisciplinary teams and iterative development in general, and the earlier you involve them in your project, the better.
● Be completely transparent about your process—if you want to do user research, for example, share your full script and your data plans in advance. Then, afterward, share your aggregated data and exactly what you learned. (Even better if you invite these stakeholders to participate in synthesis with you.)
Long-term victories in civic tech often come with a lot of short-term losses along the way. No matter your track record, you will lose battles, and you will have projects fail. Not just occasional failures, either—failures or partial successes are pretty likely outcomes. Losing is tiring; if you’re able to draw lessons out of those failures and share them with the community, they won’t be in vain, but that too demands something of your personal resources.
If you’re hired in a leadership role in a federal or state agency, you should carry professional liability insurance. As an expense, this runs around $ 200–400/ year, protects your personal assets (your savings, house, etc.), and provides some coverage for legal fees if you are named in a lawsuit against your agency, or found at fault in an investigation.
A while ago, I spoke with a civic tech colleague whose yearslong stretch on the same project had been especially taxing. He had an overwhelming sense of just not wanting to, in general. Furthermore, he had taken short vacations—the kind of time off that would have restored his mojo in the past—and had returned to work only to find the same don’t want to waiting for him. This unshakable don’t want to is the hallmark of burnout, and it may even escalate to can’t, especially if work challenges are combined with other stresses.
Pervasive structural racism in the United States means people of color are at greater risk for burnout because of overall heavier day-to-day burdens; and the unequal distribution of care work means women are generally at greater risk, too.
We need to throw the doors open and welcome more people from more backgrounds, and make it easier for juniors to navigate the field. We need to make sure each of our projects acknowledges and benefits from prior work, and we need to treat policy and advocacy colleagues as full stakeholders.
we’ll need to institutionalize a bit. We need many more books than this one, from different perspectives, and we need archives and a coherent history of projects, both failed and successful.