a16z Podcast - a16z Podcast: On Government as Software Builder, Not Just Buyer

Episode Date: July 14, 2016

We already know that the government is one of the largest IT buyers, but in many ways it is also an IT builder. Especially for areas where the government is doing something that no one else is doing, like running Medicare and Social Security -- i.e., unique services no other company out there is building software for. That's where the USDS comes in. Now almost two years old, the United States Digital Services is "a startup at the White House" responsible for mission-critical, citizen-facing services like improving Veterans' Affairs healthcare applications and benefit claims appeals, or student loan repayments. But can one really operate as a startup while embedded in an entity as complex and huge -- remember, each agency would be like a Fortune 500 company -- as government? It may not be move fast and break things, observes Mikey Dickerson, Google engineer-turned-administrator of the USDS (and one of the fixers of the original healthcare.gov), but "There's a world of difference between moving a little slower than you're used to and not moving at all." And it's not like large companies don't have huge, bureaucratic structures either. In fact, argues USDS co-founder and deputy administrator Haley Van Dyck, both government and big companies are going through the same shift right now, one where technology is moving "from what used to be the periphery into the core mission of business". So what are the similarities and differences between operating in government vs. big companies? How to draw talent from the private sector into the public sector while avoiding adverse selection (hint: through tours of duty)? And finally, what about fixing the procurement process (because "you don't buy software the same way you would buy a battleship")? Dickerson and Van Dyck share their thoughts on these issues, as well as peacetime/wartime tactics, in this episode of the a16z Podcast.

Hi, everyone. Welcome to the A6 and Z podcast. I'm Sonal and I have two special guests from the USDA, or the U.S. Digital Services, continuing our DC on the road theme. For those of you that may remember some of the fiascos with the original healthcare.gov, this is a group that came in and fixed it. And more importantly, has been working on many other services since then. The two guests we have today are Mikey, who is the administrator of the USDS. And before that, he was an engineering manager at Google for a number of years. And Haley, who is a deputy administrator at the USDS. She's been working to help implement some of President Obama's key technology initiatives during his administration. So Haley and Mikey, welcome you guys. Thank you for

having us. Thanks. Yeah. Well, I'm excited to have you guys because the government is like the biggest buyer of IT services. And then on the flip side of this, we have this idea that you can have a startup inside the government. And so there's just interesting tension between this idea of the government as a buyer and the government as a builder. And you guys, are sort of sitting at the heart of that. Yeah. Well, just to start with how we operate, so we are essentially a startup that's embedded inside the White House

and as part of a team of teams working across government to help improve some of the core citizen-facing services of the United States government. We bring in some of the best minds from the private sector and set up tours of duty where people can come in and help apply those same best practices and skill sets to improve the fundamental services our country provides. I think it's interesting that you referenced that as a sort of a tour of duty because one of the complaints that I've heard, you know, we have a lot of government folks that come in through our doors is that it's really hard to attract top talent to work in government because they would rather be at a startup or, you know, a company like a Facebook or a Google or an Amazon, Apple. And so this idea of a tour of duty is really interesting because what I was wondering is if you actually have an adverse selection problem where the very people you want to attract don't want to go there and the people you don't want to attract are the ones that do and how you

find yourselves resolving this to attract the top talent? Yeah, it's a great question. When we first started USDA, we had a big question, which was, were we going to be able to attract any top talent to come? I believe the reason why the tour of duty model is working so well is one very fundamental reason, and that is the mission. We offer a huge opportunity to have impact on things that really deeply matter in the lives of Americans, and that is our comparative advantage. And you hear often around the you know the valley and startups the the interest in wanting to have impact in human's lives yeah it's funny that you bring up the adverse selection problem i talk about i talk about it exactly that way quite a bit we don't encourage people to think they're going to uh advance their

own career in any particular way the recruiting pitch we give is is very non-intuitive we set people's expectations that it's going to be very hard and hopefully in that way it makes it much more likely that we're going to get the right kind of person that we need. And it also makes it much easier to manage after they're here. If they, if they've only been promised that they're going to have an opportunity to work on something important, that is a promise we can deliver. What exactly are they working on? If these folks are motivated to have this impact, but yet have been exposed to a very different environment of getting shit done, for lack of a better phrase, how do they sort of deal with navigating there? It seems like any large entity, forget

even the U.S. government, large corporations and enterprises are like this. There's multiple stakeholders. There's lots of inputs. You have decision by committee in some cases. How do you guys operate in a startup like way? It's tricky, as you say. There's definitely a different environment. When you're working on something that's critical to hundreds of millions of people, you know, tax filing, social security, anything like this, that it's not going to be Facebook style, move fast and break everything. And we try to minimize that effect by focusing USDS on projects that of very high urgency and very important to the leadership that we're working with because government can move fast when it wants to or when it needs to.

So when it's urgent, basically, is what you're saying. That's right. You mentioned the healthcare.gov story, and I was part of the group that worked on that. And we got a tremendous number of things done in the space of a very short amount of time, six, eight weeks or so, because it was mission critical. And it was incredibly important and everybody in the whole organization knew that. And when we have those conditions, we can get things done. There's a world of difference between moving a little slower than you're used to and not moving at all. What are some of the similarities between, say, you know, a regular enterprise and government? Is it like every large organization or are there like other differences?

One of the thing that's funny to me about government is, is people feel like bureaucracy is, you know, patented by government and that other large companies don't have huge bureaucratic structures. As a result, there are a lot of similarities between how you would operate in the private sector and here. And a lot of the things that we have gone back to as the proven method for creating change is keeping very, very small teams and having them hyper-focused on a specific mission and then doing what they do best, which is bringing in a lot of the best practices from the private sector, the things that everyone knows is second nature, agile development and bringing them into government where they are not second nature.

Most of the challenges of trying to organize a large, large group of people and get them to get something done and move, those are exactly the same. It wasn't different at Google if you have a thousand engineers and not a good decision-making mechanism and they're not going to agree on how to do things. Big companies are struggling to move into shared services, cloud hosting, off of main frames. Like, there's a lot of industries that are in exactly that place today, and that's a lot of government agencies as well. And the mechanisms that work best that Haley just pointed out, one that we get the best results with is a small group of very capable and empowered people. And that works,

that works the same in the private sector or the public sector in my experience. Yeah, it's actually almost like the tension between small companies and big companies, but all in one place. I can see now why you guys would call yourself a startup inside government, just like a startup going into a big company. And some of the similarities you describe, you know, small teams, shared mission, agile, you know, the urgency, all these factors are very startup-like. The difference, however, and I think this is an important one to bring up, is that when you are, you know, a big company, you have repeat customers. And you guys are essentially working across very different, you know, stakeholders every time. You have like sort of a repeated knowledge that then builds up that you can

carry across because it's so different with every group, I would imagine. You know, it's funny looking at government from the outside in. It's easy to think of it as kind of one single entity or something that operates similar to a company, but in reality, it's a gigantic, massive industry. Each of the agencies and the federal government, if you peel them out into the private sector, would be larger than most Fortune 500 companies. So it's a huge space that we're operating in. So yes, we do have very many different customers or two partners that we work with. But at the end of the day, it's very easy to stay focused on the same consistent stakeholder, which is the end user or the citizen or the beneficiary of the service that we're trying to improve. And that relentless focus, whether it's a

veteran that we're trying to get better access to benefits or someone who are trying to improve getting access to student loans, it's very easy to stay focused on that common user. And a lot of the tactics end up becoming the same across various parts of government, various agencies. To the extent we have principles that we feel are near universally useful, a bunch of those we put into the playbook, they're pretty high-level things. They're like, I think, number one, One is, like, have one person in charge who is going to have the ability to make decisions across the program. And another one is, you know, pay attention to what the end users actually want.

They're so high level that they're nearly platitudes, but, like, you cannot take them for granted in any big project here or in the private sector. People is amazing how often big groups people lose sight of what the thing is they were trying to actually do in the first place. Well, share some examples with me. I mean, I think some of the most, I find most personally interesting are the example. examples of the work you guys did for veterans, services, and student loans. Those are two important constituencies that are often overlooked.

Those are two great examples. We helped create a product called the College Scorecard, which lets people search for information about earnings after graduation and other stuff that's relevant to what college you might want to go to. There are a lot of ideas. Education policy, it gets complicated fast, as you might imagine, and we helped bring some direct feedback. back from the target audience. So we had user researchers talk to high school students. And so just to pause on that for a moment that feels so obvious to a Silicon Valley startup and how they operate or test products. It's not something you can assume is going to happen out here. Maybe I was just too far away from it in the companies I worked in the private sector,

but it was not a thing I could take for granted there either. I mean, there's also kind of a counter narrative of like the hero product visionary, right? Like, I mean, I don't think I've ever read stories of Steve Jobs like going and asking high school kids about the iPhone. Like it's just, we just assume that he knows everything there is to know. You're right. And yet there's this truth as well, despite whatever the biographies say that there was also a tremendous amount of work that happened beneath the surface that wasn't all just about only his vision and how they execute it on it. So it's a really great point. Yeah. I think you can't take it for granted anywhere. And it's, and it's worth writing down and reminding people, reminding whole teams from time to time

that like, okay, we've iterated this design eight times now. Did we ever at any point go back and ask the high school students, are they ever going to use the search feature? So it's interesting because you know there's this movement in usability and user testing where there's sometimes a tension between asking people don't actually do what they say, watch what they do. How do you resolve that one? My core field is engineering, so I won't pretend to be an expert at this, but I've only ever seen that work by doing the direct observation.

It's exactly, as you say, like it does not work. I mean, everybody has their favorite aphorisms. There's like Henry Ford saying if I'd ask people what they wanted, they would have said faster horses, right? Right. And by the way, there was a funny HBO article a few years ago that actually debunk that he's even the one who said that, but I think the point remains valid. And that is a very widely cited quote. Whoever it was that said it, I agree. It absolutely doesn't work to ask people

what kinds of, like, in the case of the Veterans Employment Center, Veterans Healthcare Application, facilities locator, all these types of things that are services that we need to work well for a large number of very diverse people with different needs, it doesn't work to ask a group of people in a conference room, what features they would use. You have to go and watch them, and it's much better to go where they are and watch them in their own environment. We learned crazy stuff.

There was a, we've done some user research with the veterans where our researcher came back and said, like, her mind was blown that this guy was trying to operate the VA website with his laptop, like, balanced on an ottoman, like with one hand, and

like kept dropping a laptop on the floor and like reloading the page. He was only operating it with one hand, and he's having a hard time. And that's probably not a use case that we would have thought of if we just sat around and brainstorm. The focus on the user is just so critical to everything we do. And at our work at the VA, it's very, very apparent. So if you look at the user experience from a vet's perspective, today there's hundreds of different call-in numbers that you can call in to get help and thousands of different websites that you can go to, which is unfortunate because that's not an ideal scenario in terms of providing services for veterans. Our team

is building an integrated experience that's easier for vets to find access to the benefits and services that they are looking for. Instead of just thinking about what that might be, we actually went out into the field and did a lot of work with veterans to figure out which were the services they were looking for the most to start with those in a very agile and iterative fashion. We wanted to start releasing, you know, streamlined services quickly instead of waiting to redo all of them. So we did a bunch of user research with vets and realized that the services they were looking for the most were education benefits and disability benefit. But another user experience piece of this is not presupposing where the fix is going to be.

So when our team started working really closely with our agency partners there, we realized unexpectedly that one part of the problem that could actually help improve vets getting their benefits was actually working on improving the tools that the VA employees themselves were using, which was obviously not a problem we went into the VA focused on. We released a new service called Caseflow, which is a new tool to actually help the government adjudicators themselves more efficiently process applications and do their job more easily. Yeah. Caseflow is a good example because it is not a flashy website. When we started digging into those claims, this is disability claims process inside the VA. The biggest and the greatest impact we could have there was really to just speed up the internal workings of the VA from the time the claim is. submitted to when it's adjudicated or when the appeal is adjudicated. Those are products that we're

pretty proud of that nobody's ever going to see a magazine or anything because it's not glamorous like that. But it has a potential to take months or years off of the time that the people are waiting for their disability benefits. That's hugely important. It's something that impacts human lives in a very real way. I'm going to ask you guys a tough question, though, which is going back to this tension between government as buyer and government as builder. And I think It's interesting because you guys are navigating that by being the startup inside government. But the question I can't help but ask is that, so what was the incentive for creating this model in the first place? Why wouldn't they just then just outsource the work to a bunch of different agencies who maybe are startups outside the government?

So outsourced to contractors. Right, exactly. We are always trying to optimize for what's going to serve the citizens, the customers, whoever the service is meant for the best in the fastest, in the shortest amount of time for the, most reasonable amount of money that we can put into it from the government. Most of the time, for any project that's any non-trivial size, there's already a team in place. And the best use of our people that we bring into the government is to work with that team and help them. Sometimes it's a matter of applying some best practices that they may be a little bit less familiar with. A lot of times, it's just a matter of being able to traverse boundaries and improve communications.

between different parts the organization. Honestly, that is the main service we're providing an awful lot of the time. I've been on a few intense web projects, and one of the things that I learned very early on is that these projects are actually proxies for the organizational dynamics at play, and it's when you get down to actually building something that you really begin to see, like the whims of people, the psychology of organizations.

And it's funny because you can't use technology to solve that necessarily, although it can be a driver to facilitate those very conversations that you're describing. There's this concept of Conway's law which tells us that organizations always build systems which match the shape of the organization and vice versa. So then the question I have is we had a podcast earlier with Teresa Carlson from AWS for public sector and nonprofit and international. And one of the things that, you know, she talked about is that in having these conversations with certain stakeholders, you're having to explain a lot of basic concepts because they're not necessarily tech savvy from the get-go. And that's true, both inside and outside

government. But what do you find, especially with repeat folks or other people you talk to in a regular basis, do people change in how they react as a result of these projects? I think that the place that government is in right now very much mirrors a lot of what we see big companies going through, where essentially we're removing technology from around what used to be the periphery into the core mission of business and what we do. So one example, one of our agencies, we were explaining to them the concept of user testing and how and why we make product decisions. based off of the feedback we got from users. And you saw all these light bulbs go off

that we could also be user testing policy development as well. We didn't just have to apply these practices to building applications. This could be applied to anything. So, yeah, it's been really fun to kind of watch how this culture has kind of taken root in a lot of places that we weren't expecting. One nuance I would add is,

I have seen some really positive second order effects from executives learning what is possible just what their expectations should be or could be. Like, I don't, we don't need cabinet secretaries to know how to, like, run a, you know, scrum process or something. They have, they have other stuff to do. But it is incredibly valuable for them to just have, like, a ballpark idea that you started the question asking about AWS, just the fact that it exists and you can do small things

for small amounts of money instead of there being, like, a baseline floor cost of setting up a data center for, you know, tens of millions of dollars. every time, which is kind of what they're used to from these enterprise-style projects. Just knowing that it can be done goes a long way. Yeah, I think that's the front line of the kind of culture change that we're at right now. So, you know, one of the things that I am curious about, again, going back to this notion of government as buyer and government as builder. And one of the things that we're obviously very interested in is government as buyer,

because they are, as I mentioned, one of the largest buyers of technology, and there are a lot of startups that sell to government. And one of the stories I heard from one startup, not one of ours, was that it can take up to four years to get something bought. And it just shed light on this idea that procurement itself as a process can be such a long-winded thing. You'd love to get your take on how that works and from where you sit. The government finds itself in these situations where by the time the process is finished, the thing that you're buying is already out of date or doesn't serve the needs anymore. It has to be faster. And competition in that marketplace needs to be more

effective, which is a combination of lowering the barriers to entry and doing a better job with the management of it all. To be clear, we, like most people doing government work, like we're always in favor of buying if that's an option. Oh, that's good to hear. For things that you can just easily buy off the shelf, like 100%, just there's no need to reinvent email this year. Right, exactly. You know, like our needs and the government are really not different from everybody else in that respect. There are occasional places. We end up in the build a role where the government is doing something that nobody else does. There's nobody else running Medicare. There's nobody else running Social Security. So there's going to be some

stuff where there's no choice but for government to strike out and do something that hasn't been done before. So that procurement work is really the long-term goal. And two years that we've been here, we have put a decent amount of effort into it. We see strides happening in the right direction. Yeah, you don't buy software the same way you would buy a battleship. So one of the programs that USTS has worked on setting up is this contractor training program, which is actually focused on helping improve the literacy of contracting officers and how to buy software and things that it wasn't trained to buy, you know, as a government several decades ago. So it's, I guess, you know, to wrap up. One last question I have is, you know, Ben wrote a really

popular blog post a couple of years ago about the notion of a wartime versus. is the peacetime CEO. And I love it because it actually goes off one of my favorite movies, The Godfather, where there's a wartime and peacetime conciliary. Yeah, right? And anyway, how does that play out for you guys? Because it feels like you're actually in both at the same time. Some organizations can take turns as being in a wartime, peacetime phase, even though there may be some overlap. Yeah, that's right. People sometimes want to think of the government as a business when it's actually like an entire sector of the economy of its own. So as you say, we do not get the luxury of, is this a wartime period or is this a peace time period? Obviously,

the government has wars. But like in the context of this metaphor, it's always both in different parts of the government in different times. I think that's organizationally one of the things that's been hardest and I think also one of our strong suits is that we are able to kind of do both the peacetime and wartime CEO together. On one hand, where we function at our best is often responding to very urgent, very, you know, important needs that have short deadlines and really need to kind of lean on a lot of the wartime CEO tactics to be effective. On the other hand, we are setting up a team of teams, this network of innovators across government that needs the nourishing and attention that you often find in more peacetime CEOs to make

sure that that culture can cultivate and be strong enough to continue to create change and provide a platform for doing this across government and for the next several years to come. So we have to sort of switch between the two very fluidly depending on what context we're in. The article really spoke to us in a few ways. It's maybe not an accident that since I have been here, the only organizational management type strategy theory reading I have done that has really felt like it had anything to say that was any use to me is very old stuff from the 1940s, 50s, and 60s. Oh, interesting. I don't read hardly anything, you know, in the like management section. that feels like it's anything but empty platitudes.

There's a RAND report from like 1965 by Anthony Downs, and it became like foundation for a lot of social science and sociology that followed. The U.S. had just come through World War II, had just completed the Manhattan Project, had launched the Apollo project, and was building like the space program, the nuclear industry, and the military, as we know it today. And they had just gotten these things done

under an existential threat. Like, you want urgency. There's no more urgent situation than, like, the United States, 1944. And they were not screwing around. And they captured a decent amount at that time of the knowledge that we still need today in order to actually get things done with any urgency.

That's great. All right. I would be remissed if we didn't close on the shameless plug that the United States Digital Service is obviously in dire need of additional people to come join our team and help us on these important missions. Ted and Penny Pritzker, they did a podcast a couple weeks ago. They are also advocating for this concept of tours of duty.

Like, look, you know, no one expects anyone to stay in any one place, let alone government or a startup or a company for, you know, 20 years. And so it's perfectly fine to have this model because it's a way that you can actually attract people, but it's also sort of like a sabbatical. It's kind of the opposite of a sabbatical. It's a sabbatical for a certain type of people who like to work really, really, really hard on important missions. I think sabbatical, of course, has the etymological origin of something like a day of rest concept.

But what I mean it is in the academic sense where it's actually a time when you can work on a project that's really important to you, a passion project, some work, a book, something new. And to your point, like if this is a mission that people want to support. Yeah, we, you use the word like tradition of public service, which I think is fantastic phrasing. You look at the even the legal field or medicine. And it's very common for people to take little sabbaticals or do tours of duty. from the private sector and help fulfill this mission of public service. And that's what we're really hoping to create in the tech industry, recognizing that there hasn't been a strong tradition of that in recent history.

And that's what we're trying to cultivate here. Well, I just want to say thank you, Haley, and Mikey for joining the A6 and Z podcast. Thanks so much for having us. Thank you for having us.