I’m a fountain of stories about how government can do better. They’re not rants… at least I hope they’re not. The maddening things that happen to people (Routinely! Daily! Hourly! Minutely! not in an airline-just-dragged-a-passenger-off-the-plane and now-everyone-is-watching sort of way) when they interact with government services are the effects of a system We the People designed, so this is not a finger-pointing exercise. Today’s observation is similarly not about blame, but also a bit different: it’s about what happens when civil servants learn over time that systems are immutable.
At Code for America, we work to make better interfaces to a number of government services: food assistance, probation, clearing your record, job training. Each of these services has a number of things in common when it comes to how the public uses them: users typically fill out a form, provide supporting documents, talk to a public servant live, and either gain access to that service or not. (Okay, there are often several other steps…I’m simplifying.) One of the things we’ve found maddening as we’ve watched these services from the perspective of the user is that a shocking proportion of people never make it through that process, not because they’re ineligible, but because it takes a lot of time, follow-through, and often courage (as in “I’m afraid of giving my information to the government but I’m going to do it anyway”) to make it all the way through, and then to continue to interact with the system to stay enrolled. Having to call back multiple times is one of the things that makes this hard.
Recently, someone sent us a video of an eligibility worker for one of the programs we work on talking excitedly to his peers in other counties about what can happen when you use Code for America’s service and your clients can upload documents and send them to you “magically, immediately!” On this particular program, in California at least, the State runs a legacy system that lets users (meaning people applying for this benefit) apply online. But part of the online application involves uploading images of supporting documents (think driver’s license, pay stubs, etc) to the system. In the legacy system, those documents are received immediately but delivered to the eligibility workers 48 hours later. WHY, you ask? That’s a question for another time, having to do with things like batch jobs and other processes that I don’t really understand. The point is, Code for America makes it possible for documents to arrive in the worker’s inbox immediately, just as if you were on the phone with the customer service rep at the bank and you said “hold on, I’m sending you the file… okay, got it?”
In the video this kind soul sent us, the eligibility worker is exhorting his colleagues and peers in other counties to realize something important and apparently non-obvious: you can stay on the phone with the client while the documents come in . You can check the documentation and approve the client ON THE SAME PHONE CALL. You don’t have to call the person back, probably missing him or her and starting a painful game of phone tag. His enthusiasm for this feature seems out of proportion to its level of innovation (which, to be fair, is basically zero). His enthusiasm might also seen unnecessary (why isn’t it obvious that you can just stay on the phone with the client?) until you realize something about people who work with government IT systems routinely: they’ve been trained to expect and accept that IT systems don’t work well, and that they don’t change.
There was that time when a government official told us incredulously that what we were describing we do wasn’t possible, because we integrate with their systems and there was no way that our system could adapt to the updates their team ran. Our engineer replied “Yep, I know you update every 2 weeks. I just block my calendar from 9 am to 10 am on those Mondays in case you’ve updated, make the changes to our system, and deploy.” “How long does that take?” he asked. “Oh, end-to-end maybe a half hour?” “No way,” he replied. “We could never release on that schedule.” His inability to believe that our software updates in response to theirs could take less than an hour wasn’t malicious, stupid, or incompetent. It was the natural consequence of spending your career within a system that genuinely requires six months or more for routine updates. (Spoiler alert: it’s not the software development process that takes the six months.) The belief, though rational, is wrong.
One of the least visible long-term effects of leaving government systems decades behind (and bad versions of what we had decades earlier, at that) is that the people using them have almost no expectations, and don’t vocalize their needs. If you run a consumer service that changes frequently, you’re probably used to hearing from your users if something needs attention, whether it’s an opinion about a feature that would make the service better, a bug that needs fixing, or a different color or size for a button. (You’re probably also doing a lot of A/B testing your users don’t even know about.) Now imagine your users lived in a world where software changed the way buildings do, only when expensive contractors were able to come onsite and and work for many months or years. How often do people bother to suggest changes in the built environment? “Hey, it would be great if you could move that alley so I could get where I’m going faster?” “Hey, wouldn’t it be awesome if the metro stopped closer to my office?” We just don’t see those as realistic requests so we don’t bother vocalizing them.
Neither do government workers. They have no rational reason to question that documents uploaded to their system should reach them 48 hours later, even though they are probably depositing their checks online in real time using their mobile phones when they shed their government worker personas. But now the government software world is changing, and there are folks like Code for America, USDS, 18F, and Digital Service teams in cities, states, and counties around the country, who CAN fix these things. There are agile vendor pools in use in places like the State of California and the U.S. federal government that mean that both the government team in charge and the vendors they’ve hired treat software like a service that needs ongoing improvement instead of concrete that’s been poured. It’s time to start speaking up.
During my time at the White House, I worked for a few weeks with a particular federal agency that had a major problem processing applications for benefits, not all that dissimilar to the applications we work with at Code for America at the state and local level. We were doing what we now call a “discovery sprint,” though at the time it didn’t have that name. It was just “Please bring me some of those people you have working on fixing healthcare.gov to tell me what’s wrong with my thing.” We had heard in prepping for the sprint that latency in the system in question was a major problem. In our first meetings, we asked the senior people assigned to us about latency, and they told us that it was not a problem. Latency was being measured and only a tiny fraction of users were experiencing it, we were assured. Huh, we thought, and we proceeded to go interview users. Latency, it turned out, had been defined as over two minutes of delay. If the time between clicking and getting the result was less than 120 seconds, you were not allowed to report a latency issue.
When was the last time you waited two full minutes between clicking and getting the result? Okay, now imagine there’s even a few seconds of latency between each of your clicks. Want to do it again? Yeah, I didn’t think so.
The costs of these legacy systems to the American public can be hard to see but are truly immense. They are immense in terms of IT dollars (most are in the hundreds of millions to build and dozens of millions each year to maintain), they are immense in the cost of the human capital required to use them, and they are immense in the cost to Americans trying to interact with them. Last May, hackers attacked similar legacy systems in the UK government, making it painfully clear that the security costs are also immense. (Government Technology defines a legacy system as a business-critical system that no longer meets user demands and was implemented prior to Oct. 25, 2001 — the date Microsoft released Windows XP. Microsoft stopped supporting XP in 2014, making it uniquely vulnerable to attacks like the one last weekend.) Most importantly, the costs of these systems are immense in the toll they take on trust and faith in government in our country.
And these systems can be fixed. Government workers will need to have higher expectations. So should the American public. We need to care .
If you care, get involved with Code for America. Support our work. Join or start your local Brigade. Work in government. Join our team.
