Writing our principles and values, together, part 2: policy
By: Jennifer Pahlka
Tags: Civictech, Values, Policy, Civic Hacking, Government

Note: This is second in a series of reflections on and invitations to our Code for America Brigade network. If you’re reading this and don’t know about the great work they do, read about them here and hear more about them on our Twitter feed!

Last month, I chronicled the process of moving towards a shared set of vision, mission, principles, and values across the Code for America network, and some of the questions and self-reflections that have come up through the process, including clarifying our relationship to government. Today, I’m going to pick up where we left off and address Tricia Davies’ question:

When Code for America first started, I had a different perspective on this than I do today. To be sure, we have always been in the business of advocating for a variety of policies, starting with open data. Advocating for open data policies in cities was one of the first activities that was relatively consistent across Brigades as they were forming in the early days; it helped that Brigades were also the consumers of that data, so we had opinions on how that policy should be written and how it should be implemented. We very quickly went from the what to the how, and had real impact.

But I will begrudgingly admit that in the early days, I took a somewhat hostile stance to policy and policymakers, in part because implementation has been the biggest and most obvious gap in government effectiveness, but also because of a sense that policymakers were privileged in a system that paid less regard to the people charged with implementing and delivering that policy. Mike Bracken, founding head of the Government Digital Service in the UK, once said “I never want to talk to a policy person unless they have a developer on one side of them and a user on the other,” and he captured my distrust perfectly. But there’s been a steadily growing body of evidence from the folks doing the work on the ground that doing the implementation work puts you in the best position to understand and change policy, and the Code for America community has risen to the challenge that comes with that position. The policy community has also taken notice, and increasingly wants in on this new way of working. Now I’m all in on policymakers and regulators as a core part of the movement.

A lot of what I see this community doing is what I call delivery-driven policy. The story I told at the last Code for America Summit is a good example of this. Cribbing here from a blog post I wrote earlier this year:

Last year, regulators at the Health and Human Services Agency in Washington, DC were charged with implementing a law called MACRA (the Medicare Access and CHIP Reauthorization Act of 2015.) The MACRA team wanted the HHS Digital Service team, led by Mina Hsiang, to build the website that would implement this law, designed to allow Medicare to pay more for better care. What usually happens is that before regulators engage a tech team around a website for users (in this case, doctors and other providers of medical care), they spend many months of study and research, producing a specification describing in great detail the rules the web application will encode. Mina proposed that the team writing the regulations give them an early draft in about a fifth of the time it would normally take them, and let her team do an early version of the website based on that draft. It’s normal practice for a tech team to test a site with users early in the development process; what was different this time is that the regulators could also see how users experienced and interpreted the rules they’d written, and change their language based on user behavior. They could then test the new language in a subsequent (still draft) version of the site, as the tech team put out new versions of the website to their test users. They did this four more times before the regulators called the rules final. The MACRA regulators reported that they’d just written the best rules of their career, having benefited for the first time from real-world feedback during the process.

Cecilia Munoz, head of the Domestic Policy Council for President Obama, often says “we need to have tech people at the policy table from the beginning if we are going to make policy that works.” In cities, Brigades are increasingly those tech people, helping cities understand what makes a policy implementable before they’ve gone down a path from which can be hard to return. They of course have a long history of driving policy change, starting with open data policies but moving into everything from recycling to open algorithms, but they are also instrumental in getting policy right in its implementation.

Even in the first year of Code for America, when we thought we were strictly limited to implementation, we were already tweaking with policy. One of the first fellowship projects in 2011 was Joel Mahoney’s DiscoverBPS. Tom Menino, the late mayor of Boston, asked the Code for America team to work on a problem: parents needed to find the right public school for their kids, but the school assignment policy had changed to preference distance from home, and the 26 page brochure with tiny type that the Schools Department sent out to prospective parents annually did not suffice to help parents map their eligible schools. We were convinced that this was straightforward implementation of existing policy, but when Joel and the other fellows got the site up and started watching parents use it, it suddenly seemed less straightforward. There were edge cases galore, like when the distances between a home and a school landed at the edge of a school property, and as Joel said in his CfA Summit talk: “If we’re here to clarify the policy, we’d better not be making it more confusing.” But there was also the realization that the policy itself did not always get the intended outcome. A 1.5 mile radius from a given home might span Boston Harbor, for instance, making it much further to walk to one school than the distance measured as the crow flies, while eliminating schools that were in fact closer on foot and more appropriate for a given student. It was in the digital implementation that the need to adjust the policy became clear. In other words, delivery-driven policy change surfaced in our very first project.

Delivery-driven policy is everywhere in the Code for America network if you look for it. Our work on SNAP with GetCalFresh now boasts multiple examples of policy and operational change driven by insights about users of the system and the barriers they face. And what Code for Tulsa has done in implementing CourtBot is in some ways the flip of the DiscoverBPS or GetCalFresh stories, but it’s the same thing. The policy in question in Tulsa is holding people charged with minor crimes while they await trial, a policy driven by a fear of “failures to appear” (FTAs) in court, but one with devastating consequences to the people held and their families. By offering CourtBot as a way to reduce FTAs by texting with clients to remind them to show up in court, Code for Tulsa opened up the possibility of a change in policy by making the delivery of that policy seem possible.

So to Tricia’s question, I guess my answer would be that yes, the vision is to not just change policy, but also to change how policy is changed, and how it is made in the first place. We are not starting with the high level policy decisions that set the goals, but rather with the details of the policies and regulations that matter so much to whether the high level policies actually achieve their outcomes, in part because we have many excellent policies and programs in this country that are not living up to their goals, like the participation gaps in SNAP and record-clearance programs. Showing policies and programs working as intended builds trust and strengthens the public’s faith in government. Showing that government can work for people strengthens our position from which to advocate for higher level policies that do just that.

So I have a few questions to ask back to the community. What does delivery-driven policy mean to you, and what examples would you like to share? Every movement in the country is advocating for policy change; what do we bring to the table that no one else can (or conversely, that everyone else can if we share what we’ve learned and grow the movement?) With whom can we partner to have the greatest impact on policy? I think about Code for Asheville partnering with their local homeless advocates BeLoved and having an impact on policies that affect the homeless, because they brought data about delivery (in this case about policing practices) to the table. Where we don’t operate the services ourselves, partners like in the community can help us get closer to users, closer to delivery, and put us in the position to let the delivery drive the policy.

I don’t ask these questions rhetorically. Both as part of the process of discussing our vision, mission and values, and part of the process of articulating and disseminating the practices of our community, I invite you to share your examples, questions, thoughts, and ideas by responding to this post. Let’s hear it!

And to all Brigade members, we’re closing out our process on the vision, mission, principles, and values work, so get in touch if you have final thoughts!