Want to innovate government? Focus on culture

TL;DR: The key to innovation in government is engendering a greater appreciation of technology among non-technical stakeholders

4 minute read

When innovating in government, the technology’s the easy part. Innovative efforts often do one of two things:

They take long-established technology from the private sector and inject it into an agency, or
They reimagine long-assumed processes from the citizen’s perspective.

The ultimate meta yak shave

To innovate government, 90-day, 120-day, or six-month “fellowships” (read: glorified internships) aren’t the way to do it, at least not alone. Talk to any Code for America or Presidential Innovation Fellow and you’ll hear a common theme: absent sufficient cultural, administrative, and political support, between 30 and 60 percent of your time will be spent not doing what you were actually brought on to do, but rather convincing others that that’s what you should be doing (or that they won’t go to jail if they help).

You have to fight for the tools, you have to fight for the workflows, you have to fight for the resources, and you have to fight for the solution itself. Every step is a fight, and that’s assuming you don’t have to argue things that are long-resolved in the rest of the technology world like the security of PHP or Ruby versus .Net or the need for continuous deployment. And we’ve only just touched the surface of the technological considerations. There are countless layers of policy, administrative, and bureaucratic hoops to jump through or otherwise route efforts around. Just whisper the phrase “change review board” and observe a change agent’s reaction.

Bureaucracy is an organism

Bureaucracy’s primary goal is survival, and like any organism, it has an immune system. The white blood cells of bureaucracy are the general counsels, privacy officers, security officers, and paperwork reducers, among other bureaucrats, and it’s in their personal and organizational interest to reduce risk to as close to zero as possible. By necessity, they thrive in a culture of “no”.

An innovator’s primary goal is the exact opposite. An innovator thrives on sustainable disruption. These two countervailing interests — stability and instability — balance each other out in most organizations, however, absent the traditional profit motive found in the private sector, government gives this immune system the privileged position of actual or pocket veto authority over just about every agency decision.

Never take “no” from someone who can’t say “yes”

You could have the most innovative idea, perfectly executed, and fully within the letter of the law, but if any one of the ten to fifteen layers of agency’s immune system so much as sniffs an antibody they’re not familiar with, the effort’s dead in the water. Whether the threat’s real or perceived, it’s perpetual pollen season and the bureaucracy has chronic allergies.

So how do you solve for the vocal naysayer minority? What’s the Claritin or Zyrtec of bureaucracy ? In a word: culture. Culture isn’t getting a coworker a card for her birthday, or an office-wide March Madness tournament. Culture is the cross-department set of unspoken assumptions that frame any conversation within an organization. Culture defines the realm of the possible, and in the case of government, it is a powerful exclusionary force.

What if your biggest fight you faced was outside, not inside your organization

“Parachuting” change agents into an organization is great, but if you really want to inject innovation in government, target the support roles. Non-technical stakeholders have increasingly become the “blockers” in the true software sense of the term, and today, it is they, not the underlying technology, that needs innovating.

To foster innovation, when an innovator approaches a non-technical stakeholder, there needs to be a common appreciation for one another’s craft, and more importantly, a common vocabulary. I’m not suggesting the typical government alphabet soup of PRA and ATOs, but the type of shared perspective and mutual respect that you’d expect between skinny-jeaned peers at a stereotypical San Francisco startup. Heck, even GitHub’s accountant learned how to code in her spare time. It’s not impossible.

The missing punch

Looking back at some proto-open-data-policy brainstorming emails from Summer 2012, there was a third punch to go along side the one-two punch of policy and tools that was the White House Open Data Policy, a punch that ultimately did not make the final version. There were three specific proposals to foster a more open data friendly culture:

Google-style lectures - Bring in the smartest of the smartest (Google, Twitter, Foursquare, whatever), put them in a bullpen, and have them talk to Government IT folks about what’s big in terms of technology today, how to, etc.

Conferences - Establish a fund to get government folks to private sector (read: outside of DC) conferences on technology

Technology crash course - 1/2 day gov-only bootcamp for non-technical folks to learn what’s out there. Open source, how easy it is to build an API on top of a dataset using Rails, etc. a.k.a, empower the government to become an informed consumer

What if every Wednesday 18F invited an innovator — a CEO or CIO of a prominent private sector company — to come inspire government employees, both technical and otherwise, to hear how their company works on a day-to-day basis and streamed it to anyone with a government email address. We’re not talking about a sales pitch, we’re talking a super-informal, Inside the Actor’s Studio style “ask me anything”. How do you handle hiring? Customer service? How do you decide which ideas to run with? What’s in your stack? How often do you deploy?

The idea is to pop the beltway bubble — expose otherwise isolated, non-technical career government employees, not to cutting-edge ideas, but to common-place practices well established in the private sector, to redefine the norm, to fold the map in half and bring a bit of the West coast to the East coast.

Empowering lawyer linebackers

Those three components — lightning talks, outside conferences, and targeted trainings — have the potential to unlock an army of lawyer linebackers, non-technical stakeholders that serve as a force multiplier for technical talent, and ultimately the change we all desire.

What if when you first approached your general counsel for “approval” of your innovative new idea, you didn’t have to justify each layer of the technology stack — open source software, APIs, and distributed version control — but could say “hey, we’re launching a Rails app with a read-only API. The code’s going to be on GitHub”, and they simply responded “awesome, how can we help?”. What if those you relied on understood or at least appreciated not necessarily the how, but at least the why?

Vaccination through controlled exposure

The common complaint is often that those empowered to truly affect change simply “don’t get it”. Let’s fix that. It doesn’t have to be a government-wide or organization-wide effort. Take a day off of coding (or more likely meetings) and spend it engendering a greater appreciation of technology among those whom you interact with on a daily basis, empower subordinates to spend a few hours working through Rails for Zombies, or simply attend a technology conference outside the beltway. Baby steps are what’s going to get us there.

We’re not going to turn a large, bureaucratic organization into a startup, nor should we, but by helping non-technical stakeholders to gain a broader perspective of the technology landscape, we can take a step towards building a culture where innovative efforts are the honored norm, not an unwelcome fad, and where our innovators can focus on technology, not bureaucracy. Just as in your own immune system, here, vaccination is simply a matter of controlled exposure.

Originally published March 21, 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