Note: This repository represents my personal work, done in my personal time and capacity. It is not representative of GSA (my employer at the time of publishing).
Much of the technology that people use to access safety net programs and that states use to administer these programs is aging and crumbling, despite significant spending and effort to modernize.
I have worked in this space for several years and have had a chance to see the problems from a variety of angles. Nearing the end of my term at 18F has prompted me to reflect. This is my attempt to describe the challenges as I see them and present some ways forward under the current paradigm.
We ask over-stretched, insufficiently technical state staff to modernize massively complex computer systems by adhering to federally-provided checklists and oversight regimes, working with massive vendors through multi-year contracts worth tens or hundreds of millions of dollars.
But states are not well positioned to build software, modernize legacy systems, productively manage vendors, easily comply with oversight, and deliver timely and trustworthy data. Federal agencies are not well positioned to quickly drive change in the market or provide technical oversight that accelerates modernization rather than impedes it.
The way we approach technology for safety net programs forces states to dwell on their weaknesses, buckling under the weight.
If we are to repair these aging systems to deliver the services people need and Congress has defined, we need to reorganize the work in ways that allow the various actors to thrive.
This piece attempts to envision a position of strength. The following six strengths are focused on challenging the boundaries we've drawn around our systems and distribution of responsibilities.
1. A loosely-coupled ecosystem of state, federal, and commodity software products, web services and data powers federal/state safety net programs.
The fact that most federal/state safety net programs are administered by states cannot mean each state, territory, or tribal organization must build, buy, host, or maintain all technology needed to run the programs themselves.
Rather than just delivering written guidance, programs should create and expose APIs states and others can use to help make eligibility determinations. Recent work on codifying program policy into rules that can be accessed this way has shown the feasibility of the approach.
Rather than collecting data on an application-by-application basis, we should gather data from applicants in aggregate for all relevant programs in the most intuitive way for the applicant.
Recent work on the applicant experience has largely figured out what applying should look like. Government design systems have defined good practice for how public-facing systems should look and function.
Rather than providing tools that state workers need to overcome to do their work, they should have tools that unlock their potential. Here I present a prototype of what a tool that empowers eligibility workers to meet their mission could look like.
6. Legacy systems are steadily transformed through modest increments, continuously delivered to users
Transitioning from a position of weakness to a position of strength will be hard. States will need to unwind their legacy systems to tap into a more loosely-couple ecosystem through a series of incremental improvements.
These ideas are not comprehensive—there are other things we should do as well—but these are key aspects that I feel well-suited to speak to. For example, A number of my colleagues at 18F are better positioned to explain the challenges around procurement in government and propose solutions. And the problem of diminished in-house technical capacity across state and federal agencies is a major problem without a solution.
Please note: Grandiose concept pieces like this are always wrong. Or rather, they get a lot of things wrong. The point is to move the conversation along and attract participation in rethinking broad assumptions and conventions.