How Policy Becomes Code

A lot of hands touch each product and service that gets built at Code for America. From client research to marketing, everything we create goes through a collaborative process full of feedback loops, iteration, and countless Zoom meetings. We want to hone in on one particular part of that process today: how product managers keep all our teams on track.

Recently, we sat down with three of our staff members: Ryan Hatch, a Senior Product Manager, Vraj Mohan, a Principal Software Engineer, and Francesca Costa, the Program Director of Food Assistance. We asked them a few questions to learn more about the process that public benefits policy goes through to become a product like GetCalFresh, our digital application assister for California’s version of the Supplemental Nutrition Assistance Program (SNAP).

How does policy shape the technical products we make here at Code for America?

Francesca: Policy forms the bedrock of our products. At its core, a system like GetCalFresh guides clients through a series of eligibility questions derived from the policy that creates this program. When we build products, we follow the principles of good service delivery—clients should be able to easily understand where they are in the process, what to expect, and what next steps to take, but they shouldn’t have to become policy experts to apply for benefits. Think “you need to submit these documents and answer these questions” rather than “let’s bring you into every policy detail.” Basically, we ask: where can we let the computer do the work?

What does that mean, “letting the computer do the work”?

Vraj: Letting the computer do the work is all about translating the logic of a policy into the code that underlies the product. The code is basically a set of instructions for the program to execute a given problem. So the problem here is: “Does this person or this household have an income that qualifies them for CalFresh?” One of the first steps we have to take on the backend is to compare their income to what’s written in policy. In California, this policy says that for a household with no exceptions (such as ones with elderly or disabled members), their gross income must be below 200% of the Federal Poverty Level (FPL), and their net income (gross income minus certain deductions, like for money spent on childcare) must be below 100% of the FPL.

The policy is basically a math problem with several variables. If this, then that. We can write a program to solve that. Letting the computer do the work means we ask clients as few questions as possible, then use the information they share to do that calculation, and  see if they might be eligible.

What happens when products need to change or adapt to client needs?

Ryan: We made a change recently in how we screen SNAP applicants to see whether or not they may be eligible for expedited service—a policy where clients with acute needs can get their application processed in three days instead of 30. To be screened for faster service, applicants had to answer all these compound questions that turned out to be pretty confusing. Something like, “Do you have less than $150 in income and less than $100 in resources?”

We knew asking questions this way was a no-go for us—way too confusing, and really hard to answer accurately, which is critical for government partners. Instead, we asked applicants: “How much money do you have in cash and in the bank?” Despite this simplification, we still saw high drop offs, especially for Chinese speakers. User research with clients confirmed that people were scared to give information about money they had saved, even though resources don’t count against your application for benefits.

We knew we could find a better way to meet the policy requirements and answer these screening questions for clients using the info they’d already submitted elsewhere in the application, plus maybe one or two more questions. We started taking client data and using it to calculate a simple and personalized yes/no question, so what the client eventually sees is: “Do you have less than $250 in cash?” (This number is personalized for each client.) This turned out to be much easier to answer. 

What’s the impact of changing just one question? Why focus on something so granular?

Francesca: All the screening questions are complicated on an ordinary day—and then you’re in an emergency situation needing expedited service and it’s even worse. We’re operating at a massive scale—we assist just under 80% of online applications for CalFresh across the state. So we have to think of every single edge case. There’s no getting around that. Changing this one question cut drop off rates at that stage in the process by more than half for all applicants, and by 75% for Chinese speakers. 

Is it unusual for eligibility guidelines to be this complicated? Why is policy so difficult to distill?

Vraj: This is par for the course in my experience working on government projects like this. When I worked on Clear My Record, the initial guidance that California gave for who qualified for marijuana conviction clearances was full of all kinds of nuance. We had to take guidance from District Attorneys across the state and find a way to simplify all that complex logic for the code. This SNAP expedited eligibility project was hard for me to understand even with all my policy experience, even with guides that spelled it out.

Francesca: Eligibility guidance is so hard to understand because it wasn’t designed cohesively at one moment with the client experience in mind. Policy in this space tends to be additive, which makes things very hard. The final product represents layers upon layers of compromises and  hardwon policy fights. That means we have to find the little windows of opportunity to relieve the policy burden on clients. 

How do all of your skill sets come together to tackle a challenge like this?

Ryan: One of the most important aspects of this work was getting everyone on the same page. Everyone needs a deep and shared understanding of the policy requirements, the problem we’re trying to solve, and the technical and design constraints we’re working with. When we decided to prioritize this expedited service question, we had one person from every discipline—software engineering, program experts, designers, product managers—in the room to weigh in on the fix. We had to make the space to ask questions so that everyone understood the scope of what we were doing, and we kept that communication going throughout. 

Anytime there was a question, we’d do a quick Zoom to ask the right person. One of the places Vraj and I really relied on Francesca was around edge cases. We’d sometimes reach a point and have to ask, “What does the policy say should happen in this situation?” For example, what happens if you have less than $150 in income, but exactly $100 in resources? Is that inclusive or exclusive?  We wanted to shift the burden of understanding complex policy off the client and onto the technical system. To do that, we had to make sure we understood the rules and could translate that into code. Now, clients can more easily submit an application without fear or confusion and we can provide accurate information for eligibility workers processing cases.

Francesca: At the same time, we have to engage stakeholders the whole way to make sure we were complying with the law, making accurate recommendations, and passing on the right information to county workers who make the final eligibility call. After we rolled out the change, we got feedback from some partners that they needed more information to understand how we’d screened applicants for expedited services. So we iterated—based on that initial worker feedback, we started writing out the math equation in the simplest way possible. Showing our work helped them understand our calculation, and now they save time too!

Everyone needs a deep and shared understanding of the policy requirements, the problem we’re trying to solve, and the technical and design constraints we’re working with.

What could be done at the start of this process—the policy development—to make it an easier experience eventually for the client?

Vraj: Policy should follow the whole KISS design principle—you know, keep it simple, stupid. You should be able to explain a policy easily to the beneficiary on the other end, and they should be able to understand it—but this is usually far from the case. You shouldn’t have to be a policy expert to understand eligibility guidelines. In the tech world, when you take a proposal and put out a Request for Comment, you have to put out a working implementation with it. We could apply that same logic to policy—there should be a working implementation of the code it would take to achieve a policy’s end goal so that you can see how difficult it would be to turn into a usable product. 

Ryan: Eligibility policies like this—absolutely brutal sentences that are hard to parse apart—are the result of 80 million compromises between the federal government, county workers, state program administrators, and advocates. Some of the compromises come about from the perspective that maximizing participation in safety net programs shouldn’t be a priority—that we should keep eligibility narrow or require clients to meet multiple requirements to qualify. If that’s your perspective, you’re going to write in lots of complicated policy guardrails that end up being a barrier. If, however, you want a public benefit that gets all people who need it through the door quickly and easily, you build policy a little differently. We need a policy environment that wants to get people benefits and recognizes the broadest possible access as the end goal.