A wall of frustration

Simulation as a tool

In 2008 I took a course at UC Berkeley that would end up shaping my career: IEOR 131, Discrete-Event Simulation. The premise was elegant. You model a complex system not as a set of equations but as a collection of individuals moving through states—simulate a hospital emergency room by tracking each patient's arrival, each nurse assignment, each treatment decision, and then change something, add a nurse or reorganize triage, and watch how the whole system responds. Instead of writing an equation for the average wait time, you built the room and let the wait time emerge.

The course ran on Excel and Visual Basic for Applications, and its examples were resolutely operational: healthcare facilities, manufacturing lines, service queues. But the conceptual frame stuck with me long after the syntax faded. You could understand the emergent behavior of a system by simulating its individuals rather than modeling its aggregates—and the behavior you got out that way was often one you would never have guessed from the averages going in.

My first internship put the idea to work. At Finelite, a lighting-fixture manufacturer in Union City, California, I used Matlab to simulate production decisions. Should the plant pre-cut wire to standard lengths or cut it to order? How should the assembly lines be sequenced to minimize changeover time? The questions were small and the models were simple, but they worked—computational experiments that surfaced non-obvious facts about how a factory actually behaved, facts the plant managers recognized once the model showed them but hadn't been able to see from the spreadsheets alone.

After two years in consulting, I joined Google's People Analytics team in 2010—a group whose premise was that decisions about people deserved the same standard of evidence the rest of the company brought to decisions about products.

Project Lorenz

In 2012 a colleague and I founded a small data-science team inside People Analytics. We built tools across natural-language processing of employee feedback, social-network analysis of the org chart, and—my piece—simulation models for workforce planning.

Google's staffing group processed between one and two million job applications a year. Hundreds of recruiters managed thousands of open roles across divisions with very different hiring needs, and leadership wanted to project headcount growth against targets in a way that accounted for recruiting capacity, candidate pipeline dynamics, internal mobility, and attrition. The existing tool was a set of spreadsheets: functional, but blunt. I talked leadership into letting me try something different, a bottoms-up simulation I called Project Lorenz, after Edward Lorenz, whose pioneering weather research had shown how micro-level dynamics could drive macro-level phenomena.

I built it on microsimulation principles, though I didn't yet know to call them that. Model candidates entering through different channels; estimate the probabilities of moving between hiring stages using survival models—the same statistical machinery health researchers use to predict disease progression, repurposed here to predict how a candidate moved through Google's pipeline; account for variation in recruiter productivity, for attrition, for transfers between divisions. I implemented it in R, used Monte Carlo methods to quantify the uncertainty, and had it produce not a single number but a distribution of outcomes—a spread that captured how genuinely uncertain hiring dynamics are, rather than pretending to a false precision.

Project Lorenz never fully materialized. The complexity proved hard to manage; there were too many moving parts, each reasonable on its own but producing unstable results once they were wired together, and I could never quite get the integrated model to behave—a small change to one transition probability would ripple through the whole thing and hand back a headcount forecast that no one believed. We ran the spreadsheets for another cycle. But the conceptual seed was planted, and it survived the failure: complex social systems could be understood by simulating individuals and their transitions through states, even when a particular attempt to do so fell apart. The idea was right even where my execution wasn't.

The personal motivation

My interest in economic policy became personal through my brother Alex.

In June 2004—a month after my high school graduation, two months before I left our Menlo Park home for UC Berkeley—Alex suffered a spinal cord injury in a mountain biking accident. He was sixteen; I was seventeen. He became a quadriplegic, dependent on attendant care for the daily mechanics of living, from cooking and cleaning to getting in and out of bed.

Like me, Alex went to Berkeley, earning an undergraduate degree and then a master's in public policy. And when he entered the workforce, our family ran headlong into the question of how his benefits would interact with his earnings.

Medicaid covered his In-Home Supportive Services—attendant care that would otherwise have cost tens of thousands of dollars a year. But Medicaid had an income limit. If Alex earned more than roughly $70,000, he would lose eligibility; his medical expenses would then become tax-deductible, but the trade was brutal, and he would have had to earn something like $160,000 for the added income to make up for the coverage he had lost. Across that whole range, the effective marginal tax rate exceeded 100 percent—the arithmetic our spreadsheets kept producing, no matter how many times we rebuilt them looking for a way through. Earning more would leave him worse off, and the system offered no way around it.

We modeled scenario after scenario, and the complexity was overwhelming: tax brackets, benefit phase-outs, deductions, the interaction of state and federal programs, each rule sensible on its own and the combination punishing. The tools to understand how policy actually landed on one person's particular circumstances simply did not exist; we were building them from scratch, badly, in a spreadsheet, for an audience of one.

And none of it was visible from the outside. A poverty statistic or an average tax rate would have shown nothing of what Alex faced; his cliff lived in the interaction of specific programs at a specific income for a specific person, and you could only see it if you modeled that person directly. The aggregates were silent about exactly the thing that was reshaping my brother's decisions about whether to work.

This was my introduction to what economists call means-tested benefit cliffs and implicit marginal tax rates. For the person living inside the system, it was just a wall of frustration.

The UBI thread

Around the same time, the conversation inside Google was turning to technological unemployment, to what artificial intelligence might do to the labor market, and to whether society needed new institutions to guarantee basic needs as automation advanced. Some people were talking about universal basic income—unconditional cash payments that could put a floor under people without the means-testing that produced cliffs like the one Alex faced. For someone who had just spent months watching a means-tested program turn earning into a trap, the appeal was both obvious and personal: a floor you could not earn your way off of.

In 2012, Google.org gave GiveDirectly a $2.4 million Global Impact Award .^[1] The organization was making unconditional cash transfers to extremely poor households in Kenya—families living on roughly a dollar a day receiving about a thousand dollars, no strings attached—and, as economists, its founders were running randomized controlled trials to measure what actually happened when you did that. The results were encouraging: gains in earnings, in assets, in nutrition, in educational outcomes. I volunteered with them on the side, helping them use their data more efficiently and hosting their researchers for talks at Google, and the more time I spent with the evidence the more the cash-transfer model came to feel like a clarifying thought experiment. Instead of targeting help through complex eligibility rules that taxed people for earning more, you could simply give people cash and pay for it through explicit taxes.

The point was never that UBI was necessarily the optimal policy. It was that UBI worked as a benchmark—a clean reference case against which to reason about the tradeoff between targeting, which is cheaper but builds in disincentives and cliffs, and universality, which costs more but is simpler and has no cliffs at all. It was the same move I had learned in that Berkeley simulation course, really: hold one thing constant, vary another, and watch what the system does. Alex's cliff was a data point; UBI was the counterfactual that made the data point mean something. Once you had that reference case in mind, the existing system's strangest features became easier to see for what they were.

The policy turn

In 2015 I moved to YouTube's data-science team, working on growth models, experiment analysis, and the launch of YouTube Go, a product built for markets with poor connectivity and lower-end phones, primarily in India and sub-Saharan Africa.

But my attention kept drifting to policy. Proposals to expand the Child Tax Credit were gaining traction; Senators Michael Bennet and Sherrod Brown had introduced the American Family Act, and I wanted to know what a larger child allowance would actually do to poverty rates, and who would gain. These were answerable questions—the kind with a number at the end—and yet there was no obvious place a curious person could go to get the number. So I went looking for a tool, and I found one: Tax-Calculator, the open-source model of US federal income and payroll taxes that had come out of the American Enterprise Institute. It was written in Python, maintained by economists with decades of experience, and—this was the part that changed things for me—its code was on GitHub. Anyone could read the formulas, run the model, and check the results.

So I did. I started using Tax-Calculator, then contributing to it, then spending my evenings and weekends on policy analysis with open-source tools while working full-time at YouTube. The realization crept up on me and then would not leave: serious public-policy analysis, the kind that moves millions of people and billions of dollars, could be done with open-source software, from a laptop, without leaving to join a think tank or a government agency. It didn't require the machinery behind the curtain. It required a good model, public data, and the willingness to do the work. This was how policy analysis should work.

The UBI Center

In 2018 I took three months off from Google to work on policy full-time, and enrolled in MIT's MicroMasters program in Data, Economics, and Development Policy—graduate-level coursework that could ladder into a full master's degree if I decided to pursue it. The three months were clarifying. I worked with the Open Source Policy Center at AEI, contributed to Tax-Calculator's technical infrastructure, and ran distributional analyses of tax reforms, and the work felt more important than anything else available to me. Leaving Google was not an obvious move—it was a good job, and the thing I was leaving it for did not yet exist, no organization to join, no salary, only a conviction and a set of half-built tools—but the three months had made the choice feel less like a risk than like an admission of where my attention had already gone. I returned to YouTube briefly, then left Google in July 2018, after eight years, to commit to independent policy research, supported by savings and the growing conviction that open-source policy analysis was infrastructure the world needed and mostly didn't have.

In 2019 I founded the UBI Center, an explicitly open-source think tank focused on universal basic income policy ,^[2] with all of its code and data public so that anyone could verify the findings. The first problem announced itself immediately. A $1,000-a-month basic income costs something like $3 trillion a year, and to fund a number like that you have to change taxes or benefits—which means that to model UBI honestly you have to model the entire tax-and-benefit system, not because a basic income necessarily interacts with the other programs, but because you have to show what would pay for it. And UBI doubled as a lens on the existing system. Without it, low-income families faced implicit marginal tax rates above 50 percent from stacked phase-outs, and hit cliffs where earning a little more meant losing thousands in benefits. Setting universality beside means-testing was a way to make those features visible: it gave you a comparison point, a version of the system with the cliffs deliberately removed, so you could see exactly what the cliffs were doing.

Tax-Calculator could handle federal income and payroll taxes, but not benefits like SNAP or Medicaid. OpenFisca offered a framework for encoding rules, but OpenFisca-US was young and incomplete. Neither had an interface that would let a non-programmer explore a policy for themselves. And for state-level analysis—which mattered, because so many UBI proposals were state-specific—the tools barely existed at all.

The first researcher I recruited was Nate Golden, a middle-school math teacher in Washington, DC, who cared about fighting poverty with evidence and would later found the Maryland Child Alliance to push child-poverty policy at the state level. The second came from the internet. I had posted on the Basic Income subreddit asking for help, and Nikhil Woodruff, a college student in the UK, replied; he turned out to have a rare pairing of genuine economic-policy interest and real software-engineering skill.¹ The whole operation, in those first months, amounted to a few people—a math teacher, a college student from a message board, me—working nights and weekends on a model of the American tax-and-benefit system. It did not look like infrastructure. It looked like a hobby with unusually high stakes.

The UBI Center began producing real work—analyses of Andrew Yang's Freedom Dividend, of carbon-dividend designs, of child allowances—but every one of them required cobbling partial tools together, writing custom code, and working around the gaps in what already existed.

And I kept hitting walls. I'd want to model a policy and discover that nobody had encoded the relevant benefit program. Or the model existed but hadn't been updated in years. Or it worked but demanded expertise I didn't have to run it. I would set out to answer a simple-sounding question—how would this state credit change child poverty?—and lose a week discovering that the credit interacted with a benefit no open model had ever encoded, and that I would have to encode it myself before I could even begin to answer. The frustration was not peculiar to UBI research; anyone trying to analyze a cross-cutting reform ran into the same barriers, because the open-source revolution had produced components—a tax model here, a benefits framework there—but nobody had assembled them into something an ordinary researcher, let alone an ordinary citizen, could actually use.

And there was no open-source model of the UK tax-and-benefit system at all. If Nikhil and I wanted to do comparative UBI analysis across the US and the UK, we would have to build the UK model from scratch.

So we did.

By 2020 the UBI Center had grown to ten researchers, our biggest year, and we had stopped only writing reports and started building infrastructure: microdf for analyzing survey data, openfisca-uk for simulating UK policy, two of our Python packages accepted into the Policy Simulation Library catalog. Building openfisca-uk meant encoding an entire national system that no one had put in the open before—Universal Credit, the personal allowance, the benefit taper—line by line from the legislation and the guidance, and testing it against every case we could check by hand. It was slow, unglamorous work, and it was the first time the UBI Center felt less like a research shop than like a builder of the infrastructure its research kept needing. Golden worked out whether a basic income should target adults, children, or both, finding child allowances the most effective for poverty reduction up to a given budget; Nikhil built on the UK Family Resources Survey while I worked on enhancing the US Current Population Survey. And we tried to be honest about the numbers even when they undercut the case we might have been expected to make. Our analysis of Yang's proposal showed a 74 percent reduction in poverty, but it also showed that the plan would cost about $2.8 trillion a year while his five proposed taxes would raise only $1.2 trillion, leaving a $1.6 trillion gap citation pending. Our carbon-dividend work found that a £100-per-tonne UK carbon tax would cut poverty by 14 percent and deep child poverty by 33 percent citation pending. We weren't advocates. We were modelers, showing the tradeoffs and letting the numbers say what they said.

But the deeper problem never went away: all of it took Python. The work was open-source in principle and inaccessible in practice to exactly the journalists, advocates, and policymakers who needed it most. The code was public; the ability to use it was not.

The frustration, I finally understood, was infrastructure-shaped. The tools were fragmented—tax models that didn't talk to benefit models, federal systems that didn't connect to state ones—and running any of them meant installing software, preparing data, and writing code. The gap was not a missing model. It was that no one had assembled rules, data, and an interface into a single thing that a person without a programming background could sit down and use to ask a real question and get an answer they could trust. Rules, data, and an interface, welded into one instrument and made reliable enough to believe—that was the whole of it, and it had gone unbuilt because each piece belonged to a different discipline and a different institution, and putting them together was nobody's job. That was the wall, and it was the same wall my family had hit around Alex's kitchen table, scaled up to a country. Someone would have to build the thing that tore it down.