Marina Nitze starts her essay How to Peel a Banana with a box of index cards.
In 2017, Rhode Island’s child welfare agency had an ambitious plan: hire Palantir to use big data to match foster kids to foster homes. They were sure the problem was access to data. Then Marina looked at the database. It was a physical box of cards. Probably not the same data access fix Rhode Island had in mind.
The rest of her essay follows a decade of ongoing fixes. Each fix worked. Each one turned out to be a symptom of another problem. Solving a broken intake process led to state rules that couldn’t be explained. Understanding those rules led to a federal model standard that had lost its guidance on the way down. It took rewriting the national standard itself to fix the problem, and the work is ongoing.
Marina’s description of her work may be long, but it is worth every minute of reading. Once we finished it, the State Capacity Ecosystem team had a practitioner’s question.
How do you actually do all this?
If you’re a well-meaning engineer, product manager, or consultant told to fix a government problem, what do you ask on Monday morning to avoid your own 10-year journey?
The problem you think is the problem is rarely the actual problem
Government doesn’t experience problems the way traditional businesses do. Understanding why leadership may not have full visibility into what’s broken is the first step toward engineering teams fixing causes when they’re handed symptoms. Let’s illustrate by walking through a common government problem-solution cycle.
Consultants lead an external audit and flag a data system outside the standard enterprise environment. This system, which we’ll call “rogue shadow IT” (RSIT), is labeled high danger because it duplicates the enterprise platform – this might mean that too many people have access to confidential data, that the process for using data is unsafe, and reports somehow show different outcomes. The obvious solution is to migrate the data and shut down the RSIT.
The internal team acts quickly, shutting down the RSIT, and the problem is solved. Or is it? Six months later, the same system is back and stronger than ever. Why?
First, a deeper look might have revealed that the RSIT was never, in-fact, rogue. IT built it and kept it running. It existed outside the enterprise platform because the enterprise platform couldn’t seem to do what the team needed. The external consultant didn’t get quite far enough into the weeds to understand that the RSIT was in fact a monitored, secure system.
Second, nobody had ever defined what “safe” data usage meant. Each new user, in a well-meaning attempt to protect confidential data, expanded that definition. The strictest reading of every rule and regulation won by default. (Marina would recognize this. An undefined standard always gets read in its most rigid form.)
Finally, you get to why the separate system is needed in the first place. Turns out, all this complexity exists to produce just one key report. So, the solution seems simple: scope and formalize a custom support within the enterprise system.
But building that report inside the enterprise system is hard because the data it relies on is inconsistent. The data is inconsistent because the data intake process was defined 15 to 20 years ago. People use the system the same way the very first user did all those years ago. The technology and needs changed while the process didn’t.
Nobody did anything wrong. Every choice made sense when someone made it. The system on its own was fine. The problem lives in how everything came together (or didn’t) over time, and how there was never quite enough incentive to adapt to an ever-changing world.
What you need is the toolkit to identify each of those small decisions and find and action their quick fixes, all while simultaneously keeping in mind the overall vision and the potential for more efficient redesigns.
Eight steps to find causes, not symptoms
Scope: who asked, and what do they actually control? Write down the problem you were given and who owns it. Then write down what that owner can change. Each time you find a process step out of their control, talk to the person who runs that step. You might find the world is much wider than you first expected.
Observe: who gave up, and why? Talk to users, especially the ones who quit. Their pain points will reveal what is process, what is systems, and what is people. At the VA, USDS research found over 70 percent of visitors had trouble with the health care application due to a requirement of using specific, outdated software to access it.
Quantify: where does the work pile up? As you map the process, count. Volume, wait time, and drop-off at each step. For Marina, a simple spreadsheet showed Rhode Island that over 80% of applicants never finished.
Trace: where does each requirement come from? For every step, ask whether it’s statute, regulation, guidance, a form, or habit. Then go read the source. For years, federal teams believed the Paperwork Reduction Act banned usability testing. It didn’t. OMB clarified this in 2016, then had to say it again in 2024 because the confusion was still blocking testing.
Compare: who does this well already? Find the peer who already solved it. Figure out how. Benchmarks are key to defining what good looks like. Marina put two states on a call to explain how each did things the other thought was illegal.
Constrain: if we fixed only this, would the outcome change? Your job is to find the binding constraint holding everything up. If the answer to the outcome change question is no, you haven’t found it. Keep going. Sometimes there are a series of binding constraints. This is great, because you can knock them down sequentially. Sometimes you have to handle constraints in parallel. This is tough, but that’s why you’re here.
Lever: are you fixing one output, or the machine that makes outputs? Fixing one step helps one pain point. Fixing the model solves the problem. California once ran three different online SNAP applications with 100+ screens of repetitive questions. With help from Code for America, California now has BenefitsCal, a single statewide system.
Teamwork: what’s the first (or second, or third) real quick win for everyone? Find the unglamorous solution or invest in the imperfect but workable fix that builds trust and gets you access. Too many builders make the mistake of prioritizing efficiency over empathy and perfection over good. Most problems have core human elements that need to be addressed before the system itself is fixed.
AI will speed up whichever way you’re going
How we deliver matters so much more now that AI is changing just how fast we can go down the rabbit hole.
AI can make the cascade of symptoms worse. A model reading a broken process will take it just as literally as any human and build off it. Maybe it will help you identify duplicative work or an out of order step, but since LLM’s tend towards sycophancy and work within existing systems, it’s (probably) not going to tell you to kill or reorder steps entirely - at least, not without the right prompting.
AI can also make tracing cheap and easy. Marina spent years comparing state rules by hand, one monthly call at a time. Today a practitioner could pull every state’s licensing code and ask where each requirement came from in an afternoon.
The key here is that a tool doesn’t pick the direction. The questions you ask to understand the problem before you use the tool are how you give it the direction it needs. Intentional use of AI can assist and accelerate the eight steps above, driving work toward long-lasting fixes instead of temporary band aids.
How to tell you’re still peeling
The hardest part is knowing when you’ve hit bottom. A few signs you haven’t:
The fix helps one site, project, or process – but not the next one.
The fix adds a rule.
Someone says “that’s the law” but can’t point to the exact line.
The request is for a report or dashboard.
You write articles to convince folks to join government and tackle problems with you
Are you a government practitioner who wants to use AI and technology to do your job more effectively and efficiently? A technologist who wants to dip your toe into the civic realm? An expert in government who thought our article was spot-on, completely off-base, or somewhere in the middle? Tell us more by filling out this short form!