The friction you're describing isn't a personal failure. It's a structural feature of how nonprofit data works, and naming that distinction matters. When every program defines success differently, when metrics are invented to please a funder and then abandoned, when the systems holding that data were never maintained, you're not solving analytical problems. You're translating chaos into a coherent story, over and over, for a new audience each time. That's exhausting, and it's not the same as doing difficult analytical work. It's the work of building a foundation that should have existed before you arrived.
Your instinct to look toward people analytics or accounting as more stable domains is worth taking seriously, but not because those fields are inherently easier. They're more standardized because the underlying processes they measure, hiring, payroll, compensation, financial transactions, are governed by external norms and legal requirements. A headcount means roughly the same thing at a tech company as it does at a bank. A revenue figure follows accounting rules that don't shift with a program director's mood. That consistency means your energy goes into analysis, not into first decoding what the data even represents. You can plug in faster, and your skills transfer more directly. That's a real advantage, and it's reasonable to want that stability.
But here's the part that should give you pause. Standardized domains still have messy stakeholders. People in any field invent metrics that sound good in a board meeting. The difference is that in more mature domains, there's usually a shared vocabulary and a set of established practices that push back against the worst impulses. If a CFO proposes a meaningless metric, there's a framework for challenging it. In nonprofit program work, there's often no such framework, so the nonsense persists and multiplies. Your frustration isn't just about the data. It's about the absence of guardrails that would let you do your job well.
The practical takeaway isn't to avoid messy domains forever. It's to be more intentional about the kind of mess you're willing to manage. When you interview for your next role, ask how metrics are defined, who owns them, and what happens when a stakeholder invents a new one. Listen for whether there's a process or just a hope that someone will figure it out. A stable domain can still be dysfunctional if the culture rewards improvisation over discipline. And a messy domain can be manageable if the leadership values data hygiene enough to enforce it. You don't need a domain that's perfect. You need one where the foundation is solid enough that your skills can actually carry the work. That's the bar worth holding out for.