Building CPAL's Data Function

CPAL exists to cut child poverty across North Texas. Doing that means working across housing, public safety, maternal health, benefits delivery, and criminal justice, and every one of those areas generates enormous amounts of administrative data. When I joined in 2020 as an early analytics hire, the org had little capacity to turn that data into decisions. The data team was two people, me and my manager, the infrastructure was thin, and there were no shared standards for how data got collected, cleaned, or handed to the people who needed it.

The problem was never a shortage of data. It was the opposite. Public agencies, courts, and partners were sitting on far more records than anyone could read. What CPAL didn't have was a way to make any of it usable: to clean it, hold it somewhere durable, and put it in front of staff making real decisions. Analysis happened in one-off scripts on one person's laptop. Nothing compounded, and nothing survived the person who built it.

So the thing to build wasn't a dashboard or a report. It was a data function: people, infrastructure, standards, and enough trust across the org that non-data staff would actually change what they did based on what the data said. That's a leadership problem before it's a technical one.

I helped grow the function over six years and three roles, from analyst to manager to director, and set its structure through most of that growth. The through-line was treating data as organizational capacity to be built on purpose, not a service desk taking requests. A few decisions carried the most weight.

• The team model. The team grew in stages: a first intern in 2022, the first additional full-time hire in 2023, and up to four people after that. I hired CPAL's first data engineer and mentored the analysts who came through, including an intern I brought on full-time. When the platform migration needed more engineering depth than a nonprofit payroll could carry, I brought in a four-person vendor engineering team and kept the architecture and priorities in-house. That got the foundation built. Today two in-house data engineers report to me and work alongside the vendor team on one roadmap.
• Tooling I chose and defended. I selected Databricks over Snowflake and dbt Cloud after a capacity assessment weighing the team's size and skill mix, the migration cost, and the value of one platform over a stitched-together stack. I contracted vendor data feeds (MySidewalk, DataAxle), shaped the setup and rollout of Claude Enterprise org-wide, and built project-management infrastructure in Notion that's since been adopted across multiple CPAL departments. I owned the roadmap, the vendor strategy, and the budget behind these calls.
• Leading through the CDO transition. When the chief data officer role turned over (Dec 2024 to Dec 2025), I led the data org through the transition, reporting to the CTO. I set the department roadmap, ran hiring, owned vendor strategy, and held the budget. The function kept shipping through a leadership change, which is the real test of whether you've built something that depends on more than one person.
• AI adoption as change management. Rolling Claude Code and Claude Enterprise across the team wasn't a procurement exercise, it was a change-management one. I built the scaffolding (custom skills and agents, prompt caching through the Anthropic API) and then did the harder work of getting people to change how they work. It changed how the team develops pipelines, writes documentation, reviews code, and communicates with stakeholders. The license was the easy part. Adoption was the job.

Underneath all of it is a conviction I keep coming back to: a nonprofit fighting poverty deserves the same quality of data infrastructure as the institutions and markets it's often working against. Building that on a nonprofit's terms, with a nonprofit's budget, is most of what the last six years were about.

In 2020, CPAL's data team was two people and a laptop. Today CPAL has a data function that outlasts any single project or person. A suite of 30+ R Shiny applications informs decisions across housing, public safety, maternal health, benefits delivery, and criminal justice. The eviction data workstream covers four North Texas counties and feeds 12+ partner organizations daily, moving tens of thousands of records a year. Internal tools let non-data staff act on data without waiting on an analyst, including a parcel-level outreach tool with 20 active field-team users.

The infrastructure underneath it is being systematized too. The team is moving the org's pipelines off file-based storage onto Databricks on AWS, with Unity Catalog, Workflows, a Lakebase and Lakehouse setup, and Git-tracked orchestration. That's the difference between a collection of clever scripts and a platform an organization can build on for years.

The outcomes that matter most are the ones the data made possible downstream. In the eviction work, partner organizations now send a postcard to every household with a filing in Dallas County, and outreach teams follow up directly with a share of them. About 800 tenants a year get legal representation they otherwise wouldn't have. In the Trust Her maternal-health workstream, the data has helped connect more than 15,000 women to contraceptive access over the last three years. Inside CPAL, the function now serves every team.

Building and leading a data team at a mission org taught me a handful of things I'd do the same way again:

• Build capacity, not deliverables. A data function is people and systems that keep working after the person who built them moves on. If your value walks out the door when you do, you built a role, not a function.
• Buy the right tool for the team you have. The Databricks-over-Snowflake call came from a capacity assessment, not a feature checklist. The best platform is the one your actual team can run, migrate onto, and maintain, not the one that demos well.
• Adoption is the real work. New tooling, AI included, is change management wearing a procurement costume. Getting people to change how they work is slower and harder than any purchase, and it's the part that determines whether the investment pays off.
• A nonprofit budget is a design constraint, not an excuse. The vendor team gave us engineering depth a nonprofit payroll couldn't carry on its own, while the architecture and priorities stayed with us. Constraints force clearer decisions about what to build in-house, what to buy, and when to switch.