Too often, when government technology is hard to use, the teams implementing the technology are blamed for something they couldn’t control. In her new book, Recoding America, which has been lauded on the Ezra Klein Show as “the book I wish every policymaker would read,” Jennifer Pahlka sets out to explain why we need a new approach.
“Tech implementers are not charged with building services that meet user’s needs or achieve policy goals,” Jen says in the book. “Their job is simply to meet a predetermined list of requirements. But nowhere will you find a requirement that the service actually works for the people who are supposed to use it. They are designed instead to meet the needs of the bureaucracies that create them.”
The book addresses ways vendors and agencies can bridge this divide between technology delivery and government policy. Having founded Code for America to focus on these kinds of issues, Jen has also served as the U.S. Deputy Chief Technology Officer, was a member of the Defense Innovation Board under Presidents Obama and Trump, and co-founded the United States Digital Response to provide volunteer tech support for citizens. So, yeah, she has a lot of perspective on gov tech.
We asked Jen what those of us working in gov tech can do to make a difference.
You say in the book that we need to shift the focus from policy to delivery when developing government digital services?
It’s not that we should ignore policy, but government has been thinking almost exclusively in terms of policy as what’s important. I’m saying we need to think about delivery much more.
How does bad software hurt the policies it’s intended to support?
Take for example, MACRA, the Medicare Access and CHIP Reauthorization Act, a 2015-17 policy to promote value-based care, that required doctors and medical systems to use an online service to report their data so they could get more money for better outcomes.
Insider Insights
Jen Pahlka’s top three tips for gov tech vendors and agencies
The CMS knew the system needed to be easy for medical professionals to use, that it should ‘make sense to a person,’ but when the regulations started coming down, you’ve got to do this, you’ve got build that into the system, they were things that really weren’t going to ‘make sense to a person.’ Before you knew it, there was a lot of legalese that a sole practitioner had to figure out and this had the potential to make the software incredibly complex and fragile. If the software was too hard to use, it would drive the doctors out and they would leave Medicare.
This law intended to improve the quality of care could have actually degraded the quality of care for many people if they couldn’t find a Medicare doctor because the doctors had been driven out of the system by the administrative burdens of the software.
Fortunately, in this case, the team doing the implementation fought to simplify and clarify the policy complexity that had made past systems so confusing and burdensome. Their mantra became, “I get that it’s complicated. But it has to make sense to a person.”
Why do technology teams run into a disconnect working on government software projects?
When a team has to push back because something is ‘not going to make sense to a person’, they’re working in an environment in which the policymakers and the regulators don’t yet buy into how important the user experience is to the outcomes they’re trying to achieve. Push back is agile, and an agile approach is too often not part of the government culture.
One of the reasons I wrote the book is because we’ve all had frustrations with adopting a new development methodology if we haven’t addressed the fact that any development methodology exists within a much larger culture.
To change culture, we need more situational awareness about how our government works. Any organization operating under the waterfall methodology is based on a rigid hierarchy in which power and information and insights can’t flow back up. When information only flows down, it is not an environment in which you can do agile software development because you’re surrounded by a waterfall mindset.
We need to bring people along and change the culture in a more sustainable way than just say, “Yes, your culture is entirely waterfall, but tomorrow let’s start doing agile software development and hope it works.”
Why does government resist the agile, user-centered technology delivery process used in the private sector?
When the dominant culture is waterfall, agile software development can be like putting a round peg in a square hole, a saltwater fish in fresh water. When it doesn’t work, it can actually hurt the cause. What we haven’t done is take stock of how to help an organization understand the difference between agile and waterfall and really adopt what’s going to work for them, given where they are, and help them understand how to move the culture, not just the development methodology.
I think sometimes people think we want an agile government in the sense that we want to go all the way to a government that moves quickly on all things. In fact, what we’re looking for is a balance between agility and stability. We don’t want government to be the extreme of agile in the sense that none of us would want a government that changed all the time.
Of course we want a stable government, but if it takes 10 years to build something, and it’s already outdated or irrelevant by the time it’s done, that’s not very stable. Slowness in its own way will create a lack of stability.
We also have this notion that the oversight function of government is to find what didn’t work and then to find out who to blame and hold accountable. A good way to shift this would be to ask the oversight functions if they can highlight and celebrate what good looks like. Then public servants have something to aspire to and understand the kinds of decisions that will be rewarded, even though the culture tells them that push back is risky and won’t be rewarded.
How can we get requirements more in alignment with user needs?
The biggest change needed is bringing the concept and practice of product management to government. In the traditional framework of finding all the possible requirements and delivering on all of them, the more thorough you are, the better job you’ve done. This creates a lot of work for project managers, but it also results in what I call in my book “concrete boats,” software that’s so burdened with features and requirements that it sinks under its own weight. Product management can help.
The basic difference between product management and project management is that project management is the art of getting things done and product management is the art of deciding what to do in the first place. And product management has not been a recognized role or discipline in government. In 10 years of Federal job postings there were seven that mentioned product management. That doesn’t mean there weren’t people doing it, but it was barely spoken of until recently.
When you’re able to bring in and define the roles of product owner and product manager and those people understand their jobs to be understanding user needs and figuring out how to first and foremost meet those in an iterative way, you’re not going to need to do every single requirement.
That can feel very risky to government teams, as they worry they could be criticized for not building a certain feature, for instance. But by prioritizing the work around the needs of their users, teams can avoid building concrete boats.
What about focusing on a minimum viable product (MVP)?
You can’t have a minimum viable product in a framework that says, “Find all the requirements and fulfill all the requirements.” If you have a requirements development phase and then a development phase, the development phase isn’t done until you’ve checked all the boxes. The problem is that, fundamentally, you’re not trying to meet user needs, you’re trying to check all the boxes of the requirements.
The last big project that I looked at in the state of California had 6,700 requirements. So that’s obviously many, many years of work, but within that, there’s no articulation of the goal or what will meet the needs of the users.
And more importantly, how will you know if it’s meeting the needs of the users if you’re not even going to have them trying it out until all the requirements are complete 12 years from now? Most government projects would really benefit from some way of starting smaller.
We also spoke with Cyd Harrell who has done a lot of work on bringing user testing to the forefront. Why is user testing so important?
Cyd has gotten more public servants to start using and doing user research than probably anybody I know. And one of the tactics I’ve heard her say over the years is that the biggest difference is between zero and one. If you’re not doing it, just start. It doesn’t matter how, just get out there, go stand in line and talk to somebody and once you get started it’s not as scary.
When we don’t have user testing, we spend thousands of hours fighting over questions that can be answered by asking users or watching users use the service.
Too many people think you need a PhD to do user research, and while training can be valuable, it’s also important to make this practice accessible to everyone. If you’re struggling to decide how to word a particular question on a form, try several options and observe which ones users struggle with least.
Why has user testing been so hard to do in government?
The Feds have this law that governs what the agencies can do around user testing called the Paperwork Reduction Act (PRA), which was designed to reduce the burden because the thinking is that if you measure the burden, you can reduce it. So you have to go through OIRA, the Office of Information Regulatory Affairs at the White House in order to do data collection from the public, which is fair, we don’t want agencies just creating all these forms that you have to fill out. But this has been misinterpreted to include user research.
Most forms of user research, except for focus groups of 10 people or more, are exempt from the PRA, and technically shouldn’t require review. So basically, if you want to observe people using a website, do a card sorting exercise, or a focus group with eight people, it should not need approval by OIRA. But there’s a better-safe-than-sorry interpretation in agencies so that whenever somebody has a user research plan, it’s very likely that a compliance officer in the organization and says, “Well, just to be safe, let’s make sure we write down your plan, send it up to OIRA and have them approve it.”
Unfortunately, I think OIRA is approving these requests instead of what they should do, which is to return them rejected as an unnecessary step.
OIRA should clearly tell agencies they don’t need to do the approval step at all. But currently they don’t, and agencies spend enormous amounts of time on these approvals.
Approval can take a long time, often years, and oftentimes approval was never needed in the first place.
How would you encourage people to investigate these topics?
The question I hope to leave people with is, what is their role in this? And to the extent that we all contribute to this as citizens, sometimes as builders of technology, sometimes as consumers of it, and as voters, what do we expect of our elected leaders?
If our elected leaders are not paying attention to delivery it is because we have not asked them to.
Whether you’re a web developer working with a government client, or somebody who’s frustrated at the DMV, you are also somebody who is asked for your vote and your dollar by politicians. And so, what are you going to ask back of that politician before you give them your vote and your dollar?
You could ask them what they’ve done to make the bureaucracy healthier and less risk averse. Or to ensure that existing laws have been well implemented. Too often we just want to know if politicians share certain of our values, and we expect that will magically translate into the kind of country, or state, or city we want to live in. But it rarely does.
What are your top three tips for government vendors and agencies working with vendors?
For vendors:
- Both listen to, and upskill, your partners
Don’t just build the digital tools requested, leave the agency with skills to understand them. - Educate on agile practices
Help agencies do this work with a greater understanding of product management and user needs. - Encourage user research
Explain to agencies how easy it is to do user research and that they don’t always need to get approval.
For agencies:
- Lean into product vision
Your technology is an extension of your mission so have an opinion and set a goal for your digital tools. - Become great product owners
Your vendor may be able to provide a good product manager who can speak for the vision of the tools and the needs of the users, but you should be clear on your role as the product owner, and lean into it. - Embrace user research
Instead of spending lost hours debating an issue, budget for productive hours to watch people use your digital tools and see what works best.
Learn more
- Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better, by Jennifer Pahlka
- Improving Government Services: San Francisco’s new chief digital services officer, Cyd Harrell, on the benefits of user research and civic tech
- Public Interest Technology to the Rescue: Tara McGuinness and Hana Schank on how government can improve design and delivery of online services
- Succeed with Digital Content: Successful content means successful users, says Padma Gillen
