Ten Things You Learn As A Presidential Innovation Fellow

TL;DR: The challenges we faced were overwhelmingly administrative, cultural and bureaucratic in nature. Here are 10 things I know now I wish I had known then.

5 minute read

This post originally published as part of FedScoop’s guest column series.

Looking back on serving in the inaugural class of the Presidential Innovation Fellows program, almost one year to the day we started, it’s clear now that going in, many rightfully assumed the challenges we’d face would be largely technical challenges. In hindsight, the challenges we faced were overwhelmingly administrative, cultural and bureaucratic in nature. When driving innovative efforts within government, whether as a fellow or in one’s own agency, here are 10 things I know now I wish I had known then:

1. “Innovative” efforts in government are standard practice in the startup world

Most of the problems the innovation fellows solve are not moon-shot problems. They’ve all been solved before by the private sector. Relying on open source frameworks like Ruby on Rails, exposing APIs and consuming them yourself, or designing applications with a service-oriented architecture are all standard practice for any San Francisco startup worth its venture capital funding. Introduce lean technologies and ways of thinking that have a proven three-to-five year track record outside the Beltway, and you’ll be an innovator. Chances are the internet has already solved whatever problem you’re facing. Stumped? Just look West.

2. Ship early, ship often

Scrappy is good. Government loves things to be perfect before they go out the door. That makes sense with laws, which may take months or even years to change. But when it comes to technology, it’s about starting small and iterating. As an innovator, you’re not just building technology; you’re also building a technocratic culture. Look to low-lift, high-visibility efforts that validate your underlying assumptions and can prove your vision’s viability to a larger community of nay-saying stakeholders. A working prototype or successful proof of concept is incredibly persuasive in the face of “you can’t do that” or “that’s not possible” rhetoric. Here, as elsewhere, code speaks louder than words. Know what you want your 1.0 to look like, and build toward it, but launch with 0.1, launch with the minimum viable product that can introduce your vision to the world. If you’re happy with the thing you ship on day one, you’ve already waited too long.

3. Sandbox progressive teams within the organization if you want them to succeed

The success of innovative efforts cannot be benchmarked using the same yardstick against which an agency’s traditional core competencies are measured, nor can teams thrive when dropped into an environment with years of shared history potentially antithetical to the team’s agenda. Isolate innovative efforts, administratively and culturally, and provide them with the political air cover to secure the necessary resources and execute on their plan free of internal politics or drama. That’s everything from their definition of success, to procurement, to dress code and hours. Found a startup within your larger organization, give it seed funding and great board members to support it, and get out of its way.

4. Make friends with a lawyer on day one

Find your government Sherpa. For every line of code you write, there’s going to be a line of legal code or bureaucratic red tape telling you that you can’t do whatever it is you want to do. That means half the time will be spent building the thing you want to build, but an equal amount of time will be spent crossing T’s and dotting I’s to ensure your project’s blessed by the powers that be. Friend a lawyer (or other subject-matter expert) on day one, and make them part of your team. Don’t let anachronistic requirements drive product development, but their experience and insight may help you to discover innovative workarounds to avoid unnecessary administrative legwork. Make sure they’re fully in the loop and know where you’re going, so they can spot potential roadblocks before things trip you up.

5. You are a cultural ambassador

You’ve got two products to deliver when your tenure is up. The thing you’ve actually set out to build is the easy part. You’re also the de facto ambassador to a potentially radical startup-based culture. You’re entering a world where almost all business is transacted via conference call or in-person meeting, where overengineering and “enterprise solutions” are the default, and where open source and rapid experimentation is basically unheard of. Use your time in government as an opportunity to fix that. From injecting emoji and animated GIFs into otherwise-austere email chains to fundamentally shifting a team’s priorities. In government, paperwork is king. Without you, things like security, procurement and other box-checking exercises will always come first. Show them that “it works,” “it’s legal” or “it’s secure” aren’t good enough for government work. Leave behind a culture that values design, usability and interoperability on equal or higher footing.

6. Have an exit strategy

Building something awesome is great, but if it’s just going to sit on a shelf and collect dust when you leave, what good is it? There are forward-thinking career employees within your organization who have wanted change for years. Help them to enable it. Make them part of the team, and more important, make sure they’re bought into the vision and have the tools they need, both bureaucratically and technically to see it forward. They’re going to adopt your baby once you leave. Make sure you leave it in the right hands.

7. Don’t take no for an answer — better yet, don’t even ask

Government embodies one of the most risk-averse cultures out there, and the supporting business units technologists generally work with most closely (security, legal, privacy, etc.) are often there primarily to mitigate risk. “No” doesn’t necessarily mean “no.” It’s often evidence of a failure to educate on your part. Many supportive roles exist to evaluate risk, not to eliminate it entirely. Don’t enter a meeting asking for permission. Enter a meeting asking for the best way to accomplish your goals while minimizing the agency’s exposure. If all else fails, it’s always easier to ask for forgiveness than permission. You’re not going to go to jail for failing to check a box, especially once the train has left the station and it’s picking up momentum.

8. Be vocal about your vision and make your efforts known

Make open the default. Talk about your work early and often, and encourage anyone and everyone to provide feedback. Secrecy is the norm in the private sector because for-profit corporations have competitors, and tipping one’s hand as to future plans can negatively affect the bottom line. Government doesn’t have such competition. When our government works better, we all win. Articulate your vision early on, and provide constant updates on your progress. Show a steady march of progress within your organization, and with the broader public. For the first time, technology is making working together easier than working alone. Use that to your advantage. You’ll get meaningful feedback before your product even launches, and an effort the public is excited about is much harder to kill or tie up in red tape. Put another way: Transparency is an asset, not a liability.

9. Not everyone wants to change the world

Innovation generally attracts those with a passion to change the world, but not everyone around you shares that same passion. Change can be painful, frustrating and potentially threatening to long-entrenched roles and responsibilities. Many career employees, arguably the linchpin of any long-term effort, care more about a steady paycheck and a good annual review than reimagining a particular business process to optimize for citizen experience. Get them on your team. Explain how you’re going to help move them from lower-level work to higher-level work, how they’ll be able to go home earlier at night, how they won’t have to check email during their kid’s soccer game. Show them you’re a potential rainmaker, not a threat to their way of life, and create carrots for them to make it in their personal interest to do the best thing, not the default.

10. Informal, cross-agency relationships are key to creating meaningful change

You can be doing great things within your organization, but discrete pockets of innovation don’t raise the bar across the board or push the culture in the direction you want. Reach out to like-minded innovators facing similar problems at other agencies or even other business units within your organization, and make your effort a government-wide initiative. There’s safety in numbers, and the perception that your work isn’t a fringe pipe dream but rather part of a broader movement that is going to set the new benchmark for success can give you a great deal of political capital. Stand up a repository on GitHub to discuss shared challenges, have a monthly brown-bag lunch, co-work once a week, start a regular happy hour. It doesn’t need to be formal; it’s about showing you’re not alone. Start a grassroots campaign to tackle your biggest frustrations.

Originally published September 30, 2013 | 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