Teams almost always describe it as a tools problem. Underneath, it's usually a decision nobody has made, and a new platform just organizes the same confusion more neatly.
Tools & Systems
Everyone Calls It a Tools Problem
The most common thing I hear on a first call is some version of "we have a tools problem." It usually comes in one of two flavors. Either the team knows they're not using the tool they have as well as they could, or they know they need something new and don't know where to start.
What’s Actually Underneath
Here’s what that looked like for one client. A nonprofit’s membership records lived across a dozen spreadsheets, roughly one per program, each maintained by hand. There had been real attempts to consolidate. Plenty of records were stale anyway, and a lot of what was true about the membership lived in one person’s head. The cost wasn’t abstract: work the organization depended on, like applying for grants, was hard to do with confidence, because nobody could say for certain what the membership base actually looked like.
What was missing wasn’t a better tool. It was an agreement about what counted as an “active member” across programs, and a place for that answer to live that more than one person could see and trust, without the errors that creep in when twelve spreadsheets get combined by hand. Once those calls were made, the tool had something real to organize.
When I dig into a “tools problem,” what I find underneath is usually a decision problem, and it tends to show up in one of three ways.
Either the team thinks a decision is settled when it actually isn’t, and everyone’s carrying a slightly different version in their head.
Or the decision has never been made at all, but the daily work can’t wait for it, so each person answers the question for themselves and keeps moving.
Or a leader made the decision privately and never told anyone, so the team is quietly building their own version every day.
A system can’t surface any of that on its own. It can only encode what you give it. Hand it unresolved questions, and it will organize them neatly. It won’t answer them.
The Platform Is the Last Decision, Not the First
There’s a related move in this space: “we’ll get our processes right once we pick the platform.” It sounds intuitive. What I’ve seen in practice, though, is that it’s the wrong order of operations. Pick the wrong platform with the right decisions made, and you’re inconvenienced for a quarter while you migrate. Pick the right platform without the decisions made, and you’re paying for a license to host the same dysfunction, just with better reporting.
The fix isn’t more tools. It isn’t fewer tools, either. It’s treating tool selection as the last step, not the first. Surface the decisions, write them down, and test them with the people who’ll actually live with them. The tool gets configured last, to match. That’s not a smaller scope of work. It’s just an honest one.
Hand it unresolved questions, and it will organize them neatly. It won't answer them.
If you’re about to buy a new tool because the old one isn’t working, two questions are worth asking first.
What specifically can’t the old tool do that the new one can?
And how many of the frustrations on your list are actually decisions nobody has made yet?
In my experience, the second list is longer, and buying something new doesn’t shorten it.
Before You Buy Anything
If this is the conversation your team keeps having, it's usually a 30-minute conversation to figure out whether it's actually a tools problem. I'm happy to have it with you.
