The Best and Hardest Job You’ll Ever Have
A few weeks ago, I had my last day at the United States Digital Service (USDS). Compared to working as a software engineer at a startup in NYC, my time in the federal government was challenging and rewarding in very different ways. Instead of writing code, I helped to make sound technical decisions, to ask vendors for the right things, and to evangelize techniques from industry. While I had a much different set of responsibilities, the two plus years I spent at USDS has been the highlight of my career so far.
I’m sharing the following details about my time at USDS in the hopes that folks in startup and tech companies will consider serving their country or their state at some point in their career…in one way or another.
If you’re not familiar with USDS, it is a group of technologists in the U.S. government that was formed to improve delivery of important digital services to the American people. It was created after the healthcare.gov recovery, and USDS has worked on projects from improving Veteran’s access to healthcare to upgrading Medicare reporting systems to modernizing the immigration system to a bug bounty in the Department of Defense called Hack the Pentagon (see the July 2017 Report to Congress for many more details). As federal government employees, members of USDS are software engineers, designers, product managers, user researchers, procurement specialists, and more that work on some of the toughest problems in government.
The Best
USDS is sometimes called “peace corps for geeks,” and people that join the USDS ranks, typically for a one or two year “tour of duty,” are compassionate, mission driven, and incredibly hard working. I learned so much from my USDS colleagues about essential topics like user research, user-centric design, and getting stuff done. It’s an amazing, diverse group of people that come from all over of the country.
In my two years, I worked with many great colleagues (such as John Evangelist) who have devoted their careers to the federal government. During my work on high profile projects like healthcare.gov in my role at the Centers for Medicare and Medicaid Services (CMS), I worked with Andy Slavitt, Mandy Cohen, and other senior leadership. I greatly value these relationships—through them I learned about the inner workings of the federal government and how to build and operate complex government systems that can withstand the test of time.
In addition to top-notch colleagues, the work at USDS is incredibly important. The team works on projects that do “the greatest good for the greatest number of people in greatest need.” This means, especially with support from the highest levels of leadership in an agency, USDSers are able to have disparate impact on major projects.
The work that my team did at CMS, at the Department for Health and Human Services (HHS), is a great example of disparate impact. You may not realize, but Medicare is the single largest health insurance program in America. It covers over 55 million Americans (over 20% of adults) and accounts for $672.1 billion dollars each year, which is 3.6% of U.S. GDP.
As part of our work on the Quality Payment Program (QPP), we drastically raised the bar for user experience and implemented one of the government’s first, publicly available read/write APIs for healthcare. If you’ve ever tried to share health records between two doctors, you’re well aware that the healthcare industry is very much in need of this kind of modernization. Many doctors participate in Medicare, so they’ve likely (in some way) integrated with this system. Other insurers will look at this, and they’ll ride the wave that the single biggest health payer in the U.S. has created. The QPP APIs could be just the spark needed to really push the industry forward.
Because of the impact of projects like these, if you’re a software developer, product manager, or UX researcher that wants to have a major impact on the U.S. healthcare system, working on the Digital Service team at HHS is one of the best ways to do that. Not only do most clinicians in the U.S. engage with CMS, but many companies and researchers are driving innovation based on the mass of Medicare data. Employees at CMS are at the heart of this data, doing the data plumbing and UX improvements to ensure that researchers and industry partners have the best data to innovate. Further, as systems like those for the Quality Payment Program implement modern UX, tech stacks, and APIs, it raises the bar for broader healthcare industry that accounts for nearly 18% of the U.S. GDP.
Now that’s a job with impact.
The Hardest
There are lots of ways in which working in the federal government is hard. It starts with the simple stuff—there isn’t a single Slack or Google Apps for the entire federal government. In my two years, I was issued five laptops across two agencies, and only one of them was fully capable of modern software development. When we do have nice tools, they’re often a self-hosted version rather than SaaS, which means downtime, “government-friendly customization,” and lots of multi-tenancy issues.
But the tools are just the tip of the iceburg. When you work for USDS, you’re not put on a project to maintain the status quo. You’re there to change things—to convince people there’s a better way. This can lead to conflict (many people are content with the way things are) or miscommunication due to a major terminology gap. Not only does the government have it’s own confusing terms and many acryonyms, but I’ve worked on projects where common industry parlance, like continuous integration, code review, and unit testing, were completely new to nearly everyone.
There are so many problems to solve, that a lot of the challenge is picking the right problems. Anticipating the highest value, highest return investments is a tough skill to learn, but it’s an expertise that a lot of USDSers bring to and develop in their job. For software engineers, this particularly can be a tough call to make—large swaths of software in the federal government are built by vendors. When do you build yourself vs. bring someone else in to do it?
On top of all of this, you’re working in the world’s largest bureaucracy. It’s an environment where any single person can raise a red flag and bring your idea to a hault. With the admirable goal of establishing repeatable and effective processes, government agencies develop IT Governance. Rather than improving efficiency for everyone, this process ends up being designed to accomodate every possible scenario. The resulting policies are a lowest common denominator that typically stifles innovation (one of my favorite examples—the software development lifecycle at HHS has over 50 deliverables like a formal test plan, business process models, and something called a requirements traceability matrix. Skipping some is allowed but must be justified).
Some of these government-wide policies come from good intentions (such as a System of Record Notice and 508 Compliance), but there are lots of policies that I am happy to never deal with again. These include FedRAMP for using a new SaaS product, FIPS 140–2 which governs the crypto implementations (not just algorithms!) you’re allowed to use, and the dreaded Authority To Operate (ATO) that is needed to turn on a new system in government (the audit that accompanies an ATO takes months of prep, includes weeks of interviews, and often costs $100,000 or more. NIST 800–53, which outlines the requirements, is nearly 500 pages long).
How to Succeed
I have some tips for my former colleagues (and hopefully some of you reading this post!) to succeed in this stressful environment.
First, take vacations. It sounds obvious, but I skimped on these. I ended up taking quite a bit of time off in my last six months, without which I likely would have left sooner. I’ve seen many colleagues suffer from this mistake, too. Burn out is real and sneaks up on you.
Second, your job is to bring change, so it’s important to push people. This can lead to uncomfortable confrontation—don’t take it personally. It took me a long while to learn this skill, but it’s important to be coolheaded in order to make progress.
Third, and relatedly, it’s important to push yourself. Get out of your comfort zone—if you’re in a comfortable situation then you’re probably not pushing hard enough.
Fourth, learn to write well. And concisely. A good one-pager laying out the alternatives for a decision can go a long way to getting your point across (and save many hours of meetings). This was one of the most important skills in some of my major accomplishments at USDS.
Fifth, enjoy your time with your colleagues and team. Learn from them as much as you can, both at the job and outside of it. There’s a great community since most people have relocated to DC for USDS, and you can almost always find someone up for rock climbing, brunch, or visiting one of the many Smithsonians. You’ll want to look back on these memories, so as other folks have recommended, take lots of photos!
A call to service
USDSers largely spend one to two years in the government. That means turnover is high, and USDS is always looking for new people (in my two years, I conducted well over 50 interviews!). If you’re the kind of person who isn’t scared of a tough challenge and wants to do important work, then you should consider applying to USDS. The team is working on nonpartisan projects that are incredibly important. And as I said, if you work in healthcare then you’ll have major impact. Shannon, who is the HHS team lead, has written about some of the healthcare projects the team is tackling in 2018.
If moving to Washington DC isn’t on the table, there are lots of other important organizations that need your help. Sixteen states spend over $10,000,000,000 a year on Medicaid whose IT systems costs $4,381,000,000 per year to operate. States and cities are building their own digital service teams, Code for America works on projects at all levels of government, and there are lots of remote-friendly vendors working on USDS projects.
It’s that time of year when lots of people think about changing jobs. Consider doing a tour of duty with one of these great organizations.
