Understanding government procurement, with Luke Farrell
Patrick (patio11) sits down with Luke Farrell to examine the structural "technical imagination" gap that prevents the US government from delivering high-fidelity digital services. They discuss why states routinely pay full price 29 times for the same buggy codebase, why failure is the default outcome, and why rooms full of government administrators cannot muster the expertise to say a two line code change should be trivial. They also discuss Luke’s work on the "means testing industrial complex,” why the government redundantly pays a private vendor to do a SQL query for information the IRS already knows, and what vendors would say about their own discontents.
Presenting Sponsors: Mercury & Framer
If you have more interesting hobbies than managing your money, Mercury Personal is built for you. It allows you to automate movement between accounts—allocating paychecks and tax prep the moment they hit—with a sensible permissions model for partners or accountants. It works the way tech people expect banking to work. Go to mercury.com/personal to experience banking built by the same folks Patrick trusts for his business.
Building and maintaining marketing websites shouldn’t slow down your engineers. Framer gives design and marketing teams an all-in-one platform to ship landing pages, microsites, or full site redesigns instantly—without engineering bottlenecks. Get 30% off Framer Pro at framer.com/complexsystems.
Timestamps:
(00:00) Intro
(01:52) Transitioning from Google to the US Digital Service (USDS)
(05:18) How rule buildup and administrative burdens create "Kafkaesque" mazes
(08:21) Using diagrams and funnels to visualize benefit denials
(11:49) Software logic errors that improperly kicked children off Medicaid
(18:25) Why government payroll IT costs hundreds of millions of dollars
(20:02) Sponsors: Mercury and Framer
(22:02) How recursive legal requirements and DOD standards inflate IT scope
(26:57) Market consolidation and the lack of competition in procurement
(33:47) Aligning program administrator incentives with successful service delivery
(36:03) Using in-house technologists to push back on vendor change orders
(39:27) Shifting from "Big Bang" contracts to iterative, agile development
(53:10) The moral incoherence of asset limits
(01:11:36) Insourcing electronic income verification databases
(01:16:56) Building public sector competence to manage modern technical risk
(01:20:08) Wrap
Transcript:
Patrick: Welcome to Complex Systems, where we discuss the technical, organizational, and human factors underpinning why the world works the way it does.
Hideho, everybody. I’m Patrick McKenzie, better known as patio11 on the internet. And I’m here with Luke Farrell, a fellow at the Better Government Project at the University of Michigan.
Luke: Thanks so much for having me. I’m thrilled to be here.
Patrick: Thanks very much for coming on. I think government contracting is one of these just huge portions of the economy that is largely opaque to most of us who aren’t in it on a day-to-day basis. It drives a large and I think increasing portion of service delivery to citizens — everything from unemployment benefits to SNAP (food stamp) benefits to other services delivered by the government.
So it behooves us to understand how that sausage is actually made. This has cost control implications, efficient delivery of government implications, and also some policy-adjacent implications that we’ll get into later with some worked examples. And I think it’s always useful to be a more informed consumer of what you’re using.
Given that most people don’t understand how this interface between private industry and the government determines the government’s interface with citizens and residents, they make poor choices. This happens both in their retail encounters with those interfaces, and also in a special class of retail encounter with the government, which is when you’re a legislator attempting to get the government to do what you want.
[Patrick notes: This joke works on two levels. The primary one is the legislative process, of course, but a core designed escalation system for the American government is that legislators can intervene in individual decisions of agencies, down to the last individual passport or food stamp application. Your Congresscritter of choice has full-time staff who do this; their job title is often Constituent Services. You do not have to be “important”, a donor, or to have voted for the legislator at issue; calling their in-district or in-capitol office and being able to demonstrate you live in the district (often helpful, if truthful, to say that you are a registered voter in the district, too, but they will also do casework for immigrants and in fact that is quite common) is enough.]
And legislators mispredict how their own operation operates based on lack of knowledge of some of these things. So I want to socialize some of that knowledge more broadly.
With that framing, how did you walk through a path in life that caused you to be more exposed to government contracting than most people?
Transitioning from Google to the US Digital Service (USDS)
Luke: Yeah. Not exactly the path I necessarily planned, but it’s where I found myself. I was originally at Google where I was an APM — product manager — doing tech stuff. Then, toward the end of the pandemic, I was invited to come join the United States Digital Service at the White House, where they bring private sector technologists in to take on some of the hardest challenges in government.
[Patrick notes: APMs are not just program managers at Google, in the same way that the Senior Executive Service is not simply staffed with senior government executives. It’s a brainchild from the early 2000s where Marissa Mayer et al recruited a cadre of a few dozen new recruits (out of a population of thousands) for being fast-tracked to senior leadership.]
There I was focused on a whole bunch of stuff, including crisis response (like the infant formula crisis), and then ultimately found myself working on the government’s social safety net and the federal benefits that are provided through the government — including Medicaid and SNAP and unemployment insurance, and the whole host of services that the federal government provides along with states or directly to residents. These touch hundreds of millions of Americans and make sure that they can access healthcare, get food, and continue to survive if they experience a bout of unemployment.
As a result of that, I ended up in the weeds of some of these monster government contracts, these highly complex systems.
[Patrick notes: Roll credits!]
And as you’re trying to fix these programs, you really start to learn about the mechanics that actually drive them, which are often procurement, personnel, HR stuff. That’s all the boring things that make government tick.
And then I was also the Senior Advisor for Technology on the President’s Domestic Policy Council, where I took a broader look at some government programs in crisis and how to use technology to make sure that they’re delivered in a more dignified, efficient, and successful manner to hundreds of millions of Americans.
Patrick: I’ll make the obligatory disclaimer. I am largely non-partisan in professional spaces. We might not be coming at this from exactly the same point of view. [Patrick notes: To be slightly more explicit in the notes than this Japanese salaryman was out loud: The Law and Political Economy Project, which published the essay discussed later in the conversation, is a progressive legal academic publication. I would not describe my personal politics that way. I invited Luke because the operational details of how government benefits delivery works (and fails) are underexplored in my usual haunts, and because the specific observations about contractor dynamics, data broker economics, and systems architecture are separable from the policy preferences.]
But I’ve also done a tiny bit of government contracting in the past, and can speak from the perspective of someone who has written the response to a request for proposal, and has experienced some of the complexities there firsthand.
Luke: I’m sorry you had to go through that.
Patrick: Yeah. Nobody wants to. I’ve also been a citizen and a resident, subject to various governments over the years, and know what it looks like from that angle as well.
[Patrick notes: You will, several times in the audio, hear me say American citizens and either catch myself and add “... and residents” or not need to catch myself. This is something of a politicized shibboleth in some places, and in the current political environment perhaps some might imagine some valence in that phrasing. From me it’s just one immigrant’s preference for being very precise.]
I think people from a broad spectrum of political persuasions can, at least in theory, be in favor of maximizing for more dignity and more efficiency in government services. And we’re certainly not at the local optimum for either of those right now.
Luke: Yeah, I think that’s right.
Patrick: One of the things I write about quite frequently is that the social class that the two of us are in — the one that spends most of its time thinking about how these programs should be constructed — doesn’t need to apply for unemployment benefits or welfare benefits all that frequently. So we might not have the lived understanding of what these applications look like, or the various windows into the government and the private sector that you encounter while navigating them.
So, for people who are surprised that contractors are large portions of the data sources and labor workforce for evaluating these applications — why did that happen?
How rule buildup and administrative burdens create "Kafkaesque" mazes
Luke: So I think the complexity on the front end for the user — where you might have to go through a 20-page application to get health insurance through the government — is something anyone who’s had employer-sponsored health insurance knows can be confusing. It’s even more confusing when you’re applying through a government program. You might have to answer a whole manner of questions that aren’t clearly related to your eligibility or to the program you’re applying for. And that’s kind of a result of just the buildup of rules over time — well-meaning legislators and policy people might have thought those requirements were important to the program’s design, but 50 years on they’re no longer super relevant to an application. And it’s really hard to remove rules, but very easy to add them.
So this causes — and there’s a whole body of literature around administrative burdens — just this enormous amount of work that we’re putting on people to access benefits they’re entitled to. Anyone who’s filled out their taxes is very familiar with this experience. It’s kind of the same on the government program side.
Patrick: Can I give a tiny example of this?
Luke: Yeah.
Patrick: So we got back to the United States recently after 20 years in Japan, and needed to find health insurance. Since I’m self-employed and the Affordable Care Act exists these days, going to the ACA exchange is the obvious option. That was fun.
Boring backstory: my wife is not a US national. My children are. We’re a mixed-status household, which is something of a jargon word in service delivery. The web application became convinced that she was a US national and prompted me to upload evidence of her citizenship, which she doesn’t have.
I didn’t understand why the web app had made this decision. Maybe I miskeyed something, although that’s uncharacteristic. Maybe I was in some crazy error state. Maybe they don’t model mixed-status households. So I thought, I’ll just upload a copy of her green card and the person on the other end of this form will figure it out, right?
A week later I get back a response: “We’ve reviewed your evidence of US citizenship, but the green card doesn’t demonstrate that you have US citizenship.” I’m like, yes — wow, clearly top minds here. But if she has a legal status of residence, she is still eligible for the ACA. So does this individual have legal status of residence?
You are looking at the green card. Yes. (A green card is colloquial language for the document attesting to lawful permanent residence.) So I say yes, they have lawful permanent residence. The person clicks the button, and then 48 hours later I get an automated email saying: “Okay, given that you’ve said this person has lawful permanent residence, you need to upload a copy of their green card.”
Luke: Yeah. And —
Patrick: I smacked my head nearly hard enough to concuss myself and take advantage of ACA benefits.
And I deal with this sort of friction professionally, so it’s kind of entertaining for me. But I have to imagine that if you put 10,000 people in mixed-status households — people who may have varying levels of ability to decode paragraphs upon paragraphs of inconsistently bolded, graduate-level English — a lot of people are just going to get discouraged, or not be able to find the correct path, the cheese, and end up without the thing that theoretically speaking we want them to have. This is enormously frustrating, and it’s where the rubber hits the road for people actually trying to consume services.
Luke: A hundred percent. And I think what’s so maddening is that your experience is not unique. That is the modal experience of someone trying to interact with a public benefits program. It’s often frustration, confusion, having to parse complicated plain-language websites. And it might be a person who is working a blue-collar job every day and can’t go into the office or call into the call center during call center hours in order to troubleshoot the problem they’re having.
So you have millions of people who actually aren’t getting access to their benefits — not because they’re not eligible, but because of the maze, the Kafkaesque bureaucracy we’ve built around these programs that prevents them from accessing it.
And one example I think is really instructive here on the backend too — very “Complex Systems” — is when I was working on Medicaid, we found that over 500,000 children had lost their Medicaid coverage. Not because they weren’t eligible, but because states had actually designed the software improperly.
Patrick: You mentioned that the modal experience for these programs is kind of bad. Are you using “modal” explicitly there, like we have actual data to show this, or just impressionistically?
[Patrick notes: The modal data point in a set of observations is the one which is most common among all data points. Technologists have been known to use modal to actually identify the mode of a data set, or in the more colloquial sense, and thus I asked.]
Because one of the things I’ve heard is that the government often doesn’t instrument these applications, so they can’t give you an answer on questions like “what question is the hardest” or “where do people fall out of the funnel” — until they actually get to the point where the applicant has basically disengaged. Which is a crazy point of view if you’re a program manager at a tech company.
Using diagrams and funnels to visualize benefit denials
Luke: Yeah. So the word “modal” there is not really derived from instrumentation we have inside of these systems. And I love that you used the word “funnel.” When I was working after the pandemic to re-enroll 90 million people in their health coverage after the COVID public health emergency, we were basically showing up in state governments and building those funnels for the first time. Because everyone knew there was a problem, right?
Folks knew that there was a huge number of procedural denials — in air quotes — which means people who are not deemed ineligible, but who fall out somewhere in that funnel. Their paperwork never shows up. They sent in the wrong documents and then never replied again. Maybe they were unreachable because they changed their address during the three years that redeterminations were paused. There are all sorts of reasons why someone might be procedurally churned out, but there was no instrumentation to understand why this person fell out and at what point they were disenrolled.
So we kind of drove around the country in a van, showing up at state governments and state capitals, working hand in hand with them to instrument that full funnel and say, “Actually, it’s this notice that’s knocking out a hundred thousand children from the program who should otherwise be covered.” Or, “Actually, this line of logic in the software is from the nineties and is no longer compliant with the law and should be struck from the system.”
Software logic errors that improperly kicked children off Medicaid
One example of a huge problem we found in a number of states: they had actually designed the software to determine eligibility for a whole household as opposed to the individuals in that household for Medicaid. So in some states, the threshold at which children qualify for Medicaid is much higher than for adults — which makes sense, we want the program to be more generous for children. But if there was a household where the parents didn’t qualify and the children did, the whole family was getting kicked off their coverage. Which is explicitly against the law, but no one knew about it because it was buried in a software logic error derived from misinterpretations layered on over many years.
Patrick: For want of a Sankey diagram, the war was lost.
[Patrick notes: A Sankey diagram is a type of flow chart where the width of each arrow is proportional to the quantity it represents. If you started with a million Medicaid applicants on the left side and drew arrows showing where each one ended up — approved, denied for income, denied for paperwork, lost to a software bug, simply stopped responding — you'd immediately see which arrows were unacceptably fat. It is particularly useful in complex multi-stage processes where e.g. the experience of users who resubmitted applications might sharply diverge from first-time applicants. The form was invented in 1898 to visualize energy loss in steam engines, because they didn’t have Factorio Space Exploration to do so.]
Luke: Exactly. And I mean, we were literally building Sankey diagrams and state Medicaid directors were amazed that they could have that level of insight into where people were falling out. It was just so beyond the normal course of systems design and improvement inside of state government. Just putting that Sankey diagram on a screen unlocked all of this headroom for improving the program, because no one had ever really taken the time to thoughtfully go through it.
Patrick: I feel like there’s a path dependence here — and you can tell me if this matches your experience talking to the people who actually run these systems. Much of the economy has changed in the last 70 years or so, but broadly speaking, service delivery looks a lot like service delivery did in, say, 1950. We had a paper-based workflow then, and the government is pretty good, relatively speaking, at architecting workflows where: we need a floor of clerks, we need a front office, the front office passes paper to the floor of clerks, they get 10,000 papers on Monday, we successfully drain that stack within six weeks, and everything is operating as designed.
And if you asked in 1950, “Give me a real-time count of how many papers are in process,” they’d say: one, that’s a crazy thing to ask for, but two, if you want an approximation, go look at the physical floor and count how many inches of paper there are in the to-be-done box. That’s your count.
These days we have computer systems that are pretty good at doing real-time counts. But because the institutional memory of the system is that tracking the progress of an in-flight application is just strictly beyond the bounds of what’s materially possible — and I can’t even ask a web app to look at how many inches of paper there are because the paper doesn’t exist anymore — I’ve actually lost fidelity by moving to the computer system.
The management of these programs often doesn’t do things that are pretty table stakes for private industry, which came up in a post-computer age. Private industry writes SQL queries because it has business analysts. It’s not that the government has no business analysts, but I often think there is a crushing undersupply of them relative to need, and a management culture that doesn’t really make data-driven decisions — in a number of places, both in the management of the agencies and in the legislative branch.
Luke: Totally. I think that’s exactly right. Two thoughts on that. First, for example, in Medicaid, it’s in regulation that states need to have an online application for Medicaid. To me that doesn’t mean it needs to be good. It doesn’t mean it needs to be mobile friendly. It doesn’t mean that one person ever needs to successfully make it through the flow. Our modernization efforts in government — or those mandated by legislators — have been: “You need to make a website.” But they don’t take the second step of asking how you instrument it, or what the expectations are around performance of that particular tool.
I’m not suggesting that legislators should do that, but I think the folks who are actually managing the programs day-to-day should. And it comes up in procurement too, where we use the same mechanisms to procure buses and pencils and office space — things you need many copies of in different states and jurisdictions — as we do for software, where in theory software is infinitely replicable for marginal cost. Instead we’re kind of building stuff from scratch 56 times over.
That’s a little bit of what the piece gets at: the brokenness of that process, and the conception of these government programs as paper-based is ingrained all the way into how we do the contracting for software, which should be dramatically different from how you might procure office space or paper or pencils.
Patrick: I think part of the reason that the bespoke process for negotiating software deliverables is the way it is comes from the experience of past generations. The laws were written during past generations with respect to graft, waste, and abuse, and so we’ll tighten the screws by making people say, “Okay, put a line in the request for proposal that you have to be compliant with all laws of the United States and the state of Idaho and any local regulations.”
It’s very easy to say that sentence. But it blows up the complexity of the project by many orders of magnitude, because there is almost no one who is actually capable of telling you what are all the relevant laws of the United States.
An example I’ve used with respect to government payroll systems: payroll systems are their own separate fun ball of wax that explodes and deals damage to a politically powerful group — government employees — in the most direct way possible, hitting them in their pocketbooks. One of the reasons these systems are so bad is nobody stands up in the scoping meeting and says, “By the way, we need to have the option for Chinese language translations on the back of pay stubs.” It’s a hard requirement. That actually is a hard requirement because of the sedimentary layers of laws.
There are hundreds of thousands of hard requirements like that. Which is why this is not the “a payroll system should be done by three developers in six weeks” — that doesn’t sound reasonable to me at all. It touches real money. It’s going to be a multi-month project.
Why government payroll IT costs hundreds of millions of dollars
But then how do they routinely spend more than a hundred million dollars on a payroll system? The answer is that if you start writing computer programs that have hundreds of thousands of countable requirements, AI can’t write them all for you — at least not yet.
So, contracting and procurement — which are often synonyms for each other — can you give people a bird’s-eye view of: okay, I’m a program administrator for a state. I’ve just been told that Congress says I need to have a website. I don’t know how to spell PHP. How do I go get a website?
Luke: Yeah. It’s complex. And to start: in these federally funded, state-administered programs, it actually starts up at the federal level. In the case of SNAP or Medicaid, a state is making a request for funding to buy one of these IT systems from the federal government, and the federal government will provide matching dollars. In the case of Medicaid, they’ll provide 90% of the funding to develop a new IT system for a state government.
So a state sends up a request for that, and that’s a very compliance-driven process. The federal government isn’t checking to say, “Is this going to be a good website? Is this mobile friendly?” What they’re asking is: “Did they check all the legal boxes in order to be qualified to receive this financing?” So from the very start, it is a legal process and not a product development process. And the person on the federal side is someone whose expertise is in analyzing those legal requirements, not in asking whether this is going to be a good product.
How recursive legal requirements and DOD standards inflate IT scope
Patrick: One of the things that routinely trips people up is that this is a recursive process. A lot of the legal requirements incorporate by reference just huge bodies of documents. In a single sentence, you can say something like, “Oh, by the way, the website needs to be secure.” And that doesn’t actually mean anything in the material world. What it means is there’s this Federal Information Security standard — FISMA — which defines what security means in the context of government systems. It was written by some wonks at the DOD fifteen years ago, and relatively few people in the financial industry would say, “Actually, I want my security team’s Q3 plan to be defined by what is in that document.”
[Patrick notes: My apologies to my friends at the Department of Commerce; I misremembered where NIST was on the org chart.]
But the government says no — we need to understand what these words mean, and we have no understanding other than this 400-page PDF file.
So here’s 400 pages of new requirements. And there are individual sentences in there that routinely cause many millions of dollars of extra work for little, if any, marginal gain. They’re occasionally prescriptive about things like what your backup strategy needs to be, in a way that a talented technologist might not actually endorse. But the United States federal government in its infinite wisdom says the one true backup strategy is the one on page 37, and you’re going to implement it. And if you can’t buy it off the shelf — because no one would do that, because it’s crazy — then you pay the engineers to rewrite it from scratch for the 437th time.
Luke: Yeah, that’s exactly right. And the complexity is kind of fractal — whether it’s security or accessibility or any of these kinds of requirements, there’s a whole body of potential legal flags that anyone could raise that might slow down the process.
So once the federal dollars theoretically move to reimburse a state for taking action, the state is now doing a procurement where they’re putting out a request for information or request for proposals — “Hey, we need to build this thing, folks come and bid on this contract so you can be the one who actually develops it.”
In practice, when you’re putting out to bid a Medicaid eligibility and enrollment system, these might be hundred-million-dollar contracts — huge software development contracts for systems that are, at the end of the day, rules engines. The sticker shock to a private-sector person would be pretty amazing.
And in those rules are quite often criteria that only very few players can actually satisfy. So if Luke and Patrick made a startup and wanted to go bid on a $100 million Medicaid contract, one of the requirements might be: “Has built a Medicaid eligibility enrollment system before.” So how are we supposed to develop the expertise required to actually go and bid on that thing? It’s a risk-reduction exercise. That requirement is in there because no one’s going to blame you if you hire the guy who did the last one. But if you hire an untested party, you might catch some flak for that.
Patrick: Yeah. There’s an interesting kind of cat-and-mouse game — or I guess a tug-of-war — here. On one hand, we always say we want more small businesses in government contracting, more people to get a leg up, more innovation in service delivery. And then we have things that are dramatized in a movie like War Dogs, where two people out of their bedroom end up selling hundreds of millions of dollars of weapons to Uncle Sam for delivery to third parties. And you say, “Well, okay, we want a small business, but not like that.”
Luke: Yeah.
Patrick: So we ratchet things such that there are only, say, five firms capable of contracting government services above a certain level. And of those five firms, the number that play in a particular area might be two or three. Even if you’re dissatisfied with the bids, who are you going to go with? There are not seven options here.
You mentioned these can be hundred-million-dollar-plus systems. Absent specific legislative authority or similar, the rules that govern the hundred-million-dollar systems are the same rules that govern the $30,000 systems. I once bid on a contract with an annual contract value where my bid was $30,000. I lost out to someone who bid $15,000 for bespoke software development. I was already feeling the pinch at $30,000, and it’s anybody’s guess how much legal compliance you can actually buy at $15,000 a year.
[Patrick notes: The state of Hawaii needs to tell a certain class of individuals to come to their appointments in a timely fashion. I once ran a business which did broadly that, but of course the integration work would have been bespoke software development. After spending several weeks responding speculatively to the RFP and losing, the only long-term impact to my business was the state hit me with an income tax audit the following year, certain that I was a government contractor not telling the government how much money he was making. They were annoyed with me when I told them that the reason they had not received a tax return was because Hawaii-source revenue for the year was $180 and therefore below the statutory threshold.
I feel this has more than zero relevance as to why government contracting is done by large Lovecraftian horrors and not nimble tech businesses.]
But we certainly pretend that you’ve bought all of it.
Market consolidation and the lack of competition in procurement
Luke: No, that’s exactly right. And one of the unfortunate consequences is that when only five firms can satisfy those constraints, you get a really natural market plagued by the problems of consolidation. It becomes quite easy to buy up the other three that can also do this, and then suddenly you have one Medicaid IT contractor providing 32 of the state systems — or 26 of all the state systems — and their ability to capture the market is straightforward because of the huge barrier to entry. The design of these procurements favors the incumbent. So you get these really bad market dynamics, which create all sorts of downstream negative consequences.
Patrick: I often think that people worry — and many of the rules were explicitly motivated by the worry — that the contractors are going to go in a smoky back room by themselves and divvy up the world, such that even if we get three bids for something, they’ll have decided the winner in advance. Certainly collusive behavior by people to take advantage of the government has happened in the history of the United States. However, I think it’s important that people and policymakers understand that collusive behavior is not the only way this can play out. It can happen naturally and organically too.
One example: the financial industry, which doesn’t have quite as hard requirements around who you can purchase services from, nonetheless decided to effectively sole-source an endpoint monitoring system. Not a hundred percent sole-source, but there were call it four plausible endpoint monitoring systems — like antivirus, but for enterprise, when you’re deploying it on a hundred thousand machines at once. A large portion of the financial industry picked a system from CrowdStrike called CrowdStrike Falcon.
CrowdStrike Falcon had a bug one day in 2024 and took down a large portion of the largest US banks all at once — a terrible single-point-of-failure issue. And this is why we worry about software monocultures and about competition in critical industries. Theoretically, if you have 4,500 banks and one bank is down for a day, your economy can keep running. But when all the banks are on the same computer and the computer has a flu, you’ve got a problem.
Did all the banks get their IT departments together in a room and say, “We only go with CrowdStrike now”? No. What happened was a regulatory decision was made — under authority I’m somewhat unclear on — by the FFIEC, the Federal Financial Institutions Examination Council, which is a meta-government body that unifies five different government agencies that do bank examinations. They had an IT rulebook, and that rulebook had what I’ll call “strongly worded suggestions” for what a compliant bank would have.
When an examiner visits your bank in small-town Omaha, he’s not going to do bespoke engineering work. He’s just going to read from the strongly worded suggestions. And you, wanting to pass your bank examination and continue operating, will say, “Yes, absolutely, I will do all the things on the strongly worded suggestions.” One of those suggestions was basically: you should buy an endpoint monitoring software.
So as the bank’s IT department, you don’t have strong opinions on which endpoint monitoring software to have, but you know it needs to be the one that your examiner is going to say yes to. The natural dynamic in the market was that CrowdStrike’s sales and marketing department figured out: we’ve won a lot of financial sector business. We will win more of their business by writing collateral — white papers on our website about how buying our thing satisfies this specific requirement, and we’ll even pre-write your risk analysis that you’ll have to pass to your examiner. So we’ll help you check all the boxes, and in return for checking these boxes, you’ll pay us money.
Without anyone getting together in smoky back rooms, and while the other three endpoint monitoring solutions were focusing on e-commerce shops, the natural market dynamic was that CrowdStrike Falcon sewed up the financial industry. And then one day the financial industry went down from a single engineer bug.
Luke: The analogy is perfect to what I think happens in the government sector. That instance I mentioned earlier, where children were being kicked off their health insurance improperly? That bug was forked across 29 states, presumably from the same original code base that was first operated in one state. When they won another state contract, they kind of lifted and shifted and changed the branding a little bit. And we still paid full price for it, by the way.
Patrick: Full price. Twenty-nine times.
A long time ago in a place far, far away, I worked for a software consultancy, and yes — you are paying for the rewrite every time.
[Patrick notes: I was an engineer, and not a sales representative. Had I been a sales representative, I would of course have said that you’re not paying for the rewrite, you’re paying less because we will only be configuring the pre-existing software to match your unique business requirements.]
Luke: And again, that makes sense if you’re buying office space in Idaho and Michigan. But if you’re buying software in Idaho and Michigan, you could in theory benefit from — well, two instances of the same software you buy once.
So I think that created that same kind of single-point-of-failure dynamic. In SNAP, EBT payments processing is operated by two vendors, and that is a kind of single- or two-point-of-failure risk in that industry. The good news, compared to the financial sector, is that it’s the government that’s the buyer here. We set the rules of the road, and we can change the rules to help prevent some of this consolidation and bad outcomes.
For example, instead of doing a $100 million contract for software, maybe you can modularize your contracts — have someone build the front door that connects into the eligibility logic, and have two different vendors do that, with a more capable state managing those two things and making sure they’re integrated appropriately. There are pros and cons to an approach like that, but it changes the market dynamic.
And this is an example where the government is a monopsony, right? Like, we are the sole buyer. No one else is buying Medicaid eligibility software out in the world. So we can kind of set the rules of engagement around the kind of market we want in this sector. And it’s pretty clear that the current setup is not serving us well. The government has a lot of tools in its belt to actually change the market dynamics here.
Aligning program administrator incentives with successful service delivery
Patrick: Yep. And to exercise a bit of empathy for government employees here: the individual program administrator might say, “On a theoretical level, sure — government contractor reform, everybody is for it. And you might have an opportunity to do it legislatively every 20 years. But in between those 20 years, my hands are totally tied by the law.”
Even if I’m in charge of a hundred-million-dollar program or a hundred-million-dollar contract for a program that spends tens of billions of dollars a year, I can do nothing. I’ve got all the existing laws and regulations that I have to take care of, and I don’t own this outcome. There is no success case for this contract in which my life gets better. The only case in which my life changes as a result of this contract is if I break one of these laws — then I get in trouble. If a legislator notices, and I get a phone call, my job’s actually at risk.
If the program merely fails to deliver services to — I guess this is a two-part question, and maybe I’ll ask the big one later — but if we had that 20-year window open up for changes in what we want from government contracting, what would some of those changes be? And how do we change the incentive system for Bob — the program administrator — so that Bob’s incentives are aligned with the program succeeding, not just with avoiding getting in trouble?
I’ve met a lot of Bobs.
Luke: Same.
Patrick: And Bobs often say it’s calumny that people in the press and civil society think they don’t care about the program succeeding. They keenly care about the program succeeding. So without addressing Bob’s mental state — how do we change Bob’s incentives such that they’re aligned with the program succeeding and anti-aligned with failure?
Luke: Totally. It’s an excellent question. And shout out to all the Bobs out there, because you will find those people everywhere. People know this isn’t working, right? You won’t talk to a state Medicaid director who thinks things are going super well in their state. I’ve talked to nearly all of them. No one has ever said that to me. The folks who are in the procurement office or the IT shop feel hemmed in by the system they’re a part of. So you’re a hundred percent right that their hands are — or at least they perceive that their hands are — meaningfully tied.
Using in-house technologists to push back on vendor change orders
So how do you make those incentives better? I think one approach — and this is what I saw from my government experience — is hiring technologists into government: software engineers, data scientists, user researchers, product managers. Those people can call a spade a spade in a way that lawyers might not be able to. If a government contractor says, “Oh, this bug you want us to fix is going to take us a thousand hours and a million dollars,” a software engineer can share his screen and say, “I’m going to fix it in this 30-minute meeting right now.” That’s a really powerful tool for pushing back on the kind of day-to-day slog that Bobs everywhere are experiencing, where they’re not empowered with the skill set to push back on the contractors they’ve hired to do some of this work.
Patrick: There was a particular government contractor doing a thing — I won’t throw them under the bus, but I’ll throw this example under the bus — in the VaccinateCA days. They were contracting with the federal government under some authority. One part of that contract was: you need to produce a CSV file, and then we’re going to distribute it to a lot of places. The CSV file was materially about locations, and it became very useful for many consumers of that CSV file to have the latitude and longitude of those locations — which the organization clearly knew, because they were also producing a map as a different deliverable.
So: hey, can you put the latitude and longitude in the CSV file? And that organization said, “Yes, we can absolutely do that. We’re going to need a change order and six weeks of process to do it.” And I’m like, “Really? That’s two lines of code.”
So VaccinateCA — to accelerate the delivery of services to people living in the United States of America — went to the government and said, “Look, you’re also getting a file from us. We know the latitude and longitude of these places. We’ll just publish that, and then you can do the trivial SQL join to put the latitude and longitude together. Also, we’re going to go to the downstream consumers and tell them: hey, while you’re waiting for that, you can just pull it from this file, and you can trust us not to hallucinate them because we’re working from the same underlying data sources.”
So yes — it is very useful to have someone in the room with the authority to say: “Six weeks to do two lines of code? And you’re telling me you’re going to do six weeks of manual testing on it? Pull the other one, it’s got bells on. Let’s bring some adults into the room here.”
Luke: Yeah, I think that’s right. The folks who are at the table today are policy people and lawyers and analysts who might not be able to push back on a vendor who says, “Oh no, you don’t get it — those two lines of code really need six weeks of manual testing.” I think there is a huge amount of headroom in growing technologist state capacity, even just to push back on that. You see millions of dollars’ worth of change orders disappear overnight if you have even one software engineer, paid a reasonable salary, just to push back on those things every day. Huge ROI in bringing those folks in.
Shifting from "Big Bang" contracts to iterative, agile development
Patrick: I would also love to get them involved at the legislative stage — whenever we do this big contracting reform, if that ever happens, or even in the year-to-year business of updating regulations. Because there are some fundamental, difficult-to-fix issues. I don’t remember how many members of Congress are lawyers — it’s like 400-plus.
[Patrick notes: Overestimated by ~2X. Sorry, counselor(s).]
Lawyers are going to get really into fine distinctions of language and writing complex state machines, ba dum bum, but they don’t really have a lived feel for the software development process. So basically all of the Big Bang contracts assume you’re going to put 90% of the engineering effort in before launch day and only 10% for changes in operations — which industry has been screaming about since the waterfall-versus-agile distinction, which is 25-plus years old at this point.
That is not the way successful software actually gets shipped in the world. You ship the minimum viable product to start experiencing what users actually need, and then you change the software rapidly in response. Because attempting to identify all of the requirements for the software before you’ve spoken to users and shown them something they can play with is a fool’s errand. We’ve lost tens of billions of dollars chasing that fool’s errand, the private sector stopped chasing it, and the government continues.
And one of the things that has happened in some contracts is they say, “You must use agile development methodology,” which is then defined in a way that I would say describes waterfall, not agile — because that is apparently the controlling definition for the purpose of this contract. So we can all pretend that you’re doing what you want as long as you do the same thing you’ve been doing unsuccessfully for the last several decades.
Luke: Yeah. One positive example that comes to mind is IRS Direct File, which the US Digital Service helped launch a couple years ago. Instead of building a tax filing tool for all 200 million American taxpayers all at once, they did a pilot. They developed for a narrow set of use cases that were straightforward and could demonstrate product-market fit. Users really liked the tool — they got a net promoter score of 92%, which is a huge success by industry standards and an even bigger success by government technology standards.
They were able to build in a thoughtful, agile, pilot-driven way and grow the product over time. And they did that with an in-house government team — they had contractors who were mostly functioning as staff augmentation, software engineers pitching in and project management teams. But they were able to do it iteratively in an industry-standard way, as opposed to writing a $100 million contract that blew up in everyone’s face. As a result, users loved it, it worked really well.
It did get discontinued for political reasons. But I’m hopeful that one day it will come back, because that is a model for how you can actually do great human-centered design and product development that delivers for people. It can’t be the big-bang, contractor-led, $100 million debacle. It has to be a thoughtful, iterative, pilot-driven, user-research-driven process.
Patrick: I’m glad you brought up Direct File, because the experience of IRS tax filings is often misunderstood in the technology industry as being entirely dictated by Intuit’s lobbying budget — which is something like $6 million a year, a rounding error in terms of the broader lobbying spending, or the total amount of energy spent by United States citizens on their tax filings every year.
Without getting into partisan commentary, this is a political dynamic we see frequently in many different scenarios. The Groups, the people who are closest to the issue — the subject matter experts who are not directly in the agency — will often say: “I don’t want a good 98% solution, because I feel that a good 98% solution is going to drain the political will to address the last 2%, and I keenly care” — partly for objective reasons, partly for ideological reasons — “about that last 2%.”
In fact, they might care more about that last 2% than the 98%, because the reality is that people with complicated personal situations in X, Y, Z generally tend to have complicated situations all the way down. Some theories of justice will say: if agency A is doing the 98% solution, and agency B is doing the 98% solution, and agency C is doing the 98% solution, the people who fall through the cracks are going to be the same people every time. The government will work for most people, but not for the most vulnerable people in society, every time. [Patrick notes: The most common identifiable theory here is Rawls’ Theory of Justice but this moral intuition is quite diffused, to the point where it is almost a touchstone of the broader culture around service delivery.]
That argument is often advanced by broadly left-of-center people — although I am not left of center and I’m happy advancing it — and IRS Direct File is a similar case. You can read where the opposition comes from: it’s Americans for Tax Reform, a right-leaning group of policy entrepreneurs in the tax space, and Republican members of Congress basically take their marching orders from them because if Grover Norquist says you wavered on tax issues, your career as a Republican is done.
And what they say is: if we make taxes easy and people assume taxes are easy now, then the tax burden faced by small business members — voting members of our political coalition — is going to grow in an unbounded fashion. Their actual dollars-and-cents burden is going to grow in an unbounded fashion. Therefore, no half-measures, and certainly no experiments that aren’t specifically authorized by legislation that we had a hand in crafting.
So people of goodwill can say, in basically as many words, “I’m okay with the perfect being the enemy of the good.” And I think achieving political consensus that no, we should not let the perfect be the enemy of the good, is one of the large issues — not just with that specific program, but with other programs too: just shipping a simplified user experience as a first step. Not addressing every possible thing in the 60,000 pages of implementing regulations, but saying: “Okay, until you hear differently from us, just answer these questions. And that is probably everything we need to know.”
That’s the thing that happens in program after program after program. But it is difficult in the current configuration of the polity to allow program managers to take advantage of that.
Luke: Totally. I think there’s a political economy question implicit in what you’re sharing, but there’s also just the implementer’s perspective.
From the implementer’s perspective, I think there are actually a lot of use cases where fixing the 90% experience has enormous benefit for the 10% experience as well. In the case of Medicaid, my team drove around the country — red states and blue states — and was fixing the eligibility and enrollment software that helps automatically renew people for benefits if nothing has changed on their case. If Luke’s income is the same, my family composition is the same, my address is the same — I shouldn’t have to start from scratch and refill out a whole packet. The state should be able to check data sources to verify that fact, and then have my application automatically renewed for 12 more months.
What that does is remove an enormous burden off the beneficiary and remove a huge amount of casework off caseworkers’ desks, who can then spend — instead of five minutes per beneficiary — an hour working with a family that has more complex medical needs, or a mixed immigration household, or whatever the more complex situation is. It can remove the easy cases off the desk to the enormous benefit of people who have more complex cases. Even though you’re not able to automatically renew that more complex person, they still see huge benefit from the system being more efficient overall, because now they can get through the call center in five minutes as opposed to eight hours.
And so I think there are really nice downstream effects of improving the efficiency of some of these programs. In the case of Direct File: there might be enormous benefits for small business owners if the IRS is less focused on troubleshooting personal tax filings for individuals and can better serve businesses.
There’s a political economy question about whether if you make programs better, people like programs more — and I think that’s a good thing, right? I don’t think it should be pain and suffering to get your health insurance through Medicaid. I don’t think tax filing should be really, really painful and horrific because we’re all legally required to do it. The downstream consequence of those arguments feels like people backing into making services worse because they might not like other parts of the program — and I’m less sympathetic to that.
Patrick: You might be better acquainted with the literature than I am, but I think there’s an academic argument advanced about rationing via friction. The numbers matter. We have a few levers available. One is eligibility criteria — you can choose those criteria to express some of society’s complex preferences about what level of subsidization for what people, what level of political economy is embedded in the process with the “deserving poor” rationale, et cetera.
Another lever is: in every program, not everyone who is eligible takes advantage of it. The conversion rate from eligibility to actually submitting an application is a huge driver of program cost. The acceptance rate and continued application for benefits is another driver.
So maybe without people explicitly deciding this — but if everyone could successfully, say, one-click apply for benefits, the amount of benefits we could afford without getting political blowback is relatively low per beneficiary. If it’s higher-friction, then some people will select out due to the friction, and then people in the know or connected to the right people will be able to get more dollars allocated to them, or will go through the blessed pathways that NGOs have built to navigate people through this process — which also creates jobs for members of political coalitions, and so on.
There are some difficult trade-offs here. But I said before the call, and I think it holds: people from a huge part of the political spectrum can broadly agree that government services should be generally pro-dignity and should generally work. If they don’t work, what are we doing?
Luke: Yeah, I agree.
Patrick: So. You wrote a paper recently about the Means-testing Industrial Complex. I’d love to talk about the object level of that — partly for you to tell people about something that comes up again and again, and partly so that we can have a discussion of why this keeps happening.
Luke: Totally. Just to start where you started: administrative burdens — and there’s great literature by Pam Herd and Don Moynihan on this topic — are a knob that policymakers turn to either increase or decrease access to a program without necessarily saying, “Oh, we don’t think pregnant mothers should get Medicaid, but we’re going to make the paperwork really hard, so maybe they’ll be less likely to get through.” It’s a kind of alternative policymaking that happens below the surface. It’s complex and under-discussed, but a really important reason why benefits are either easy to access or not, and why government services are great or they’re bad.
[Patrick notes: Pamela Herd and Donald Moynihan, Administrative Burden: Policymaking by Other Means (Russell Sage Foundation, 2018). This is the standard reference in the field.]
I think the job of being in government is to reduce those burdens and to be more clear about what the program you’re trying to design is and who it’s for. In the means-testing industrial complex piece, I lay out how the complexity of these systems that has grown over time has become a surface for capture by vendors and by contractors. The more complex we make these rules, the more complicated the software needs to be, the more boxes that need to be checked, the more surface area for contractors to embed themselves and grow the complexity further. I’ve seen some code bases that would blow your mind — and I’m sure you’ve seen some yourself — where you would never engineer this thing to look this way if you were looking for the most efficient path.
The moral incoherence of asset limits
Patrick: Just for the benefit of people who don’t live in benefits world for most of their lives: “means testing” is a term of art. It refers to the broad perspective of the US polity that we want to give benefits to people who are in need of them, and both for cost-control reasons and for the value system of the United States of America, we don’t want to give money to people who don’t need money. So you need to be able to prove that you’re not someone who doesn’t need money.
Means testing will often have an income component to it, or a wealth component to it, where you need to prove to the government what your income is and document your wealth and sources of wealth, such that they can do a relatively deterministic calculation on whether you are above or below the line.
I say “relatively deterministic” because the actual implementation of some means testing gets into some genuine craziness. A great example that I think I’m borrowing from Dave Guarino: everyone will need to make final arrangements at some point. Often that involves buying a burial plot. A burial plot is, technically speaking, real estate. And real estate has a cash value attached to it. So if you’re older in years and are asked the question “Do you have at least $2,000 worth of assets?” — if you’re looking at a bank account that says $67 in checking, you might still have $2,000 of assets because if you’ve planned ahead, you have a burial plot you’ve paid for and ready to go.
You own $2,000 of real estate. And it’s probably no one’s moral intuition that because this person has made prudent choices in planning for their end of life, they should not be eligible for government services. But the combination of how we’ve layered the regulations says: we made the decision that if they have $2,000 of assets, they should be selling those assets before accessing this program. We didn’t explicitly say “sell your burial plot.” We just said “assets.” But the law considers that no different than if they had $2,000 worth of Google stock.
And thus we end up with a morally incoherent result that we ask of people. It also means you have to ask every potential beneficiary: “Have you prepaid any burial expenses?” That’s in the book of things we need to ask about. So we’re imposing marginal friction on everybody with respect to this one edge case that I think in their heart of hearts, no one who matters in the American political system would actually say means that prepaid burial expenses are obviously a sign that you’re super rich and should be outside the scope of government services.
[Patrick notes: I misattributed this in the audio. The burial plot example is from Jennifer Pahlka's Recoding America (2023), not from Dave Guarino. Dave was interviewed in the book in a separate capacity.]
Luke: Yeah, exactly. And there are a ton of examples like this, where well-meaning policy proposals — like “there should be an asset limit for those who receive SNAP or non-MAGI Medicaid” — trickle down through the system of legal interpretation until suddenly, having a burial plot is disqualifying you from food benefits, even though you can’t really trade a burial plot for groceries very easily.
These well-meaning intentions to design programs for specific populations can end up getting really complex and causing all sorts of problems for beneficiaries and access, and aren’t the programs we wanted to design in the first place.
So one of the arguments I make in the piece is about universalizing programs more fully. One example from during the pandemic that’s persisted is school meals for children. Many schools and states have moved to universal in-school meals for kids. Before, the status quo was that you had to be deemed income-eligible to receive free and reduced lunch. So you would have kids in a separate line who are getting their free or reduced lunch — and if mom or dad forgets to fill out the form, now they’re not eating at lunchtime. There are all sorts of bad consequences from theoretically wanting to target this program at low-income kids.
When you universalize the program, it actually doesn’t end up being that much more expensive. You get all sorts of great second-order effects. You no longer need the clerk at the school monitoring every child’s income to determine eligibility. You no longer need a separate line for kids who are paying a quarter for lunch versus getting free lunch. It removes this eligibility infrastructure that needs to exist, and it has all these nice second-order effects: parents are less stressed, parents who could afford to pay for their child’s lunch no longer need to pack a lunch and do as much grocery shopping. It’s a relief on their family’s weekly budget, even though they might not have otherwise qualified for the program.
Patrick: There’s a dignity element to this that I think is really strong, which I’ll illustrate with something minorly personally embarrassing — though it really shouldn’t be embarrassing.
I’ve had money in life and not had money. A long time ago in a place far, far away, my family was in similar circumstances. There was a field trip that cost $10, and $10 was a lot of money for my family that week. But we still wanted to send me on the field trip. The school said, “Good news — it’s $10 for everybody in school unless you qualify for low-price lunches. If you qualify for low-price lunches, it’s free. Just fill out this form. You don’t have to actually eat a low-price lunch.”
That form got sent home, and there was a discussion between my parents. I won’t throw either of them under the bus, but one was like: “Patrick wants to go on the field trip. We can’t spend $10 on it. Filling out this form gets him on the field trip.” And the other parent was like: “No. Filling out that form is an acknowledgement that we have failed as parents — that our child can’t even afford food.” Which, to be clear, was not really the situation. We were not that close to the line. But we were close to a different line — the socio-culturally fraught line of saying, “I’m the kind of person who needs help right now.”
There are people who are unable to take advantage of something which is basically free to provide at the margin. I think people can have a reasonable discussion every four years, on whatever cadence, about where we set the taxes-versus-benefits slider. That’s the point of politics, and I’ll leave that to other people. But I think basically everybody on the spectrum agrees that people should not be crying about these decisions. We should, as a society, be pro-dignity with respect to people navigating these challenging circumstances. So where program design is causing us to compromise on dignity, I would hope we do something differently.
Luke: I think that’s exactly right. And I don’t think that’s a unique experience.
Patrick: Oh, very clearly not unique. Many, many folks have ones that rhyme with it.
Luke: Totally. Millions of Americans’ incomes fluctuate over time, and the system moves too slow to catch them. There are months and gaps where kids aren’t eating, they’re not getting healthcare, they’re not able to go to the doctor or get their prescriptions.
When we were traveling around the country, we met a lot of those families. The idea that we would put burdens in front of them to access programs that we all pay for — because we all might be on them at some point or another — there’s a reason we build these social insurance programs. They keep society strong. They care for the most vulnerable. And the most vulnerable could be me, it could be you, at any point. I think that is a core part of why we need to build dignity into the administration of these programs, because it’s part of the social fabric that we’ve built over so many years.
And the way we advance it is by simplifying that machinery, so that the industrial complex around eligibility determination and means testing is not just kicking people off the program, but also not giving them an undignified experience — being in a separate line in the school cafeteria, or going to the doctor and finding out they lost their coverage. At the end of the day, it’s about building an experience that is what we expect when we interact with any private-sector company. We would never tolerate an experience like that elsewhere, and we shouldn’t tolerate it from our government.
The way we can improve these programs through reducing administrative burdens and universalizing them where possible and where it makes sense — it’s not just an inefficiency argument, though we can make that all day. It’s also a dignity argument.
Patrick: I think there’s a kind of barbell with respect to the experience of income volatility. People at the lower ends of the socioeconomic spectrum have rather substantial income volatility. This is also true of people at the higher ends — stock-based compensation, they run businesses, et cetera. But the great majority of the population conceives of income as something that happens every two weeks on a very predictable schedule and is recorded on your W-2. And therefore, how hard is it to demonstrate your income to a government process? It’s actually distinctly non-trivial at either end of the barbell.
Folks at the higher end of the socioeconomic spectrum understand that keenly with respect to taxes — they don’t care about it so much with respect to low-price lunches, because that isn’t relevant to their interests. But when we talk about income verification for people in more typical circumstances: the person is theoretically speaking employed at a franchise, let’s say McDonald’s. They have an inconsistent number of hours given to them by their management every two weeks, so income fluctuates on a biweekly basis. They’re also what the government says is running a small business — they’d say, “No, I’m a driver for a rideshare. It pays me money occasionally.” But from the government’s point of view: “No, you’ve got a small business. That business has revenue and expenses, so you need to be able to calculate what your profit was. Because profit is income — not the revenue, but the profit.”
And people elsewhere in the socioeconomic spectrum who actually run small businesses might say: bookkeeping and accounting for a small business is intellectually non-trivial, and on a month-to-month basis I don’t really know what the business is making until I do my taxes at the end of the year. Asking that of someone who is more sociologically similar to a rideshare driver than to, say, a software consultant — that’s a really rough ask. And yet we do it, and perhaps should consider either not doing it, or electing some sort of safe harbors.
Like: “If you have a rigorous calculation about the profit of your ridesharing business, we’re all ears. If not, click here to link your rideshare app. We will pull the gross number out of it and deem 70% of it as the profit, and you can pick whichever is better for you.” I think more people would actually succeed in doing that, and it would stop us from wasting the time of very expensive people in government going back and forth with prospective beneficiaries over: “Okay, bring your box of gas receipts. I’ll be your overpaid bookkeeper while we spend hours together walking through whether you are above or below the $500-a-week line” — or whatever the threshold is for the particular program.
Luke: Yeah, income verification is another thing I talk about in the piece, with respect to Equifax — which is a provider and aggregator of income data about American workers. It’s a great example of how our over-reliance on these verifications, which are very complex, has resulted in consolidation around one market leader who’s now bleeding the government dry. And it’s not only a painful experience for folks who need to bring in their receipts and pay stubs and figure out if they qualify this month versus last month, while their household budget is all out of whack. We’re not providing an environment where they’re even able to work capably, because they might need to go into the office and miss additional hours, or maybe they’re sick and need healthcare they’re not accessing, which actually harms their ability to work.
Patrick: Can I say a few more words about this particular database? Because this system is geeking me out — and who doesn’t love mortgage underwriting?
I think it’s instructive why the system exists. You have an HR department. The HR department has many responsibilities: Tim and Cindy are having a bit of an interpersonal conflict and you need to resolve that, you need to prevent the company from taking on liability, run the annual training. And then occasionally employees are going to say, “Hey, I applied for a mortgage with Bank of Bigness, and Bank of Bigness is going to need to call and verify what my salary is.” And the HR department would prefer to do anything other than answer that phone call, because they get hundreds of them a year for an employee base of hundreds of people.
It’s a waste of their time. It’s also a bit of a risk: if a jilted ex-lover calls up and says, “Hey, this is the Bank of Business underwriting department, how much does Cindy make?” and you give that information out — now you’re legally liable for having disclosed it.
So Equifax called up the employers and said, “Trade proposal: in lieu of you ever having to answer that phone call again, you tell people to call us. We will do the ‘is this person not an ax murderer’ screening for you, and then we will give out the number only to people who pass that screening. You never have to take the phone call anymore. And we won’t charge you for the service.”
So who do they charge? They charge the mortgage companies, the banks. And the federal government — because when the federal government says, “Hey Bob, to get access to these government services you need to verify what your income was for the month of March,” in lieu of Bob going out and getting his W-2 and pro-rating for the number of hours, yada yada, all Bob has to do is point at Equifax. And Equifax says, through the magic of SQL, “We have determined that their payroll department said that exact number was X.”
So I’ll express a bit of qualified disagreement with the piece, because the piece makes much of Equifax being a monopoly here and ripping the eyeballs out of the American taxpayer by charging $15 for SQL queries — which is true, they do charge $15 for SQL queries. But this is part of the efficiency of automated government services. In lieu of pushing all the work onto Bob — “Bob, you need to go have a perhaps uncomfortable discussion with your HR department about why you need that number mid-cycle, and explain that your daughter’s sick and you need X and Y and Z” — we have an entirely impersonal discussion orchestrated by computer systems at scale, and then the government pays a bill for that increased efficiency.
So that is the brief context for this thing. But as you develop in more detail in the piece, Equifax is basically the sole source for this income verification for a variety of federal and state programs. And among other implications of this, they can charge whatever those various programs will agree to for access to this number. It turns out the federal government pays, I think the number you cited is around $4 for this SQL query, and then different state governments pay $15 for the same SQL query on the same individual run at essentially the same time. There are reasons for that. But lay out the backstory for the issue you go into in the piece.
Luke: I’ll start by saying I’m also very glad that electronic income verification exists in the world. It’s just a way better experience for employers, and a way better experience for beneficiaries — the government can just query a database and find out what your income is, as opposed to having you come in with your pay stubs for manual verification.
The challenge is who owns that database. We’ve decided to pay a private company to acquire the exclusive right to income information for over a hundred million American workers, allow them to establish market dominance, and then basically pay whatever they say we need to pay for that query.
The good news is the federal government already has a relationship with businesses across the country through its tax authority. We already know what employers are paying their workers, and we know the wages workers are making on the other side of the house of government. The proposal here is not to stop doing electronic verification — it’s to do electronic verification inside of government, instead of paying upwards of almost a billion dollars every year to a third-party data broker. There are all sorts of interesting ways you could do that. It’s complicated and a great problem to tackle. But I totally agree with your base case that electronic verification is the superior user experience. The question is who is providing that experience and for what price. And I think we can get a much better deal.
Insourcing electronic income verification databases
Patrick: And you also mentioned the possibility that — yes, this is a monopolistic provider, but we’re a monopsonistic consumer. Not exactly monopsonistic, in that there are private-sector users of this database: mortgage brokers and similar. But given that we’re buying hundreds of millions of API calls at once, we could get a better deal if we negotiate as a block, versus having the state of Kansas’s department of something negotiate its contract, and Health and Human Services negotiate its contract at the federal level, and the state of Nebraska have an entirely different negotiation, yada yada, all ending up paying different prices.
I’ll say in defense of the contractor — having been a prospective contractor myself — there is a reason for this. You gave me this book of 60,000 pages of regulations and said I have to be compliant with all of it. And it’s a different book for the state of Nebraska versus the state of Kansas. One of the things you are paying me for is to understand the differences in those books. So even though it looks like exactly the same service at the SQL query level for the state of Kansas and the state of Nebraska, it’s a very different service actually being offered. And different service means different prices. Or you can tell me you’ve gotten rid of all the laws of the state of Nebraska and the state of Kansas in the last two years, and then I’ll be able to give you the one-size-fits-all price.
But putting that argument in their mouth — it is a pretty compelling one. And for some reform here, we need to choose to want different things. We should choose to want more efficiency, more dignity, and maybe choose to want a bit less of the regulatory state that we’ve developed. If there ever is a reform effort, I just hope it doesn’t become the 70th year of additional sedimentary layers, where in lieu of repealing anything, we’re just going to build another set of patches on top. And now instead of 60,000 pages of regs, we’ll have 75,000 pages, and those will be the last 15,000 pages that anyone needs to read.
Luke: “I promise it’s just one more lane, bro.”
[Patrick notes: This is a reference to an Internet meme popular among transit geeks, where the highway system deals with capacity problems by expanding just this once. Spoiler: the person making this prediction will not be negatively consequenced when it is falsified, much like every previous prediction in this genre.]
But on the adding-regulations-on-top point: I think quickly to the first part of what you shared — these contractors need to spread costs into an API call as the thing that’s being charged, right? Procurement costs, legal costs, compliance costs, and what they’re charging for is an API.
So it might be higher than what you would expect as a private-sector procurer of those services — totally agree. But I think it’s the magnitude question. Them quadrupling their prices in a six-year period, I think, is pretty strong evidence that those compliance costs didn’t radically change in that period. Their ability to extract profit did. So I think the magnitude is what’s actually the issue. I appreciate that there’s going to be a little premium to deal with the government, but the change over time is what points to something else.
Patrick: That’s pretty instructive and matches my experience from the contractor side, where when I was bidding $30,000 and thought I really couldn’t go lower than that, one of the reasons to bid low and get in the door is: okay, in the second, third, fourth year, maybe you assume you’ll be able to walk up the prices, and that no one is going to rip out the software over aggressively walking up the prices.
Luke: Yeah, that’s exactly right. There are lock-in effects that are kind of standard. And then there’s what Equifax is doing, which is pretty spectacular price hikes across the board relative to their prices even just a few years ago — and doing that across all those jurisdictions you mentioned, from local government all the way up to huge contracts with the federal government.
And then there’s the redundancy across those contracts. If Luke loses his job and wants to apply for unemployment insurance, needs food benefits for his family this month, and needs Medicaid — those three services might all be pinging the same person at the same time for the same bit of data, getting charged different prices, all to the same vendor. Which is a spectacular example of how the silos in the government technology stack also come back to bite us.
Greater transparency, government to government, would help a lot. There was a New York Times investigation into Equifax increasing prices on state governments, and it was the first time a lot of state governments I talked to had seen anyone else’s price — what other states were being charged by Equifax. And they were like, “Oh my God, I’m getting held over a barrel here.” Just at the level of coordination across different entities, there’s a huge amount of savings to be earned.
And this is kind of coming back to our IRS Direct File conversation — we can insource and build a lot of this inside of government for a small upfront cost that ends up saving us a billion dollars a year in perpetuity on external pings. But it requires a little bit of investment and courage to do it the first time right. And I think it’s not even the dollar amount that’s scary. It’s the kind of courage required to take on a hard new project.
Building public sector competence to manage modern technical risk
Patrick: The thing I hear over and over again from people in Washington, DC — and I’ll acknowledge that there have been efforts to change this by people like the US Digital Service and similar over the course of the last 15 years or so — but the rollout of healthcare.gov, the Affordable Care Act website, back in 2013, was deeply scarring to the policy community in DC.
The received wisdom after the healthcare.gov rollout is that you can be a well-loved president and have your signature initiative and legacy tarred — if those crazy geeks don’t get their act together. And therefore: never be in the position as the government where you’re bearing tech risk. Always have a contractor. And when things inevitably go wrong, throw the contractors under the bus, and you walk out with your reputation intact.
I don’t think it’s a very partisan point of view to say: we have to be good at doing what we do, as the government or as the private sector. And you can’t be good at doing what you do without competence in software in the modern world. Therefore we should have that competence internally, and at least be able to identify it in external partners — versus just saying, “Well, we’re all lawyers, we can’t tell the C from the PHP, et cetera, et cetera. That’s somebody else’s problem. I’m paying them a billion dollars a year so that they are made fun of in the New York Times and I’m not, when this inevitably fails.”
[Patrick notes: Previous podcast guest Mikey Dickerson was instrumental in the so-called “tech surge” to fix the rollout, and ended up being one of the early leaders at the US Digital Service. I continue to believe that story needs a better book-length treatment, and good news, Mikey and coauthors have a book coming out which addresses it in part later this year.]
Luke: Yeah, no — I think that’s exactly right in defining the incentive structure around this. It takes real public sector leadership to do something here.
When I was at the White House, I had leaders who had my back when I was building something that was internal and higher risk than the normal “cut a million-dollar contract for Deloitte to go do it.” IRS Direct File, for example — they needed real leadership buy-in, which wasn’t easy to get, to go pilot something and build something new.
And I think it really requires public sector leaders — whether it’s governors or secretaries or mayors — to really lean forward and say: “We’re going to demand public sector excellence here. We’re going to demand that the IT stack is built in a modern way that provides dignity and efficiency for folks on the receiving end.” There’s kind of no way around just needing leadership who is willing to take that risk.
And it’s one that we know the stakes of the status quo: it’s millions of people not getting their healthcare, families not being able to go to the doctor who should otherwise be able to. It’s sending billions of dollars out the door to bad contracts. That’s a status quo we’ve become comfortable with. And I think it’s on public sector leaders to say that’s actually a worse trade-off than trying something new.
Patrick: Increasing competence and the Will to Have Nice Things in the American government will always be relevant to my interests.
I feel like we could continue discussing this for another several hours, but unfortunately don’t have that time available on the schedule. So Luke, where can people follow you on the Internet?
Luke: Sure. I’m LukeF on Bluesky. On Substack, I’m Luke Farrell. I’ve really enjoyed talking about this — I could nerd out about government contracting all day.
Patrick: Likewise. Well, thanks very much, Luke. And for the rest of you, thanks very much, and we’ll see you next week on Complex Systems.
