History and values of 18F

18F stands on the shoulders of giants! These teams paved the way for our existence: the Consumer Financial Protection Bureau, the Office of Personnel Management Lab (focused on user experience, user research, and human-centered design in government), the Sunlight Foundation, Code for America, the Office of Products and Programs (our sister org, which has been around for a decade and runs things like USA.gov), the U.S. CTO's office, and the Presidential Innovation Fellowship.

The hypothesis was simple: the U.S. government could attract talented technologists to the civil service by enticing them with meaty problems and an opportunity for huge impact. The MVP was the Presidential Innovation Fellowship (go say hello to the , external,TTS-only, PIFs), which proved you could get people to give up (or take a break from) their jobs in the private sector to serve a tour of duty in the federal government. The next step was to convince people to serve longer than a six-to-12-month fellowship and join a product delivery team.

Key dates

• 2013: 18F funding approved and hiring begins.
• 2014: 18F creates , external,cloud.gov.
• 2015: 18F creates the , external,U.S. Web Design System (USWDS)
• 2015: 18F joins TTS Solutions.
• 2016: 18F creates , external,login.gov and , external,cloud.gov Pages
• 2016: 18F gets procurement authority.
• 2019: 18F gets assisted acquisition authority.

The Presidential Innovation Fellows

In 2012, the White House established the , external,Presidential Innovation Fellows (PIF) program to bring the principles, values, and practices of the innovation economy into government through the most effective agents of change we know: our people. This highly competitive program pairs talented, diverse technologists and innovators with top civil servants and change-makers working at the highest levels of the federal government to tackle some of our nation’s biggest challenges. These teams of government experts and private-sector doers take a user-centric approach to issues at the intersection of people, processes, products, and policy to achieve lasting impact.

The PIF program is administered as a partnership between the White House Office of Science and Technology Policy (OSTP), the White House Office of Management and Budget (OMB), and the General Services Administration (GSA). In 2013, the PIF program established a permanent home and program office within GSA. Housing PIF inside GSA gave it the resources necessary to grow.

18F: a civic consultancy

18F grew directly out of the PIF program. During the second year of the program there was increasing chatter about wanting to create a permanent team of technologists, and the hypothesis was clearly proven — thousands of people applied for the first two classes of PIFs. But while there was talk of hiring "perma-PIFs" and a lot of talk about trying to create a GDS equivalent (the Government Digital Service in the UK) in the U.S., various bureaucratic hurdles kept getting in the way.

In October of 2013 (during the second class of PIFs), two rather big things happened: a certain government website failed, and the government shut down. There were several of us already chatting and scheming about how we could stay beyond our six-month fellowships, and these two events ramped up those discussions quite a bit. Two critical discoveries happened: we found a budget, and we realized that the PIFs were already GSA employees (which wasn't the case the year before), so extending our employment contracts was easy.

On December 17th eight of us came to work as PIFs and the next day we came to work as GSA employees on an as-yet unnamed team who figured we would be prototyping, continuing fellowship projects, and generally looking for work that would help us move things forward. We partnered with a couple of amazing bureaucracy hackers inside GSA and quickly realized that there was broad support and enthusiasm for our mere existence. :) We were given the latitude to do what we needed to do to grow: to figure out what we needed to work as an agile, user-focused product team inside the government.

We quickly hired a few folks from those organizations mentioned above (specifically CFPB and Sunlight), and we got to work hacking the bureaucracy around the two things we knew we be the ultimate blockers to a team like ours: ​hiring​ and ​deployment​ — we're still working on them! But the team's early work set the stage for our independence in these areas.

GSA officially launched 18F on March 19, 2014. The name is an abbreviation for the intersection of 18th and F Streets in Washington, D.C., where GSA headquarters is located. In March 2014, the 18F team had 15 full-time staff. We grew 10x in the following 18 months! :bow: to , external,TTS-only, Team Talent and , external,TTS-only, Team Ops!

How we fund our work

18F is a cost-recoverable organization. We rely mostly on the following two channels for funding our work:

GSA funds 18F through the Acquisition Services Fund (ASF), which allows for investment in the development and delivery of products and tools that will be used by other agencies on a reimbursable basis.

The Economy Act allows 18F to be reimbursed for services provided to other agencies. Once an agreement is in place, we bill on a quarterly basis through , external,IPACS.

18F is an open source team. We use open source development to transparently promote the security, quality, and modularity of our code, and to invite review, participation, and free and simple reuse of our efforts by government agencies, the business community, and developers.

You can read more about funding and IAA details on 18F’s , external,Intake Information page.

Delivery is the strategy

We launched not only a new team, but also the promise of a new way of working with and for the federal government. The first 15 of us committed to making government services simpler and easier to use — a mission that continues to guide us. We set out to do this by drawing on principles of user-centered design, developing in the open, and incorporating agile and lean development practices.

With our mission and approach established, we rolled up our sleeves and got to work. With each new project that we take on, we know the long tail of our impact will be the education and empowerment we share with our partner agencies. Following in the footsteps of the UK’s Government Digital Service, we’ve been capturing, documenting, and blogging about our process as much as possible — not simply for the purpose of recording our history, but so we can share our process and progress with the public.

“Just Start” was our mantra in the early days of 18F, and we did. Sometimes we stumbled, but each time we practiced what we preach — build, measure, learn, and do it again.

Our values

Like Lean Startup, we favor experimentation, customer feedback, analytics, and iterative design over a sequential “waterfall” model. If startups and companies like General Electric can do it, why not the U.S. government? Our goal with this approach is twofold: build user-centered digital services; and prove that building technology in an agile manner is possible in government at scale. In order to transform how the U.S. government builds and buys digital services, there are several core principles that provide a framework for our team.

• Be the change. We intend to lead by example, by instruction, and with hands-on assistance.
• Think like a designer. We believe that user-centered design can fundamentally change the experience the public has with government. We build only what people really need, nothing more. User needs are the driver for all decisions — not stakeholder or government needs.
• Data-informed. We use metrics and analytics to augment our user research. We measure everything, including ourselves. 18F does more than make websites; we enable the discovery of information. Whenever possible, we think “API first” and lead with data.
• Leverage Agile methodologies. Agile and lean methodologies drive our work. We believe in delivering early and often. We build something small; learn by validating with real people; and “rinse and repeat.” Quick feedback loops with stakeholders mean big failures never happen.
• Open by default. We are open by default: both what we make and how we work. We’re , external,coding and designing in the open; we use and build open source code by default; and we’re evangelizing our methods and practices across the federal government.

Hacking bureaucracy

When asked what it is we do, one quick answer is, “We’re hacking bureaucracy.” While it may sound provocative, it isn’t.

In the movies, hackers are often dangerous criminals who break into large systems, but in the software development community, “hacker” describes the way someone thinks and works rather than a malicious activity — hackers are problem solvers. We consider ourselves hackers in that positive sense: productively disruptive and curious. (See , external,“What is a Hacker?” by Bruce Schneier for a wonderful definition.)

It’s not enough for us to just build software inside the federal government. Such an approach may bring short term gains, but it won’t drive long term positive change. At 18F we’re integrating our style of software development with the many departments and employees of the federal bureaucracy. This is the human platform on which we build our software platforms.

When the founding team first started work, we decided to start with two initial big and challenging projects: improving the efficiency and agility of (1) the hiring process and (2) the software deployment process. Building our “startup” inside the federal bureaucracy meant first integrating with the federal bureaucracy.

Historically, hiring and software deployment practices inside the federal government have posed significant challenges for agile and user-centered software development practices. These processes need to take weeks, not months. 18F is approaching hiring and software deployment in the same agile, open, user-centered way that we approach all of our projects:

• Find innovators inside government who have solved similar problems
• Engage stakeholders and users early and often
• Set up a minimum viable product (MVP) to get started quickly
• Give real users the process/solution from the beginning
• Learn and iterate our approach
• Stay aligned with the rules of the bureaucracy
• Formalize the process/solution for reuse

Those first few bullets are very much in line with lean and agile development methodologies. For successful product development, you need a stakeholder, a client, or a prototypical user for which you can: create an MVP; get real people using it; gather feedback; and iterate the next version. The last two bullets are somewhat unique to being lean inside a very large organization. We’ve learned two things that helped us get traction fast:

1. It’s ok to hack your way around the rules, but you must stay aligned with them.
2. As soon as something works, formalize it and memorialize it for reuse.

Collaboratively, we’ve significantly improved turnaround times for hiring and secure deployments. We’ve reduced the time to hire by 70%, and the time to deploy software by 80%, and many of our products are now in continuous deployment. Despite the constraints of the federal bureaucracy, continuous iterative improvement is possible. These processes and policies are now being formalized and we intend to make them repeatable and useful to the rest of the federal government.