Scale funding is poison when you're actually growing
Non-profits often can't influence enough of their problem space to create scale, so we must fund them for growth not scale, which means the funding can't just end.
With the closure of Benefits Data Trust (BDT) happening as several “Scale” grants ended their funding cycle I wanted to think through what scaling means and why it seems to be so deadly to previously well situated non-profits. I want to start with the disclaimer that I was only at BDT for the tail end of the work funded by scale grants. I also have no insights into the finances of BDT, nor the grants in question. I don’t know what was agreed to in exchange for the funding, how that got explained to the staff, or what conversations were had with funders as the work progressed. But having been around the sector and having been in the leadership/C-Suite in a prior role, I have some general observations and insights to share.
First some background. BDT announced funding from a group referred to as the “Scale funders” around 2019. You can read how that funding was described contemporaneously via a MasterCard Press Release (archive.org) among other places. There’s several references to “scale” and “impact” and these are common phrases in non-profit circles. But what is scaling and what is growth?
In the technology realm, scaling is used to describe infrastructure that can adjust to spikes in traffic, interest, popularity. It often takes the form of throwing money at the problem. Run more copies of the software, or pay more for additional resources for a database server that is the temporary bottleneck that is keeping users from accessing the site, buying the thing, or otherwise completing their task. This differs from growth, in that scaling is elastic, you scale up, you scale down, you expand and contract around a relatively fixed average point. You don’t scale, year over year, quarter over quarter, or month over month. When your baseline or average is higher now that it was last month or last year, that’s growth. You’ll never claw that back. Your bill will never go back down (unless your cloud vendor cuts prices, LOL). A new baseline is growth, not scale.
This is a pedantic but important distinction. Because while scale implies you’re doing more with less, or that the change is temporary, growth is forever. You can’t support growth on a 5-year grant, because at the end of 5 years the funding is gone and the growth in expenses (and impact) remains. None of this is to say growth is bad, but it’s linear and represents ongoing costs, another employee, another server, another location. Scale is often about throughput, but growth is often about capacity.
Self-checkout machines are a great example of this distinction. In the space of a single regular staffed checkout stores often fit 2 self-checkouts. (Side note, self-checkout is bad for workers, bad for shoppers, good for owners, but that’s a separate post) So now the store has doubled the capacity of that checkout aisle. 100% more checkout capacity sounds great doesn’t it? But do you get twice as much checkout throughput? Do twice as many shoppers checkout each day using those two self-checkouts as in a single aisle with a cashier? No, of course not.
We don’t know the codes for the fruit and vegetables. We don’t know where the barcodes are located on the different boxes. We don’t know how to make the squishy or wrinkly barcodes scan. We don’t know how to best pack the bags so they don’t keep falling over. We have to “place the item in the bagging area, remove the item from the bagging area, place the item in the bagging area.” Fucking bagging area!
So there’s nowhere near twice as much throughput, even though there can be two people checking out at once. If anything you might halve the original throughput while doubling the original capacity. And you have a line of people 10 deep down one of the shopping aisles, because there’s no place for them to wait in an organized way like if they were one extra person in each of the 10 staffed lanes. In a lot of ways, public entitlement benefits resemble the self-checkout. Giving constituents a web site or paper form they don’t use regularly, don’t understand the nuances of, and (often) don’t want to be forced to use on their own, is clearly not a way to ensure high completion rates, and successful applications for benefits.
Benefits in the US are funded federally, but administered at the state, and often county level. Part of this is good, you want local control and insight in your systems. But Republicans have long supported this setup because they know it makes the systems harder to navigate and weakens the safety net. There is no “right answer” for SNAP. There are at least 50 right answers, and likely even more considering county and municipal level differences. The Federal funding means that Congressmembers can threaten and mess with hungry people’s lives even though they represent completely different parts of the country. So it’s more confusing and more precarious — minefield as safety net. This is common in our political system, but there’s a less obvious side effect as well. This balkanization makes scale impossible.
The way the system is setup and administered means you can’t “support SNAP,” or any other national benefit. Maybe you can support 80% of SNAP rules across all 50 states. In doing so you’d still help millions of people. But another landmine intentionally placed in the public benefits system is that if you incorrectly receive benefits, you can be barred from receiving benefits in the future, and even face criminal prosecution. So can you really roll out an 80% solution? What if that 20% you’re wrong on is having people incorrectly apply for a benefit they aren’t eligible for? Or worse, what if your classifications for income are wrong so it’s not even that the person is ineligible per their application, but they appear eligible because your software didn’t count income they should have reported. Did they lie on their application? Is your organization committing benefit fraud on a national scale?
Even if you could figure out 50+ eligibility mazes, there are application differences once you believe someone is eligible. To “support SNAP” you’d need to implement applying via: online forms, mailed PDFs, faxed PDFs, paper with wet signatures, APIs, … And not just once. Each state has its own online form, or has no online form. Cities have their own APIs or online forms or PDFs. You can’t scale this. You can grow, adding more staff, to set up and maintain all these pipelines, understand the nuances, walk clients through the different and incompatible processes. But that’s ongoing work, ongoing cost, and completely incompatible with a 5-year grant cycle. And that’s just to support one national benefit. Now add in a city’s rent or childcare benefit. Add in the local utility’s heat assistance application. How do you apply to stop a water shutoff? Privately funded Universal Basic Income (UBI) pilots. It’s definitionally anti-scale.
To scale you’d need alignment, uniformity, generalization, standardization, adoption. You need an API, not 50+ APIs. You need to know that all SNAP applications can be filled into this e-fillable PDF that every state can directly ingest data from, not fax that PDF creating even more paperwork that someone has to re-key into yet another closed system. You need alignment on what types of income count, on who is part of a benefit household. That’s unlikely to happen at the federal level given the pain is intentional, as noted above. States that care about their residents could band together and agree on eligibility criteria, application formats, data standards. Given our broken politics, this feels like the most likely path forward. But how do we fund this shared work across multiple states, counties, and municipalities? This is different from the money funneled through states to beneficiaries. We need digital infrastructure investment, both the skills and expertise to build it, but also the ongoing costs to run it.
And just to be clear, this isn’t just one party causing problems. New Jersey has a fully Democratic state government. In fully Democratic Essex County, in non-partisan (but Democratic) Newark, the Police Department has a consent decree with the Department of Justice. As part of that agreement they needed to implement better data collection and analysis capabilities. So they were planning on spending $31 million on such a system, for just one municipality of 564 in the state. At the same time, the NJ Attorney General is struggling to get police departments to reliably report use of force, discipline and other key data points to be analyzed across departments, including to spot issues that require the AG to investigate or require corrective measures. The NJ State Police had their own consent decree and needed to adjust their computer systems to gather data in a different way (and they’re still not doing what they’re legally required to). But we don’t have a statewide police software platform, despite single party leadership all the way down the stack. I don’t think I even have to explain how a single statewide system best threads the needle of reusability and standardization and local configuration and nuance. And we could have that for far less than 31M x 564.
There’s plenty of blame to go around. We need political leadership to invest in software and online services as infrastructure for our government services to be built on top of. We need philanthropic funders to invest in software and technology staff like we pay to maintain infrastructure. It’s an ongoing, and likely slowly growing expense that non-profits need long term help with, not a short term, time bound thing that can be paid off once. AWS gives non-profits one year of credits to build on their platform and then you pay full freight. That sounds a lot like the first hit is free. The solution to both of these problems is more open source and community source style software endeavors. But the policy, standards, and requirements need alignment too, otherwise you’re building bespoke, custom, Frankenstein software in a public GitHub repository which doesn’t really help the next state or the next benefit.
This isn’t unique to technology, I’m just enmeshed in that world. You can’t invest in extra beds in a shelter, or extra meals in a soup kitchen for 5 years either. Unless you’re funding policy changes that build more housing and address food insecurity so that those problems are smaller 5 years out. That’s not how funders like to think, and it’s not how they like to fund. But that’s the reality on the ground. Non-profits know it, and they constantly try to show/tell funders this reality. So we need folks to listen.
Thank you for this insightful analysis. It suggests that the strongest theme for a non-profit such as the one I’m working with is enablement: we enable our volunteers to do more on the mission than they could do on their own.