Social services + data systems
Built database applications to replace manual tracking and make program reporting more reliable.
About
I came to analytics through operations.
Before I practiced data science, I owned outcomes for people doing difficult work. That experience still shapes how I frame questions, test evidence, communicate uncertainty, and decide whether an answer is actually useful.
The through-line
Start with the operating reality. Then design the analysis.
I began in social services, where fragmented paper and spreadsheet processes pushed me to build Microsoft Access applications for case tracking and reporting. The lesson was immediate: a technically correct tool fails if it ignores how people actually work.
Later, as the owner and operations lead of a behavioral-health practice that grew to roughly 25 employees, I was accountable for staffing, scheduling, billing, compliance workflows, vendor systems, and financial reporting. That made data quality, clear ownership, and usable processes operational necessities rather than abstract design principles.
Today, in high-volume manufacturing, I work close to maintenance and production systems and translate frontline questions into structured data, analysis, and management-ready dashboards. In independent work, I extend that practice into statistics, optimization, recommendation systems, and guarded AI. Across every setting, the same challenge keeps appearing: define the real question, find credible evidence, and make the result useful to a decision-maker.
Founder + operations lead
Owned the people, process, compliance, billing, and reporting systems behind a growing practice.
Manufacturing + data science
Connects frontline technical work with data analysis, decision dashboards, optimization, and applied AI.
One tool carried over from social work.
I came up through social work before manufacturing and data, and one instrument survived the move intact: the logic model. It forces an honest chain from the resources you actually have to the outcome that is supposed to change, and it refuses to let the middle of that chain stay vague. It is the reason every case study on this site names a baseline before it reports a result.
InputsA named decision and the person making it · available data and its provenance · operating constraints, risks, and the current baseline · a measurable definition of success
↓
ActivitiesProfile and reconcile the data · test the simplest credible method · compare it against the baseline · evaluate accuracy, failure modes, and risk
↓
OutputsA reproducible analysis, dashboard, or evaluated prototype · the methodology and the evidence · documented limitations · a recommendation to adopt, iterate, or stop
↓
OutcomesA better-informed decision · uncertainty made visible · a smaller and clearer next investment · evidence someone can review before committing to scale
The step that does the work is the third one. A method has to beat something real, and the something real has to be chosen before the result is known. Seven of the twenty comparisons on this site came out against the thing I built, which is what that discipline costs and why it is worth keeping.
What I bring
Technical range with operational judgment.
Decision thinking
I connect the question, data, method, interface, controls, and adoption instead of treating analysis as an isolated deliverable.
Translation
I can work from a frontline process, communicate the tradeoffs to leadership, and turn both perspectives into a concrete technical contract.
Accountability
I document assumptions, distinguish measured outcomes from synthetic benchmarks, and make the limits of a system explicit.
Let’s connect
Have a data question or AI opportunity worth testing?
I am open to senior data science and applied AI roles where evidence and practical adoption matter more than the size of the build.
Get in touch about a role