August 2026

Process beats technical skill

The most common way a data science engagement fails isn't a bad model. It's a good model built on top of a mess, delivered to a team that has no way to act on what it says.

I've watched this happen from the inside more than once: months of modeling work, solid accuracy numbers, and then nothing changes, because the output doesn't fit into how anyone actually works. The model was never the bottleneck. The mess underneath it was.

The order most people run backwards

The instinct, especially for anyone hiring a "data scientist," is to start with the model. Get the smart thing built, then figure out where it plugs in. I do the opposite, in four steps, in this order:

1. Understand how the organization actually operates

Not the org chart version. The real one: where the donor data actually lives, who touches it, what "at risk" means to the people who'll act on it, and what already gets ignored because it doesn't fit anyone's workflow. This is usually different from how anyone described it to me on the first call, not because they were wrong, but because nobody had looked at the whole picture at once before.

2. Get everything in one place

Donor CRM, event platform, email tool, spreadsheet someone built in 2019 that still runs the gala. Whatever exists, it usually exists in three places that don't talk to each other. Clean infrastructure before anything intelligent runs on top of it. This step is unglamorous and it's where most of the real value gets created, because half the time the "prediction problem" turns out to be a "we can't see our own data" problem.

3. Build the model on the clean data

This is the part people picture when they hear "data science," and it's the fastest step once the first two are actually done. Custom, explainable, tuned to your specific definition of success, not a generic churn score borrowed from an industry benchmark that doesn't describe you.

4. Deliver it inside a dashboard your team will actually open

A model nobody looks at is worth exactly nothing. The last step is making the output visible in whatever your team already uses, so the value shows up every month instead of getting delivered once in a PDF and forgotten.

Why the order matters more than the model

Skip steps one and two, and you get a technically impressive model that nobody trusts, because nobody can trace its answer back to something they recognize about their own organization. Do them first, and the model itself is almost the easy part, which is the opposite of how it feels from the outside.


If you want to know what step one would actually surface for your organization, book 20 minutes.