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 built the function over six years and three roles, from analyst to manager to director. 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. I scaled the team from one in-house analyst (me) to seven: one in-house data engineer I hired, CPAL's first, plus six external data engineers through a vendor partnership. The vendor-augmented model was a deliberate call. A nonprofit budget can't carry a full in-house engineering payroll, but the work needed real engineering depth, so I bought the depth on terms the org could sustain and kept the architecture and priorities in-house. I also mentored the analysts who came through the team, including an intern I brought on full-time.
• 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 a single unified platform over a stitched-together stack. I brought Claude Enterprise in org-wide, contracted vendor data feeds (MySidewalk, DataAxle), 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 had one analyst and a laptop. Today it 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 runs daily to 12+ partner organizations across four North Texas counties, 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 migrating 35 to 40 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 reach every household with a filing in Dallas County, and 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. The function now serves nine internal teams across the org's focus areas.

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-augmented team model was how I got engineering depth without an engineering payroll. Constraints force clearer decisions about what to build in-house and what to buy.