I’ve been an employee of the United States Government for a quarter of a year now (1/8 of my 2-year term with 18F), and it’s been a fascinating adventure. There have been plenty of opportunities to apply what I learned about building great software at Microsoft, and lots of new lessons as well.
The government is gigantic
Did you know that nearly 3 million people work for the US federal government? Because I sure didn’t — I learned it while working on a short project with the Office of Personnel Management, the agency that serves as HR for the entire government.
My view of the government was laughably incomplete: I thought of the government only in terms of Congress and the President. Sure, I was vaguely aware of high-profile agencies like the FBI and EPA and US Postal Service, but I never really internalized them as being part of the government.
As it turns out, the US government is yet another iceberg made up of a mix of elected politicians, political appointees, and career feds. (this, of course, is a dramatic oversimplification)
Politicians have a lot of visibility. They’re the ones making speeches and writing laws. Political appointees are (comparably) short-term employees who occupy positions of leadership and influence for a few years before leaving as the politics upstairs shift. Career feds keep things running day-to-day, implementing law and policy. There’s a special breed of leadership aimed purely at buffering career feds from the churn generated by politicians and their appointees.
This is necessary because…
The government has a lot of rules
200 years of organically grown policy ends up being a bit complicated. Wherever you work within the government there are thousands, if not millions, of pieces of policy that affect your daily work. I’ve yet to meet anyone who actually knows all of the policy that they’re beholden to, let alone what type of policy it is (did you know that there are types of policy? I didn’t!) and what its origins are. It’s a delicate ecosystem that works — as long as you don’t unravel threads before fully understanding them.
You can probably imagine that this mixes interestingly with a system where agency leaders are political appointees. It’s easy for outsiders to join an agency, identify things they want to change, and make sweeping recommendations that have unintended consequences to the entire organization. As a defense mechanism, agencies have grown a layer of management to manage upwards and insulate on-the-ground workers from change. This is crucial when leadership is unknowingly steering the organization in a destructive direction — and incredibly frustrating when the proposed changes would actually benefit the agency and the American people.
A lot of government tech work is done by vendors, not federal employees
The government has a hard time hiring tech talent. Work is concentrated in Washington, DC, away from major tech centers in the US. The organizations aren’t tech-focused, which makes it harder for technologists to envision a growth path for themselves. The pay rates, limited by law, aren’t competitive with private industry (especially for senior level employees). Federal employment rewards long-term commitment to the job, and the best benefits federal employment dissipate when you’re only around for a few years.
This leads to a dependence on outside vendors to implement technical work. As a result…
Strong product management is critical
I’ll admit I have a personal bias here, but it’s also been confirmed by folks from other disciplines: government needs good product managers.
Policy workers have a great sense of what needs to happen and why, but they don’t necessarily have experience articulating it clearly. In an environment where everything has to get done, prioritization skills suffer. Bureaucrats generally don’t know how to design and build software. Their expertise is in law and policy, not code and user-centered design.
Product management is about articulating a problem, choosing the right solution, and shepherding a team through delivering on that solution, balancing tradeoffs and communicating with stakeholders the whole time. It’s the perfect skillset for an environment where people know what the problems are but aren’t sure how to prioritize or solve them.
Government wants to build great software
All of the folks that I’ve met in government care about doing great things. They take their jobs seriously, and they’re constantly aware of just how many people are affected by their work. They know that government software has a bad reputation, and they want to change that. 18F and the US Digital Service have worked with agencies across the federal government, from the Department of Education to the Federal Election Commission to the Department of the Interior to the FBI, who are all united by one thing: an earnest desire to deliver great technology services to people.
The clients that I have worked with are passionate, insightful, and eager to learn. Their leadership is willing to take huge risks in order to work differently, providing the air cover that teams need to operate in an agile, user-centered way. They’re trying to solve problems that really matter, and they’re not going to give up when things get hard.
It’s been an incredible four months. There have been ups and downs, and I’ve certainly gotten a taste of just how hard it can be to move forward in an environment that values certainty above all else. All the same, I’m optimistic about what we can accomplish working together. And I haven’t had a moment of regret about joining this team.
