About Me

---

I've spent over fifteen years helping nonprofits and associations get their data to do what it's supposed to do — which is, more often than not, a structural problem before it's a technical one.

My entry point into this work was self-taught, out of necessity. Growing up without reliable access to computers or formal instruction, I learned by breaking things and reverse-engineering how to fix them — a methodology that turns out to be genuinely useful in organizations where the documentation doesn't match what the system actually does. My professional life has been a long accumulation of point-of-need learning: I taught myself Salesforce as an AmeriCorps VISTA volunteer when my nonprofit needed donor management infrastructure and there was no one else to build it. From that first implementation, I've spent the subsequent decades building systems in increasingly complex environments, and eventually made Salesforce the center of my practice.

I now hold nine Salesforce certifications and specialize in solution architecture, database design, process improvement, and full project lifecycle management for mission-driven organizations. My job is to find where a system is failing the people who use it, understand why, and fix that — in a way that serves daily operations, not just the requirements document.

The work I find most meaningful involves telling clients things they may not want to hear. On a recent membership management project, I discovered during discovery that the solution the client had already purchased — and paid licensing fees for — wasn't the right fit for their actual needs. I documented the unmet requirements, made the case to leadership, and steered the project toward simpler standard functionality. The client ended the project with no additional licensing costs and a system flexible enough to change as their organization does. Their retrospective feedback was that they felt I truly understood who they were and what they needed. That's the job.

My approach is direct. I ask "why" early and often, because the request on the surface is rarely the actual problem underneath it. I don't add complexity when simplicity serves the goal, and I'll say so when the proposed solution doesn't match the stated need. I've found that clients who want a vendor generally don't work well with me; clients who want a thought partner generally do.

I'm autistic. I mention it here because it's directly relevant to how I work: I notice patterns in data architecture that aren't immediately obvious, I mean what I say, and I maintain the same standard of precision regardless of whether that's convenient. These traits are assets in this field, and liabilities in environments that prioritize performance over accuracy. I know which kind of environment I'm suited to.

I'm currently available for contract work.