What’s next for federal IT policy, IMHO

TL;DR: There’s been a lot of great momentum generated from the policy side, giving the geeks the environment they need to do what they do best, but that’s just the start.

2 minute read

While a government employee, as a developer and as an attorney, I had the opportunity to work in government IT, from both a technical perspective, implementing policy at various government agencies, and from a policy perspective, shaping that same policy at the White House. Here’s what’s next for federal IT policy, IMHO:

Shedding Cold-War era workflows

From the standpoint of workflow, we may as well be using a typewriter. Heck, the process would be essentially the same. An analyst fires up a desktop word processor, types out the policy, and then emails it around to increasingly larger circles of stakeholders, often creating a punch list of proposed changes (using their desktop spreadsheet application, of course) to opaquely track feedback after each round. Did you miss my comments? Did you disagree with them? Who’d you discuss them with and what were the arguments against it? After several months of this, the document is set in stone and finally pushed outside the firewall, sans this rich pedigree, often as a PDF, and given the pace of technological change, is almost undoubtedly already out of date.

I was fortunate enough to be part of the small teams the drafted the White House Digital Strategy and Open Data Policy. For the digital strategy, we took the baby step of publishing the digital strategy — a document which begged and pleaded agencies to use machine readable formats — in HTML, rather than PDF, a somewhat unheard of move at the time. For the open data policy, we took that a step further and drafted in, and published the policy as a living, collaborative document on GitHub, where anyone — government employees and civic hackers alike — were invited to submit proposed improvements.

Industry-standard practices as policy

On a substantive level, the bulk of the policies we’ve seen have, by-and-large, taken a basic assumption on how the open source community approaches software development (open standards, shared tools, lean workflows), and codifies them into law. It’s a challenge, for sure, but there are two areas where we should start to see movement:

Culture and education - We can’t run the government of the 21st century with 20th century skills and workflows, and the way to get there is to cross-pollinate life in government with life outside the beltway. Attending non-government technology conferences, speaking freely about one’s work (both online and off) without stringent approval requirements, and streaming best-of-breed technologists from the private sector across government for an hour each week to simply show how they approach basic things like deployment, customer service, or managing risk will go a long way to bridge that divide.
Anachronistic laws - Most developers in government are well versed in the alphabet soup that is the PRA, FISMA, FAR, and ATOs. That shouldn’t be the case. We need to let software developers be software developers, not de facto lawyers. Policy folks need to rethink how we approach hiring (so we can attract and retain great developers, rather than contracting that role out), how we evaluate risk (so we can lower the minimum batch size before it becomes practical for a project to go out the door), and how we structure contracts (so that developers, not contract officers or tradition prescribe what’s needed).

There’s been a lot of great momentum generated from the policy side, giving the geeks the environment they need to do what they do best, but that’s just the start.

The is an excerpt, originally posted on opensource.com, and is republished here under a CC-BY-SA license.

Originally published October 15, 2014 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit