From Google To Government: Diving Into The US Digital Service With Eric Hysen
Last week Wellington’s Open Source Open Society (OS//OS) conference featured a keynote address from Eric Hysen, Executive Director of the United States Digital Service at the Department of Homeland Security. He spoke about his efforts over the past two years injecting startup technology, design and culture into the US Government.
I sat down with Eric at the Biz Dojo in Wellington to chat about his experiences within President Obama’s much discussed “Government Startup”, what the most surprising thing has been in the leap from Silicon Valley to Washington DC, and what New Zealand can learn from his journey.
(Also check out our reporting live from OS//OS for a taste of the conference)
What was it that motivated you to join the US Digital Service?
I was working at Google, it was my first job out of college. I worked there for several years, and loved the culture, loved the type of work we were doing.
And then healthcare.gov happened. It was a situation where one of the President’s major policy initiatives to expand access to health care in the country had passed politically, and yet the website failed. It had taken so long to build, and was out of date by the time they launched. People were faced with dozens of error messages, and as a result risked not being able to get health care.
So I joined as one of the first people that came into Government to create the U.S. Digital Service to make sure something like that wouldn’t happen again.
How would you summarise the problems that you are trying to solve within your work?
Ultimately we’re charged with transforming the Government’s most critical services through technology.
My chunk of that is the Department of Homeland Security, which sounds a lot more intimidating than it is. And that means that we’re looking at digitising our immigration system, facilitating international trade and improving how we admit refugees into the United States.
You spoke at OS//OS talk about introducing agile software development concepts into Government. Before we get into how you go about that, how would you explain agile software development to someone who is totally unfamiliar with it?
You guys have Lego here right?
Indeed we do…
Okay, so imagine that you have your Lego blocks and you are trying to build a Lego house, and you don’t have the instructions with you because this is your own creation.
One approach you might take if you’re trying to build that house with Legos, is that you might write out the instructions piece by piece before you touch any of the bricks, and try to figure out exactly what’s going to work. And then you build it once you wrote out all the instructions. And that’s really what we call waterfall software development: that you start with one stage, move to the next, and move to the next.
But with the concept of agile development, instead you’re actually playing with the Legos the entire time. You might first build out the door, you might then build out one room, and maybe you’ll write up the instructions as you go so that someone else can build it. But you always have your hands on and you’re always playing and seeing what you get to.
So fundamentally, the agile model means that instead of planning out everything you’re going to build in a minute detail, you build something that adds value. That is what we call a minimum viable product in the tech world. You build something that is useful like one room of the house and then you’ll keep repeating that over and over again. So you might know that you’re moving towards a house overall, but you might not know exactly where the bed is going to be positioned in each bedroom - versus thinking that you need to plan everything out all the way in advance.
So how do you balance that kind of approach of learning as you go, and adding things as you go, with working within the constraints of a Government system with high levels of regulation and oversight?
Achieving the balance is most of what we spend our time doing. The Government is geared around reducing risk. And that’s a good thing. Governments should be responsible with public money. We shouldn’t go willy-nilly spending it just because we think something is cool. But the idea that it is less risky to plan out a giant software project in advance, and assume that everything is going to go exactly as planned, is just wrong and outdated.
So what we’re trying to do is say it’s actually less risky to start small, to plan less and deliver faster. You might have more failures, but they’ll be small failures, rather than these giant programs that fail after investing hundreds of millions of dollars into them.
Let’s talk a little bit about people. People often have very high expectations of Government departments. How are you finding it dealing with a user base that perhaps is less forgiving than they would be if they were dealing with a software company?
What we have found is that being transparent, saying upfront that this is a beta launch, that’s it’s still early, or asking people for their feedback, changes that relationship.
In some areas we have certainly not been able to take as many risks as a private company. If you’re filing your taxes, we can’t lose your money or fail to keep proper records just because we’re trying out a new system. That’s not excusable. So we have to be a little more careful. But in many areas we’re improving upon, there is still the ability to explain what we’re doing, work with people and bring them into the process, rather than delivering one giant finished product at the end.
Looking at this from a user experience perspective, you must be dealing with a wide customer base with differing needs. How do you approach user experience design when your users are so widespread?
Most of it is through a very standard process of research and design - starting by actually talking to our users, and coming up with different personas that can embody the very broad spectrum of people that use government services. In doing that we are able to make sure that we are designing for people that may not have access to the Internet, that may not speak English as their primary language.
It’s also been interesting to note that the Government employees, the Civil Servants that we’ve been working with, are often some of the first people to point this out to us. That’s one of the great things about working with them, is that they really do know and care about the people that are using their services. They will know, for example, that designing an interface on a tablet to sign your immigration certificate after your interview might appeal to those of us that go into coffee shops where they’re turning around the square tablets to you all the time, but could be very intimidating to someone who has never interacted with technology in that way before. We need to be able to bring them along with us.
Within two years, you have digitised one third of the immigration process, compared with a 1% digitisation in the previous seven years. Are you seeing ripples of learning going out to other Government Departments that have also traditionally been quite paper heavy?
Oh yeah. Once you prove that something can work in the Government there are a whole host of people that rush to follow on. The harder part is doing that first proof. The Digital Services Playbook acts as a blueprint to help other departments.
They’re shocked because it involves Government contractors sitting next to the Government employees talking constantly, not just handing down requirements and expecting them to be delivered. They are then able to bring that back to their own projects and try the same things there.
What has been the most challenging thing for you to transfer over from a private sector technology company to government?
I thought it would be all the perks, that it would be not having free lunch, not having a kegerator in the office, or not being able to just flop down in a bean bag chair. But that’s all been really blown away by the biggest challenge; it is really the culture.
It’s a very different type of place to work from the tech world.
Dealing with that culture shift was a big thing to overcome - just being able to realise that it wasn’t that way because government employees don’t want to do good work, but because in many cases the system is setup to make that incredibly difficult. So it became a challenge to me and many of us in our team to be able to try to change that culture. Not just for us, but to really empower those people that had been doing this for decades and may not have had this opportunity before.
What has been most surprising?
The amount of paper. I think I saw more paper in my first week in the Government than I had seen in my entire life up to that point. I don’t actually think I’m exaggerating on that. It sounds like hyperbole but it’s not. It’s such a different visual and physical environment, carrying around a bag and realising suddenly I had a back issue because I was carrying around too much paper every day. That was the biggest shock to overcome for sure.
What are the most valuable lessons that you’ve learned along the way?
No one goes into government service because they want the pay cheque or they want an easy job. They go in because they care about the people that they’re serving. Being able to partner with people that care that much has been incredibly valuable and incredibly rewarding.
You’ve been in New Zealand a few days; you’ve spent two days at the OS//OS conference. Any reflections from the conference you’d like to share?
I love what I’ve seen here so far. It feels to me like Wellington, and New Zealand more broadly, just has this amazing tight knit culture among groups that would be very fragmented in the States.
In the US we might have three different open government accelerators that all have slightly different focuses and are all over subscribed. I just came from Creative HQ and saw this amazing mix of commercial startups and people trying to do work with the Government. I think that’s actually a really huge strength being able to bring people together in that way.
That leads nicely into my next question which is a two-part question: What do you think NZ can learn from the U.S. Digital Service?; and then in what ways do you think we have an advantage or a good starting point already?
More of the latter for sure. So far I’ve seen here a lot of really great collaborations with government and the private sector. I think just the community here and the fact that you’re not so isolated from each other.
In the States we your creative, innovative industries on the West Coast with Silicon Valley, San Francisco and LA, and then on the East Coast you have the financial sector in New York and government in Washington DC, and they’re separated by six hours of flight. It’s generally much harder to connect with different communities and be able to bring different people together.
I think one of the more unique things that we’ve done at USDS is bring technical folks directly into the government to be able to work at it from the inside out. I think you need both government and private sector to be able to really transform how things work.
Do you see any disadvantages in NZ for this kind of model?
I have definitely heard from folks so far that have said that there is a need for more technical talent across the board, and a number of folks are talking about ways to attract more tech talent into the country. That’s certainly been something that has not been a challenge for us. We’re focused on getting people to move across the country, but fundamentally they’re already there. So from some of my conversations so far, that is a different focus for sure.
Will you be back to NZ?
I hope so.