A wall of frustration

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.

Individuals moving through states

The strange part is that I already knew how to model systems like this. The method had followed me from a Berkeley classroom to a factory floor to Google's hiring pipeline — everywhere, that is, except home.

In 2008, as a Berkeley undergraduate, I took IEOR 131, Discrete-Event Simulation. The premise of the course was the working engineer's version of the idea chapter 1 traced through economics: model a complex system not as a set of equations but as a collection of individuals moving through states. To simulate an emergency room, you do not estimate an average wait time; you track each patient's arrival, each nurse assignment, each treatment decision, then change something — one more nurse on the night shift — and watch the system respond. The course ran on Excel and Visual Basic for Applications, and its examples were operational: healthcare facilities, manufacturing lines, service queues.

My first internship put the method on a factory floor. Finelite, a lighting-fixture manufacturer in Union City, California, had decisions that sound trivial until you cost them: whether to pre-cut wire to standard lengths or cut it to order; how to sequence assembly lines to minimize changeover time. I simulated them in Matlab and watched the answers emerge from the individual units rather than from any formula about the factory as a whole. What the method kept delivering was surprise — the behavior of the system, computed from its parts, was routinely one the averages had hidden. The syntax changed over the years that followed, VBA to Matlab to R to Python, and the frame never did: individuals, states, transitions, and a sum at the end.

By that description, the spreadsheet my family kept rebuilding had been a simulation all along: one household, moving through the states a statute defines, with a sum at the end that kept coming out negative. Knowing how to model a system, it turned out, was different from having a model of it.

Project Lorenz

After two years in consulting I joined Google's People Analytics team in 2010, a group premised on bringing the same standard of evidence to decisions about people that the company brought to decisions about products. In 2012 a colleague and I founded a small data-science team inside it, working on natural-language processing of employee feedback, social-network analysis of the org chart, and — my piece — simulation models for workforce planning.

The planning problem was concrete and enormous. 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 different hiring needs. Leadership wanted to project headcount growth against targets, accounting for recruiting capacity, candidate pipeline dynamics, internal mobility, and attrition. The existing tool was a set of spreadsheets.

I built a simulation from the bottom up and named it Project Lorenz, after Edward Lorenz, whose weather research showed how micro-level dynamics drive macro-level phenomena. It modeled candidates entering through different channels and estimated their probabilities of moving between hiring stages with survival models, the same machinery health researchers use to predict disease progression. It accounted for variation in recruiter productivity, for attrition, for transfers between divisions. It ran in R, used Monte Carlo methods to quantify uncertainty, and produced a distribution of outcomes rather than a single number. It was a microsimulation of one company's labor market, though I did not yet know the word and had never read Orcutt.

Project Lorenz never fully materialized. It had too many moving parts, and wiring them together made the whole thing unstable: a small change to one transition probability would ripple through the pipeline and produce a headcount forecast nobody believed. The idea was right. My execution was not. We ran the spreadsheets for another cycle.

Cash as a benchmark

Around the same time, conversation inside Google kept turning to technological unemployment — what AI might eventually do to the labor market, and whether society would need new institutions to guarantee basic needs. Some people talked about universal basic income: unconditional cash payments, no means test, and so none of the cliffs that means-testing produces.

The idea had a live experiment attached. In 2012, Google.org gave GiveDirectly a $2.4 million Global Impact Award .^[1] GiveDirectly made unconditional cash transfers to extremely poor households in Kenya — families living on roughly a dollar a day received about a thousand dollars, no strings attached — and its founders ran randomized controlled trials to measure the effects. The results were encouraging: gains in earnings, assets, nutrition, and children's education. I volunteered with GiveDirectly on the side, helping them use their data more efficiently and hosting their researchers for talks at Google.

I did not know whether basic income was good policy; I knew it was a clean benchmark. Safety-net design runs on a tradeoff between targeting and universality: means-tested programs concentrate money on the poorest and, in exchange, build the phase-outs and cliffs my family had been mapping, while a universal payment costs far more and builds none. Set the two designs side by side and the cliff stops hiding — the same move my Berkeley course had drilled, hold everything constant, vary one thing, watch the system respond. Against a benefit that never phases out, every phase-out shows. Seeing the comparison, though, takes a model that can run both designs over the same families, household by household. The benchmark was, quietly, a demand for a microsimulation.

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. The work was good. My attention kept drifting to policy.

Senators Michael Bennet and Sherrod Brown had introduced the American Family Act, an expansion of the Child Tax Credit, and it raised questions with computable answers: what the expansion would cost, which families it would reach, how many children it would pull over the poverty line. The models that could compute them lived behind the walls chapter 2 described, and I was a data scientist at a video platform — not a constituency the Joint Committee on Taxation serves.

Then I found Tax-Calculator, the open-source model of US federal income and payroll taxes that chapter 2 traced to the American Enterprise Institute. It was written in Python and maintained by experienced economists, and its code sat on GitHub, where anyone could read the formulas, run the model, and check the results. Using it required no one's permission.

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. A question about a Senate bill could become a distributional table by the weekend, produced on a laptop, checkable by anyone who cared to look. Serious analysis took a good model, public data, and the willingness to do the work — no think tank, no agency. This was how policy analysis should work.

In 2018 I took three months off from Google to work on policy full time. I enrolled in MIT's MicroMasters program in Data, Economics, and Development Policy — graduate coursework that could ladder into a full master's — and spent the leave working with the Open Source Policy Center at AEI, contributing to Tax-Calculator's technical infrastructure and running distributional analyses of tax reforms. Then I went back to YouTube, and the return did not take. In July 2018, after eight years, I left Google to do policy research on my own, living on savings.

The UBI Center

In 2019 I founded the UBI Center, a think tank for basic income research with one structural commitment: all of the code and all of the data public .^[2] The commitment came from the previous three years, in which everything I had done as an outsider had been possible because someone else's model was public. You do not climb that ladder and then pull it up.

The first discovery was that you cannot model basic income by itself. A $1,000-a-month basic income for the United States costs something like $3 trillion a year, and paying for it means changing taxes or benefits — so an honest UBI analysis is an analysis of the entire tax-and-benefit system, because it has to show what would fund the thing: which taxes rise, which programs shrink, and what both do to the same families the dividend helps. And holding the benchmark against the real system did what benchmarks do. Stacked phase-outs pushed implicit marginal tax rates above 50 percent for low-income families; cliffs meant that earning a little more could forfeit thousands of dollars in benefits. Alex's cliff had been no anomaly.

The tools were not ready. Tax-Calculator handled federal income and payroll taxes but no benefits — no SNAP, no Medicaid, none of the programs whose phase-outs build the cliffs. OpenFisca, the French framework from chapter 2, offered a way to encode the rules, but OpenFisca-US was young and incomplete. Neither had an interface a non-programmer could use. State-level tools barely existed, and the programs that had produced Alex's cliff ran through the states.

What the UBI Center had before it had tools was people. The first researcher was Nate Golden, a middle-school math teacher in Washington, DC, who wanted to fight 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 posted on the Basic Income subreddit asking for help, and a college student in the UK named Nikhil Woodruff replied. A message board is where you recruit when no institution hires for the job you think needs doing. Nikhil had a rare pairing — serious interest in economic policy and serious 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 analyses came anyway. When Andrew Yang's Freedom Dividend — $1,000 a month for every American adult — put basic income into a presidential primary, we ran the arithmetic all the way through: the plan would cut poverty by 74 percent (from 7.3 percent of the population to 1.9), and it would cost about $2.8 trillion a year while the five taxes Yang proposed would raise $1.2 trillion, leaving a $1.6 trillion gap .^[3] Both findings went into the same report at the same volume; we were modelers rather than advocates, and the job was to show the tradeoffs and let the numbers say what they said. Nate worked out whether a basic income should go to adults, children, or both, and found that for a fixed budget, child allowances cut poverty most. Every analysis meant cobbling partial tools together and working around their gaps.

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.

Building openfisca-uk meant encoding an entire national system nobody had put in the open before — Universal Credit, the personal allowance, the benefit taper — line by line from the legislation and guidance. The exactness was the point, and the family spreadsheet had taught me why: a cliff lives or dies on one threshold, so a model wrong about one parameter lies to every household near it. We tested against every case we could check by hand. It was the spreadsheet ritual again, at national scale, with one difference: a rule we got right stayed right for everyone who came after us.

Nikhil built on the UK's Family Resources Survey; I worked on enhancing the US Current Population Survey. By 2020 the UBI Center had grown to ten researchers, its biggest year, and its center of gravity had moved from writing reports to building what reports need: microdf, for analyzing survey data, and openfisca-uk, for simulating UK policy, both accepted into the Policy Simulation Library catalog beside Tax-Calculator. The models started answering questions: a £100-per-tonne carbon tax with the revenue returned as a flat dividend would cut UK poverty by 14 percent and deep child poverty by 33 percent, and the US companion put a $100-a-ton version at a 10 percent poverty cut .^[4] It was the two-country comparison we had built the UK model to make.

Open in principle

All of it took Python. A journalist on deadline was never going to install a programming language to check a claim about the Child Tax Credit, and neither were most advocates or policymakers — the people who needed the answers most. The work was open-source in principle and inaccessible in practice: 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.