Tech tools & techniques for the public sector

I recently attended Nesta’s LabWorks conference in London, which brought together “innovation teams” from across the world. While I could (and probably should) write an entire post on the conference itself, the short summary is that the event was specifically focused on policy innovation: how to better inform policymakers, how to better implement and iterate on government programs, etc. As a software developer who has been in government ten months, I was definitely out of my element — in a good way. Was a good reminder that “innovation” is broader than the tech world.

After the conference, Bloomberg Philanthropies (who, full disclosure, sponsored my travel and attendance) provided this writing prompt:

What are the top three emerging tools and techniques that public sector innovators should pay attention to?

I’ve always enjoyed helping people without technical backgrounds better understand and use technology (though I acknowledge that much can go the other way), so here are three ideas government can incorporate from the tech world:

Static sites

As a developer in the US government, I spend a lot of time thinking about how to make software easier to understand, collaborate on, and deploy. One technique used extensively at 18F is heavy reliance on static web sites. For those unfamiliar with how web sites are built, back at the dawn of the internet in the early 90’s, web pages were simply “static” HTML files that contained all of the information needed to display a single page. The downside here is that if you had, say, a navigation bar, adding a new button would require changing every page. From there, sites moved to be more and more “dynamic”, which means that the HTML for each page would be generated as soon as it’s requested, based on things like what social media posts the user should see. This is great in terms of making a richer web experience for the end user, but adds a lot of moving parts, which can break.

In the past few years, there has been a resurgence of static web sites, though this time with site builders. Site builders re-generate the pages when the templates or content are changed, meaning that you can have your layout defined in one place, but applied everywhere. This is particularly relevant to public and nonprofit organizations, who often can’t hire/afford developers on staff to maintain their sites — nor should they have to! For presenting information like blog posts, reports, image galleries, etc., static sites are able to provide the flexibility of a larger-scale content management system (e.g. Wordpress or Drupal), but without the setup cost, operational overhead, performance penalties, or security concerns.

Incentives for openness

While there are always features to add, bugs to fix, stability to improve, I’ve noticed over and over that the hardest challenges in (but not limited to) government are people problems, not technology problems. For one of my projects, we needed to get a list of buildings owned/leased by the agency. This seems like a fairly straightforward question, but answering it took two months of emails back and forth to find the right person with the right spreadsheet. This has been my main argument for open data: why shouldn’t I be able to download that information from somewhere in a machine-readable format? Before joining government, my main arguments for open data were around transparency and accountability. While these are both noble causes, they aren’t very good incentives for the people in charge of that data. Making information more accessible within, across, and outside of agencies, however, helps me do my job, and thus saves time and taxpayer money.

Similarly, developing software behind closed doors (“closed source”) means that users of that software (inside or outside of government) are unable to provide feedback to the developers or even propose changes on the content or code directly. Different governments and government agencies are often solving the same problems (keeping track of employee records, providing informational and contact pages, managing approval workflows, etc.), so open source software can mean the next group can pick up your software where you left off, deploy it for their own purposes, and contribute improvements back to the original. These benefits alone far outweigh any downsides of developing software in the open.

The civic hacking community

As mentioned above, few public sector (and nonprofit) organizations have their own design or technical teams in-house, nor can they afford to hire high-quality development firms. What these groups rarely leverage, however, are their civically-minded citizens, who would love a way to make a meaningful contribution to their governments. Many cities have Code for America Brigades or other civic hacking groups, who are constantly playing with open data, creating visualizations, making apps to find various social services, and more, all on their free time.

Despite all this energy outside of government, relatively few public service employees interact with these communities, outside of the occasional hackathon. Perhaps worse, civic hackers don’t have a great way to find the relevant parties inside of government. For example, if they are exploring a data set and have a question (or spot an error), it’s hard to find the relevant person who could make the fix. If they create a visualization that would be helpful to a particular agency, it’s hard to get it in front of the right people.

Thinking in the other direction, many civic hackers would probably be happy to explore a particular problem that an agency is facing or provide meaningful feedback on a new site/page/post, but that communication rarely ever happens. challenge.gov is a platform that offers large-scale problem statements, but I believe small, weekend-size development or data exploration projects could be equally valuable. Civic hacking communities should be leveraged to answer problems and questions governments are facing.


Would love to hear other ideas!