US Digital Service is Born

Yesterday, the White House announced the formation of the US Digital Service, a cadre of technology sherpas meant to inject more modern commercial practices into government IT, especially the development of websites and mobile applications. It’s obviously inspired by the Government Digital Service, a similar effort in the UK, and the early success of the GSA’s 18F team.

With the announcement, OMB also produced a very readable Playbook, which demonstrates with tenets and checklists what kind of IT the USDS is meant to promote. To my delight, it calls out open source1, open data, agile procurement, automated testing, and all the other tools the most interesting commercial IT projects have already embraced. Because everyone knows no reform survives first contact with the FAR, they’ve also released a very smart TechFAR, which provides the interpretations necessary to get the contracting officers on board. Clearly, a lot of thought has gone into this.

There should be plenty written about the likelihood of USDS effecting real change in government programs. I’m eager to hear, for instance, what the Professional Services Council thinks of what I can only assume they understand as a bold incursion on their turf. I’m eager to hear from the pockets of innovation that already exist in government, and whether they think this effort will help them, or take all the oxygen from their work. While I wait for the punditry engine to spin up, I’m thinking about the assumptions built into this effort.

Neither the sudden shock of battle, nor the long-drawn trials of vigilance and exertion will wear us down. Give us the tools, and we will finish the job.   – Winston Churchill, February 9, 1941

If you’re creating a corps of talent that understands agile development, microservice architectures, and building for modern infrastructure, you’ve tacitly admitted that you don’t have sufficient talent at your disposal today. That’s mildly embarrassing to government agencies, but it’s a catastrophic defeat for those selling services to the government. It’s a defeat they’ve deserved; there is precious little talent available for this kind of work, and even less expertise. This is, in part, because anyone who can do this work properly has long since defected to the private sector. The unanswered question is why, with these critical missions and enormous budgets, the US government can’t command the interest of the talent it so desperately needs? It’s not clear to me why hiring its own pool of SMEs will solve this problem.

The formation of USDS also assumes that agencies are already sufficiently motivated to do this work in the first place, and simply lack the means. For all the ink spilled on healthcare.gov and the F-35, most of the innovation to date has been devoted to risk mitigation. That’s made programs less interested in new approaches, not more. If we imagine USDS as a vendor, it will be interesting to see who’s buying.

The fact of the USDS, and that it’s housed in OMB, is also interesting. Instead of having one central team, the CIO could have asked for a number of teams, each housed in a different agency and given them a mandate to experiment. Instead of creating a new team from scratch, it might have been easier to double-down on GSA’s 18F and expand their scope. After all, it’s very much in line with GSA’s mission to provide this kind of service. On the other hand, housing USDS inside OMB certainly gives it more juice, and brings it closer to the CIO’s office. Maybe it’s helpful to think about this as an “Innovation Office,” which means to drive new approaches inside the organization. That kind of thing is very common for a CTO’s office, and in retrospect is conspicuous by its absence in Van Roekel’s organization.

The TechFAR is probably worth a blog post all by itself. Until then, the existence of TechFAR implicitly endorses what industry has been saying for quite some time: the rules are fine as they are. This is a surprise, since you can’t spend five minutes with someone in government IT without a sarcastic remark about procurement. With TechFAR, OMB has spoken: We can make do with the acquisition tools we have. Reinterpretation and new guidance will get us where we need to go.

But the questions of talent, agency appetite for change, procurement reform, and the bureaucratic home are all implementation details. The really interesting questions come when you put the USDS is the context of the Federal IT strategy and a longer-term vision for what government IT should be. Here, I’m hard-pressed, because I’m not really sure how the USDS is meant to succeed. Is it designed to accrete web and mobile projects over time, as the UK’s GDS has done? Is it meant to be a kind of consultancy to other groups, making them more successful? Since it’s led by one of the saviors of healthcare.gov, will it become a team of firefighters, rescuing faltering websites? Once we understand that, how will USDS serve the tactical goals of cloud first, shared first, and the FDCCI? How will we know that it’s doing a better job than a private contractor? How will we know it’s better than publishing the Playbook and TechFAR alone? There’s a lot to be learned from the UK’s experience with this, and Mark Thompson has leveled some very important questions at GDS which apply just as easily to the USDS. I encourage you to read it.

Yes, it’s early days, and I’m embarrassed at my reactionary response. I am enthusiastic for the US Digital Service, and it feels intuitively like what government IT needs. Still, it’s creating far more questions for me than answers.

1-Although they do refer to open source as non-commercial, which grieves me. Open source is commercial software, and has been since the OMB memo of 2004. [Update: Daniel Morgan was good enough to file a PR for the problem. Thanks!]