Working With Quantitative Policy Analysis the Rosenthal Way
Most policy analysis that reaches decision-makers is half-baked. The data is fine. The question being asked is usually something nobody in government actually cares about. Paul Rosenthal's approach at Columbia — specifically through the Work and Family Policies Working Group and the broader Columbia policy analysis ecosystem — sidesteps this by forcing the analytical framework to match the actual constraints of implementation. I've spent years watching policy projects fail because the rigor was in the wrong place. Rosenthal's work demonstrates why it matters to put it somewhere useful. The core of his method is straightforward but rarely executed correctly. You start with a policy question that has already been constrained by political reality, then you build an analytical model around those constraints instead of ignoring them. Most analysts I know start with the ideal model and then try to force the policy to fit. That sequence produces work that looks impressive in a peer-reviewed journal and gets discarded the moment it reaches a legislative committee room. I learned this the hard way during a state-level workforce development evaluation a few years back. We were asked to assess a training program's impact on employment outcomes. The standard approach would have been a clean regression discontinuity design. But the program's enrollment process had been politically modified mid-stream — the governor's office had added a priority population that broke the original assignment mechanism. Our initial RDD was invalid within weeks of launch. Instead of spending three months trying to patch it, we switched to a difference-in-differences approach with program-site fixed effects and a synthetic control group built from nearby counties that never adopted the modification. It wasn't the prettiest identification strategy, but it answered the actual question policymakers needed answered, and it held up under audit. That's the Rosenthal sensibility: the rigor is in matching your method to the mess, not in pretending the mess doesn't exist.
His work on work-family policy specifically demonstrates this consistently. The research on employer-provided leave, childcare subsidy design, and scheduling flexibility all share a structural feature. They treat institutional context as a variable, not as noise. When you analyze parental leave policy without modeling the employer size thresholds that determine eligibility, you're measuring something that doesn't exist in practice. Rosenthal's publications routinely include these institutional boundary conditions as explicit parameters in their models. There's a practical implication for anyone actually doing this work. You should be spending roughly forty percent of your project time understanding the policy's legal and administrative architecture before you touch a single dataset. I know that sounds backwards. People who build their careers on statistical methods tend to want to get to the data immediately. But in my experience, projects where the analyst doesn't understand the eligibility rules, the funding streams, and the enforcement mechanisms before modeling tend to produce results that are either technically correct and practically irrelevant, or emotionally satisfying and empirically unsupported. The counter-intuitive part that most people miss is that this approach actually requires less technical sophistication in some ways. You don't need the most advanced causal inference method available. You need a method that your audience can follow, that survives scrutiny from people who weren't involved in designing the study, and that produces estimates with confidence intervals narrow enough to matter for budget decisions. A well-executed OLS with proper cluster-robust standard errors often beats a fancy double-ml estimator that nobody on the receiving end understands.
I've also found that Rosenthal's collaborative model — working directly with implementing agencies, reviewing program manuals before collecting data, attending agency staff meetings — produces materially different analysis than the traditional distance-based research approach. The difference isn't just philosophical. When I pulled program documents from a prior project that hadn't included that step, I discovered we'd been measuring the wrong outcome variable for six months. The program's actual performance metric had shifted the year before, and our data collection instrument was still tracking the old one. Nothing in our model specification was wrong. The entire analysis was measuring something irrelevant. That kind of error is nearly impossible to catch from an academic distance. There are limitations to this approach that aren't always discussed. It doesn't scale well. The intensive institutional engagement that makes this method effective requires genuine time investment — we're talking months of preliminary work before analysis begins. Large grant cycles and academic promotion timelines rarely accommodate that pace. The results also tend to be context-specific in ways that make generalization difficult, which is a liability if your career depends on publishing in top-tier journals that prioritize external validity over internal validity. If you're trying to apply this rigor to your own work, start by mapping the policy's institutional architecture on paper before opening any software. Draw the eligibility flow. Trace the funding. Identify every decision point where a politician or administrator could have changed the rules. Then build your model around those decision points rather than treating them as background conditions. It will feel slower at first. The initial projects will take longer. But the analysis will survive contact with the actual world, which is where most policy work dies anyway.
Get the Full Details
