Insights

Healthcare.gov didn’t create the U.S. Digital Service (USDS) — it proved why USDS was necessary. 

For years prior to USDS, people both inside and outside of government were already leveraging technology and design to make government more effective. These efforts included the Consumer Financial Protection Bureau (CFPB), the Federal Communications Commission (FCC), Code for America, the U.K.’s Government Digital Service (GDS), and countless other U.S. government entities. 

The Obama Administration sought to harness these efforts. But by 2012, after three years of putting out policies to build tech and design capacity within government, it became clear that policy actions alone were insufficient. The administration needed people with experience designing and delivering digital products at scale, a capacity the U.S. government didn’t have in-house. It had been almost entirely outsourced, and at several times the cost. By fall 2012, a concept for how to build that in-house capacity coalesced at the White House. 

The Healthcare.gov crisis added momentum, providing a valuable and viable operational model and theory of change. In some ways, the Healthcare.gov rescue served as USDS’s first project. Healthcare.gov also highlighted the structural and organizational obstacles to designing and delivering best-in-class digital technology and services. To prevent similar crises, they focused on root causes to produce meaningful change.

The U.S. Digital Service (USDS) was just one of many teams making government more effective through technology and design. Together, these groups compared notes, built community, and composed a movement. USDS initially drew inspiration from the FCC, CFPB, and the U.K.’s GDS. Over time, the ecosystem in the federal government also included 18F, the Presidential Innovation Fellows, the Technology Transformation Service, the Technology Modernization Fund, and the U.S. Digital Corps.

The U.S. Digital Service (USDS) believed that small, semi-autonomous, cross-functional teams of highly capable experts with top-cover from the highest office in the organization could drive change — not alone, but in partnership with key policy leaders and public servants. This structure was somewhat novel in government. It also enabled USDS teams to work on the front lines of products and services alongside people who rarely communicated directly with leadership. This gave USDS an unvarnished view of the issue, immersing them in the problem space and enabling them to make diagnoses before making recommendations.

The Healthcare.gov crisis (and the ensuing rescue) illuminated the degree to which public policy and digital technology are inextricably entwined. Technology, whether visible or invisible, is essentially a dependency of public policy — if the tech does not work, nothing works. Conversely, technology is a reflection of the policy it is implementing, and the systems and institutions that it is built on. To truly deliver better services to the American people, you need technology and policy working in concert.

Healthcare.gov also illuminated the degree to which technology was entangled with underlying structural and organizational issues. Fixing the technology alone was insufficient — structural and organizational changes were needed, or the problems would persist. Unlike previous government responses to technology crises, those responding to the Healthcare.gov crisis took the time to understand, untangle, and (where possible) address those structural and organizational problems. While engineering skills were important for this work, they weren’t the primary driver of success. Design, relationship building, and the navigating of bureaucracy proved essential.

The U.S. Digital Service (USDS) mission statement in the launch press release read: “To improve and simplify the digital experience that people and businesses have with their government.”

The goal was not focused on the technology alone; it was focused on delivering a better experience. The technology was a vehicle to addressing outdated policies, procurement and hiring issues, and convoluted business processes.

The ultimate priority was an outcome, not an output. For the most part, USDS teams did not arrive with a predetermined intervention in mind. They arrived seeking clarity on a problem, and then helped to identify a path forward to improve a specific outcome.

The focus on outcomes is evident in the approach and values of the organization. USDS projects began with some version of a Discovery Sprint, employed industry-standard practices for building effective digital services, and possessed a shared sense of values.

Two consistent priorities in how the U.S. Digital Service (USDS) approached its work included (1) developing a deep understanding of the problem at hand, and (2) and building trusted relationships with those closest to the issue. These approaches paired well with USDS’s efforts to push the envelope and maintain focus on practical outcomes rather than just technical solutions.

USDS teams worked most closely with the people who had their hands on the technology or the programs, whether they were government employees or contractors. Many interviewees highlighted that their successes would have been impossible without their partners and colleagues in the agencies. These relationships were critical because they allowed USDS teams to gain an informed and holistic view of complex problems before proposing solutions. More often than not, the technology was the easy part – the human element made the real difference.

Hire and empower great people. Find the truth, tell the truth. Go where the work is. Design with people, not for them. Optimize for results, not optics. Create momentum.

These values were a reflection of how the early U.S. Digital Service (USDS) team operated. A decade later, these values continue to surface in USDS language among employees and alumni. That said, how the values are understood and practiced has not been consistent. “Go where the work is” is more recently interpreted as “meet the public servants where they are.” Originally, that value literally meant, “Go to the physical location of a project, be it a conference room in D.C. or an office park in Iowa.”

The U.S. Digital Service (USDS) discovery sprint methodology created a new process for government technology: dedicated time, usually two weeks, for thoroughly understanding the problem before identifying an intervention. That understanding did not come in the form of lengthy research and studies, but in practical, hands-on exploration of problems and direct observation with fellow public servants and other stakeholders. 

This approach allowed teams to immerse themselves in the problem space and develop thorough diagnoses before making recommendations. The tactic carried over from the technology and product worlds that many early USDS staffers came from, and was successful because it included both public servants and “users” – in this case, the American public – in the process.

Read more about USDS’s approach to Discovery Sprints. 

Working side-by-side with peers in government played an outsized role in successes of the U.S. Digital Service (USDS), especially when USDS engineers interfaced with agency or contracted engineers. This approach enabled substantive conversations. It also created a whole greater than the sum of its parts: Technology acumen from USDS and policy, and organizational acumen from long-time public servants. 

Additionally, given USDS’s proximity to the White House, it was at times able to elevate the voices of agency colleagues who were traditionally unable to speak with agency leadership due to rigid hierarchies. In practice, this looked like USDS inviting agency colleagues to meetings with agency leadership. Or, agency colleagues working directly with USDS to take action.

The U.S. Digital Service (USDS) succeeded because of its people, and those people were able to join because of a novel government recruitment process that merged public and private sector approaches. Hiring was identified early on as mission-critical, and even became one of USDS’s values: Hire and Empower Great People. A dedicated team, the USDS Talent Team, was created at the founding of the organization, to find talented individuals and create a pathway for them to join and serve in government.  

USDS applicants were asked to select a primary field of expertise, indicate Veterans status, and had the opportunity to answer open-ended questions. Those primary fields of expertise included: Accessibility, Administrative Support, Artificial Intelligence, Communications, Content Design, UX Writing. Content Strategy, Cybersecurity, Data Science, Information Technology, Operations, Procurement, Product Management, Product Policy, Site Reliability/Production Engineering, Software Engineering, Talent Acquisition, Talent Management, User Experience, User Research, and Visual Design.

The talent team also created the core competencies of a successful USDS staffer across different fields and evaluated all candidates for both TQ (technical quotient) and EQ (emotional quotient), recognizing that how people worked was just as critical as their skills. Recruiters sought senior candidates with multidisciplinary skill sets uncommon in government, and who had the capacity to contribute on day one. Some candidates found USDS through the website, networks, news outlets; others were invited to recruiting events across the country to learn more. 

Implementing this new hiring approach within government required creativity. The USDS hiring team collaborated with and adapted the White House’s rigid hiring protocols and tools, while creating new processes with Office of Personnel Management so people across government could hire — not just USDS. It also collaborated with 18F, Presidential Innovation Fellows, and other organizations hiring from the similar talent pool, opening up entirely new pathways into government.

The U.S. Digital Service (USDS) had a clear vision of creating the most value for the most people – but precisely how to do that was a recurring debate.

Quickly after launching, USDS leadership was pressured to scale rapidly: the White House wanted to scale the organization across the federal government, and hire 200 staff by the end of the administration. This led to challenges familiar to any organization that scales rapidly, from difficulty managing people and priorities to shifting goal lines and expectations. Three tensions in particular proved persistent:

1/ Centralized vs. decentralized power:  As the team grew, there was an increasing need for formal structure. And yet there was also a palpable resistance to anything that felt like a hierarchy.

2/ Firefighting vs. “dev shop”:  A recurring question / debate was whether USDS should be focused on crisis-response, or on the longer-term work of designing and delivering user-facing products, and organizational change.

3/ Long-term vs. short-term: Another recurring question was related to the tenure of employees. Was USDS a place to build a lasting career, or should it be a sabbatical from an existing career?