The first federal chief technology officer discusses misconceptions about public-sector innovation and his new book, Innovative State.
Those living in the tech world are likely to know Aneesh Chopra. He was the nation's first chief technology officer, position created by the Obama administration, and remains a nationally recognized advocate of government transparency. With this experience in hand, Chopra went on to run for lieutenant governor of Virginia in 2013, and co-founded a data an analytics company, Hunch Analytics, that same year. This year, he's written a book -- Innovative State: How New Technologies Can Transform Government.
When it comes to his book, and to innovation in the public sector, Chopra had three things to say. First, he is hopeful this will be the decade of problem solving, especially in difficult areas that need fixing, such as health care, education and energy. Second, his hopefulness is grounded in the context that America has had an innovative state since its founding. "Therefore, I have greater confidence in this reversion to the mean, where we can return to that spirit and are in the process of doing so," he said. "Third, and last but not least, I wanted people to have specific tools they could use no matter who they were in our civil society."
Whether it's an entrepreneur looking to create a new business, a political activist trying to solve a problem, a voter who wants to see the country work better or a non-profit looking to improve stakeholder value, Chopra wants for everyone to see in the book a set of tools and techniques they could apply to deliver an innovative state.
He spoke with Government Technology about what open data continues to do for governments, both federally and at the local level, misconceptions about innovation in government and public-private partnerships.
Government Technology: If there was to be one notion readers gathered and kept after reading your book Innovative State, what would it be?
Aneesh Chopra: The most important message I would like people to think about is that the definition of an innovative state is one that embraces "handshakes" and "hand offs." The term handshakes and handoffs is sort of central to the book. Handshakes are the notion that much of what I talk about in the book is bipartisan and on both sides of the aisle. All levels of government have either already improved, authorized or embraced philosophically the notion that we should be opening up data -- voluntarily engaging in [open data] standards, issuing challenges and prizes [for civic tech initiatives], organizing lean government startups -- these tools are bipartisan and we've seen a lot of handshakes around them. But, it is insufficient. An innovative state doesn't stop within the walls of Congress or in the square miles of D.C.; an innovative state requires a handoff to the entrepreneurial ecosystem. For open in government to work, someone has to build that last mile of helping people find health insurance that's right for them, or helping seniors live more financially secure lives in retirement and so on. The handoffs are what are critical to create an innovative state.
GT: What’s the most pervasive misconception about government’s ability to innovate?
AC: I would say the biggest misconception is that there is a talent gap between the vibrant, successful exciting Silicon-Valley-like private-sector ethos and this perception of a laggard, old-school, underperforming public sector. If there was a myth to bust, it's that there are just as many entrepreneurs within the government with talent, with passion and with the benefit of a mission orientation -- that is, that they're called to serve on issues that are larger than themselves.
What we need to do is find a way to shine light on their talent and provide air cover so they can be successful and do a better job of interfacing themselves with the outside world -- this open innovation concept -- so they can be more successful.
GT: In your book you talk of open data as a major influencer to a multiplicity of sectors such as health care, energy and others. What is a major factor driving the open data movement as it matures?
AC: The first point I would get at is supply of data is significant. So let me give you some context: I wrote in the book that the original Healthcare.gov, the one that went live in July of 2010, built a data set that had never been assembled before. It was the most comprehensive database of public and private health-care insurance options ever amassed. And it was built within 90 days, because in part, when government tells the insurance companies to submit data, they do.
In contrast, there's a publicly traded company called eHealthInsurance.com that was venture backed over a decade ago ... and wasn't even able to finish the job ... So there's a tangible value in the government's ability to collect lots and lots of data, and when made available for the public, can be very, very useful.
GT: Often many open data policies and legislation use a softer language when requiring federal or state agencies to open up data. For example, open data can gradually be rolled out or on an "as soon as possible" basis. Should stronger, more regulatory wording be used?
AC: I think, that between the president's executive order on day one calling for the agencies to make data more open, our subsequent open government directive, the more recent presidential memorandum on open data, and all of the administrative actions that we've taken are absolutely sufficient to shift the culture and the mindset from a closed and constrained data environment to one that's more open and accessible. There are always moments and opportunities where legislation can be more specific. As an example, in the Affordable Care Act, Congress made explicit authority on opening up data -- essentially the Medicare claims files -- through new programs that would allow organizations to apply for and gain access to the most important database in the American health-care system. So individual data assets might have opportunities for more explicit authority. But as a broad brush, the president's executive actions are more than sufficient. It is hopeful future administrations will carry on this directive. And at some point, it might be an important legislative endeavor to memorialize what's been done at the executive branch thus far.
GT What are your thoughts on the recent passage of the Digital Accountability and Transparency Act, a law that mandates federal agencies to make their expenditures public? How will its stronger wording influence open data efforts?
AC: I would say No. 1, that the spirit of the DATA Act is spot on. Two, it's an example of a bipartisan commitment. I believe that bill passed without a single vote in opposition. And No. 3, I do believe there's an opportunity to replicate much of that consensus and focus on a broader slate of data assets -- it's obviously narrowly focused on a narrow set of financial data -- but one could imagine a similar approach on a whole range of data assets that today are not organized in a machine readable form. It's spot-on in the vision, it's a demonstration of bipartisan support and it has replicability across other domains.
GT: What role should private-public partnerships play to support open data?
AC: I think they're central. The term I would use is "ecosystem." And I want to credit my successor Todd Park for illuminating me that open data by itself doesn't do anything. He often makes the joke that "open data doesn't feed your kids." What he means by that is that within this ecosystem, entrepreneurs and innovators who have an idea on how they can create a service -- [for example], how to feed your kids healthy food -- might envision a set of data that's currently held by the government or could be organized better by the government as an important element to support a service. So you need a vibrant ecosystem to make requests from the government, to invoke its authority, to collect data and do it in better ways as much as you need the government to proactively look at its data sets to find ways to make information open. You need that yin and the yang and the concept as an ecosystem.
You may have seen the vice president's report yesterday on skills; this is the culmination of the president's call to action in the State of the Union, and if you read the vice president's report yesterday, there's a whole section dedicated to data jams, which are opportunities for the private and public sector to come together to talk about what can [and] should be made open, and how and where those resources should be turned into tools to help job seekers.
GT: There is a new breed of tech position popping up all across government -- chief innovation officers, analytics officers, chief data officers, and other tech-centric positions. How can these positions be best leveraged by cities and states?
AC: I do think there is an emerging organizational structure that acknowledges the need to have a world-class CIO and a world-class CTO, the premise being that the CIO can take leadership on ensuring the effective and efficient use of government IT spending -- [for example], are we moving to the cloud? Are we managing projects with rigor? Are we ensuring that competitive bidding processes are more open, ensuring prices fall?
There's a whole body of work on how we create a world-class IT infrastructure in the government. But just as importantly, the role that I held and the role you're starting to see more frequently organized is a position on the policy-making side, ensuring the new initiatives, new laws, new executive actions that are meant to silo problems are sufficiently incorporating the opportunities for open data at the outset. So you need a little bit of a policy adviser with expertise in data, and in combination with an internal focus to ensure the systems you've got are running at full speed. Those combinations are critical to success in professional organizations in the future.
GT: What tangible actions can be done to make the federal procurement process more agile and responsive?
AC:That's a billion dollar question. I would say three things. One, simplification. There's a level of complexity that almost makes you have to have a Ph.D. in procurement physics to navigate on all sides -- from inside the government to make sure you're compliant, and from outside the government knowing you're doing everything right to be fair and open. So simplification has to be an important factor.
Second, I'd have to say it needs to be much, much more transparent. In the wake of the Healthcare.gov circumstance, you realize that task orders and subcontracting often are hidden from public view, and the ability to compete and ensure everyone has a fair shot at serving government almost requires more transparency. And generally speaking, more transparency for understanding the opportunities that truly exist. There's a transparency need for current spending habits and patterns so that we know not just who the prime contractors are, but also who the sub-contractors are and who's ordering tasks and to whom, to where, and why.
Third, I'd say there is a need for alternatives for innovation, whether you call them challenges and prizes or other related vehicles. In the case of innovation, you sometimes know the goal you're trying to accomplish but don't know the specific path to get there. And that's sort of the opposite of a traditional procurement process document where you're supposed to know not only where you're trying to go, but you explicitly list all the requirements that are necessary in how you get there. And then all you're essentially doing is shopping for price quotes to implement the vision as to what it is that you want to do to get there. And that feels contrarian to the truly agile model of government, which is much more to really iterate, learn from the customer, pivot, take those feedback loops and incorporate them into the project.
The original Healthcare.gov that was introduced in 2010 really had that agile approach. We listened to prospective insurance shoppers, built features that they thought would be relevant -- about every 90 days or so, [the developers] released new features in part to new feedback. So there wasn't like a single requirements document. There was a rough consensus running code approach, which is a "let's start building toward the goal" approach and learning and sprinting to the next phase. So that just speaks a lot more to being able to do a lot more work both internally as opposed to externally in terms of establishing new work.