In my first post about government technology leadership positions, I wrote about how “IT” in government has unhelpfully come to mean “all things technology,” and how we need to tease apart the distinct roles that Chief Information Officers (CInfO) and Digital Service leads play in cities, states, and federal agencies today. I started writing about this topic because we get so many requests from non-technology leaders in government for help filling technology leadership positions. In this post, I’ll address some questions around the Chief Innovation Officer (CInnO). Whereas the CInfO title has unhelpfully come to mean everything related to technology, the problem with the CInnO title is that it can mean anything.
The first Chief Innovation Officer in government I’m aware of was Bryan Sivak, who took the role at the state of Maryland in early 2011. Governor O’Malley had a set of 15 urgent, measurable, cross-cutting goals that he personally spent most of his time focused on. Bryan’s job was to work across the government to accelerate progress on each of the goals as much as possible. In his case, the “innovation” bit of his title really meant “silo-buster,” and he was working towards specific goals.
Other CInnOs have more clearly defined mandates. As CInnO of San Leandro, CA, Deborah Acosta is tasked with attracting modern investment and tech jobs to a traditional manufacturing city via Lit San Leandro, a 10 gbps, 20 mile fiber optic infrastructure. Similarly, Abhi Nemani is serving as Sacramento’s Interim CInnO with the mandate to stimulate the startup ecosystem there. In each of those cases, the “innovation” label could easily be replaced with something more specific, but the title may not matter as long as they know what they need to do and have the authority and resources to get it done. But in many cases, CInnOs have neither clarity about their mission nor the authority and resources to carry it out.
When a government leader creates a role like a CInnO and defines it too broadly, it’s usually driven by a diagnosis that’s hard to argue with: ossified processes and practices, lack of questioning of the status quo, resulting in low performance. Too much structure and overly prescriptive solutions seem to be the problem, so giving a CInnO a lot of freedom to do whatever is necessary to change the organization seems like the right answer. But it can end up looking like a bit of magical thinking. The people who own the operations that government leaders would like to see “innovated” aren’t measured by innovation. They are measured by (or perceive themselves to be measured by) stability, reliability, and compliance with a wide range of policies, laws, and regulations. And they retain the authority and resources to get those results in the face of any number of innovation initiatives imposed upon them.
Moreover, many of those operational leaders would like to lead their own innovation initiatives, and under the right circumstances, they can be more than capable of doing so. CInnOs who see themselves as coaches, obstacle removers, and air cover for career bureaucrats to innovate on their own terms can have significant success, but often need to ensure the credit goes to the departments, not those formally charged with innovation. Boston, Philadelphia, and Austin have each created offices dubbed “New Urban Mechanics” to partner with other departments on “risky” experiments, and provide cover if they don’t work and credit if they do. New Urban Mechanics co-founder (and Code for America board member) Nigel Jacob describes these offices as “risk aggregators.” (A good example was their “Bump” app using the sensors in the smartphones of city drivers to detect and automatically geolocate potholes — an innovation that was later adopted by various private sector actors.)
There is one definition of the CInnO role that we need to watch out for. Increasingly, CInnOs are being appointed with “fix the website(s)” as one of their many mandates. If you read my earlier piece, you know that I’m friendly to a strategy that assigns citizen-facing digital services (aka websites and/or mobile apps) to a Digital Services lead who specializes in understanding and meeting user needs, and often works alongside, under, or (very rarely) over, a Chief Information Officer. There is no inherent reason someone qualified to be a Chief Innovation Officer (however defined) is not competent to lead digital services. But there is a huge danger in using the word “innovation” to describe the practices that result in websites that work.
The problem is that if you want “government technology as good as what we have at home,” (as Ben Terrett says) you’re going to have to do things like move to the cloud and test prototypes with actual users. That’s not innovation. That’s just how tech works today. The practices and tools that result in good digital services vary from organization to organization, to be sure, but there is a lot in common that the private sector, and increasingly the public sector, pretty much agree on as standard. When we frame these practices as somehow cutting-edge, risky, or non-standard, we do the mission a great disservice.
This is not to say that there’s no room for innovation in making digital public services as long as we set a reasonable baseline for what’s just “the basics.” (Fun fact: Code for America’s cupboards contain coffee mugs emblazoned with “#Innobasics,” a word our staff coined to express a certain coy outrage at the conflation of these two domains.) What’s the difference? Here’s one example:
· Basics: Making a website that works well for its users at a reasonable cost in a reasonable timeframe.
· Innovation: Opening an API and cultivating an ecosystem that makes alternate apps, websites, and services that work with the same data and same transactions for use cases we never anticipated.
What most political and bureaucratic leaders want when they hire a CInnO is the former. If that’s the case, they should hire one or more of the roles I discussed in my previous blog post, charging that person(s) with modernizing their digital tools and practices, not innovating them. Of course, what is innovative today becomes tomorrow’s basics. The ecosystem play described above is a natural next step and a modern digital shop should be able to handle the technical aspects of the API, though additional resources are generally needed for the cultivation and care of the ecosystem. That cultivation work could fall to the CInnO, but it might really fit best within the purview of program management. If that’s true, we can reserve the innovation label for other purposes.
I’ve frequently heard a defense for using the “innovation” label on what I’d call “the basics” in government simply because the term should be seen as relative. “Sure, Jen,” they say, “but you don’t realize how far behind we are here. This IS innovation for us.” I don’t buy this, because it sells government short, and because it unnecessarily mystifies practices that are simply that: practices an organization can choose to adopt. Using the word innovation here implies that you need some sort of genius, charismatic Steve Jobs figure hanging out in City Hall if you want good digital services. You don’t. You just need to throw out your old operating manual and get the new one. To be clear, this is incredibly hard to do in an environment where political priorities shift from day to day, job descriptions are locked down and hopelessly out of date, there is often a lack of understanding of and resistance to the cloud, and union rules prescribe what your team can and can’t do. The many amazing people who have been able to pull off this shift deserve enormous respect and admiration. But they did not invent modern web development. They simply had the courage and political skill to find ways to do it within an institution that had locked down, outdated practices. And by the way, those who have tried and failed deserve just as much respect and admiration.
Here’s another way to think about the relationship between innovation and the basics. A 2007 Honda Civic isn’t innovative just because I’m still getting around on a horse. In fact, it’s not even that innovative compared to a 1989 station wagon. It’s just a more modern car. Real innovation today is not needing to own a car because now I can summon one whenever I need it with a tap of a button. Eventually I’ll summon a car that will drive itself. And government will need to innovate to deal with the consequences of changes like these, both through new policies and through tech-enabled implementation of policy. How, for example, might a city respond to on demand services like Uber and Lyft, other than with regulations written dozens of years ago in a world with different challenges? New data sharing agreements with these services could monitor their compliance with the city’s goals — for example, providing fair access to these services from traditionally under-served neighborhoods or reducing peak hour congestion. How might a city provide or enable digital infrastructure that would enable the self-driving cars of the future to reduce congestion or the need for parking?
I also don’t want to use the word innovation to refer to what are now basics because we do need true innovation in government. We face economic challenges such as the hollowing out of the middle class and a growing number of people requiring access to social services. City planning challenges like gentrification of neighborhoods. Climate change. The spread of new infectious diseases. All of these are all going to require government to respond in radically new ways.
To anyone holding a title I have held up to scrutiny, please don’t take offense. If you’re doing good work, I’m your champion no matter what your business card says. I offer these thoughts, which are intended primarily for non-technical leadership in government, because we have something to gain by getting clear on what we want out of the people we hire. But I’m also a fan of the “just do something” school. I’d rather governments start on the path towards both innovation and modernization and learn along the way than not start. To paraphrase Mike Sarasti, who starts as CInnO of the City of Miami today (congratulations, Mike!), it’s like writing a song. First you just gotta jam for a while, and keep it loose. Eventually, you’ll have to draw the line and lock it down.
At the end of the day, what titles we give to the people who do the work of technology and innovation in government matter less than what gets done and whether the result works for the people who use the service you are providing. By the way, they don’t really care what we call it either. Whether citizens or consumers, the public generally just wants something that works.
PS: For a succinct and entertaining diatribe against “innovation,” treat yourself to Russell Davies’ blog post about a help guide. Wise words.
PPS: Congratulations also to Brendan Babb, now the CInnO in Anchorage. Brendan has been innovating access to food benefits and other government services from his leadership role at Code for Anchorage for some years now, and I’m delighted to see the City recognize his remarkable achievements and bring him in.
PPPS: Thank you to everyone who read and commented on a draft of this document. Particular thanks go to my husband Tim O’Reilly for his thoughts on 21st century regulation and Mike Sarasti for his thoughtful perspectives and his delightful music metaphor!
Be a part of the conversation. Join me at the Code for America Summit, November 1–3, 2016.