What "heavy" actually feels like

It’s a familiar scenario. The system slows the work down. Every interaction adds friction. The technology feels like it's working against the team.

Recently, a nonprofit was integrating their CRM with a marketing automation platform. Development had one set of language around opt-in consent. Marketing had another. When they tried to create a unified dataset between the two systems, the inconsistent understanding caused them to step all over each other. They tried to fix it, but it became structural. One team overruled the other, likely to the detriment of the organization.

That's what heaviness feels like. Not a bug. Not a missing feature. Just friction that compounds every time two parts of the organization try to work together.

What nonprofits usually blame

Old software. Complexity. Lack of ownership. "No one understands it." "It's not built for nonprofits."

These are understandable complaints. But they're incomplete.

Where heaviness shows up first (the stress tests)

There are three places where a heavy CRM reveals itself, and they function as stress tests for the entire system.

The first is when leadership wants answers. Looking up a donor's history, understanding forecast, seeing constituent relationships. No one trusts the answers they get. So they end up doing something manual, stitching together spreadsheets, cross-referencing notes, rebuilding what the system should already know. It takes forever. This is the stress test that shows up most consistently. Not always the fastest to reveal itself, but the most persistent.

The second is when work moves between teams. Handoffs break. Workarounds multiply. One team’s definition of opt-in differs from another and suddenly, at best. you’re opting out constituents that actually want to hear from you, at worst, you’re out of compliance with privacy regulations. When the data moves between systems, the inconsistency creates collisions no one anticipated.

The third is staff turnover. The person who understood how everything connected leaves. The system collapses. “Oh! Barb was the one who always did that.” Barb never documented anything either. Not Barb’s fault mind you.

The real cause: no one designed the relationship

In simple terms, a designed relationship is one where the organization understands the operational steps that need to take place throughout the lifecycle of a constituent and what data handoffs occur across the system architecture.

When that doesn't exist, here's what shows up. People answer questions with "I think." That leads to data gaps, which bubble into all the other problems: inconsistency, mistrust, workarounds. Because when you start with a shrug, you end up with a lack of trust.

The real issue isn't the software. It's that no one ever created a clear vision for how work should move, agreed on what the system is responsible for, or planned for ownership or stewardship over time. Intent fades. Friction fills the gap. 

The spaghetti wall: how orgs try to fix it

When the system starts feeling heavy, organizations reach for solutions. Training. Data cleanup. New platforms. Add-ons. Consultants. Each of these can be the right answer, but only if it matches the actual root problem.

Here's the issue: most organizations can't feel where the pain is coming from. So they can't isolate and pick the right solution.

In early conversations with a nonprofit, when cross-functional people are on the call, the clues are there. If they're inconsistently describing the same workflow, it's almost always a vision problem. Get a consultant to help reset. If specific feature or function gaps come up, it's usually a platform problem. The tech is antiquated and no longer supports the work. If data problems dominate the conversation, it's usually an ownership problem. It's been a free-for-all. Clean up the data and clarify who's responsible. If the refrain is "no one understands it," it's a knowledge problem. Train people.

But without diagnosis, these solutions get applied like throwing spaghetti at the wall. And that's a symptom of the original problem: no one could name what was actually broken.

Why this makes things worse

Applying the wrong solution, even with good intentions, creates harm. It adds work to already strapped teams. It creates change fatigue. It reinforces the belief that "the tech is the problem." And it moves the organization further from clarity, not closer.

Sometimes organizations do something reasonable, something that makes sense in isolation, that makes the overall situation worse. Like launching a data cleanup initiative when the real issue is that no one ever agreed on what "active donor" meant. The cleanup is meticulous. But it doesn't resolve the underlying confusion. It just standardizes the wrong thing.

Good intentions can still create harm.

What actually changes the experience

Not tools. Not features.

Here's what actually changes the experience. Talk through the work across every function. Challenge assumptions about "how it has to be done." Decide how the work should move. Name ownership. Then decide what the system needs to support.

That conversation is built on "what" and "why" questions before "how." What are you trying to achieve? Why? Then how. Drilling in two or three layers deep.

And here's what happens: almost immediately, something breaks. Someone realizes, "Oh, we actually don't know this." Or, "Wait, we don't agree on this."

What happens next depends on the trust in the room and what's been observed. But this is the moment to push harder. To name it. To break through it. Because that's the reset moment.