You cleaned up the CRM. You spent a full weekend on it — merging duplicate contacts, updating out-of-date information, tagging clients correctly. And for a few weeks, all was good. Then, slowly and without much drama, it started getting messy again. Same patterns. Same gaps. Different month.
Or you built the workflow. Mapped every step. Wrote the SOP. And your team acknowledged it, nodded at the right moments, and then mostly kept doing things the old way — not out of defiance, just because the new way never fully took hold.
If either of those scenarios sounds familiar, you're not dealing with a discipline problem or a technology problem. You're dealing with a systems problem. And the reason it keeps coming back is that you've been fixing the symptom without touching the system that keeps producing it.
What Systems Thinking Actually Means
Systems thinking is a way of looking at the world that acknowledges that elements within a system dynamically influence one another over time. Donella Meadows, author of Thinking in Systems, explored this theory as it relates to ecological systems and it has since been expanded by researchers across disciplines from engineering to organizational management. The core idea is deceptively simple: every problem is produced by a system, and if you don't change the system, the problem will keep being produced.
Most of us are trained to think in events. Something goes wrong — we find the cause, we fix it, we move on. That works fine for isolated, simple problems. But in complex environments that are interconnected (like a financial advisory practice with dozens of interdependent workflows, data sources, relationships, and moving parts) events are almost never isolated. They are the output of a system designed, however unintentionally, to produce them.
The CRM is messy again. Follow-ups are falling through. The same client data keeps being entered wrong. Onboarding feels chaotic every single time.
No defined data entry standard. No single owner for each process step. No consequence or reminder when steps are skipped. A workaround that was faster than the right path has now become the default.
The mess you see at the surface is real. But fixing it at the surface — cleaning it up, reprimanding employees, trying harder — only works until the underlying structure produces the same output again. Which it will, because that's what systems do.
The Patterns That Show Up Most in Small RIAs
I've seen a handful of systemic patterns repeat across almost every firm I work with. They look different on the surface, but they share the same underlying structure.
The workaround that became the process
Someone, at some point, needed to get something done quickly. The "right" way was inconvenient or unclear, so they found a faster path. It worked. They did it again. Other people followed suit. Now that workaround is the process — even though it creates downstream problems, even though it bypasses whatever system you built to handle that task. The workaround persists because it's easier than the alternative, and no one has redesigned the alternative to actually be easier.
The data problem that's actually a behavior problem
You think you have a CRM data problem. Records are incomplete, inconsistent, outdated. But when you trace it back, the CRM isn't the issue — the issue is that logging information isn't built into the natural flow of how work gets done. There's no moment in the process where someone is prompted to record what just happened. It requires an extra step, in a separate system, after the real work is done. And so it gets skipped. Routinely. The data problem is a process design problem in disguise.
The fire that gets fought instead of prevented
The same issue erupts every year — a missed distribution for a retiree who just reached RMD age, a client who was onboarded without the updated privacy policy, a rollover that didn't get invested. Each time it happens, you deal with it. You put out the fire. You might even feel good about how well you handled it. But because the crisis got resolved, there's no sustained pressure to fix the processstructure that keeps creating it. The system is optimized for crisis response, not crisis prevention. And so the crisis recurs.
"You do not rise to the level of your goals. You fall to the level of your systems." — James Clear, Atomic Habits
Where the Real Leverage Is
Meadows wrote about something she called leverage points — places in a system where a small change can produce large shifts in behavior. The frustrating thing she discovered is that the most obvious intervention points tend to be the least powerful, while the highest-leverage changes are often counterintuitive and invisible until you know where to look.
In operational terms, this usually means the leverage isn't in the surface-level fix. It's upstream. It's in:
- The information structure — who sees what, when, and whether that information is accurate and timely enough to act on
- The feedback loops — whether the system signals when something is wrong early enough to correct it, or only after the damage is done
- The defaults — what happens automatically when no one makes an active choice, because most of the time, no one does
- The ownership structure — whether each step in a process has a single, clear owner, or whether it lives in the ambiguous space where everyone assumes someone else is handling it
This is why two firms can implement the same CRM and get completely different results. The software is the same - same product, same capabilities - but the systems around the software are different. In other words, how it's configured, what prompts it creates, how the workflows are designed -- these all determine what behavior it will reinforce. Design is everything.
What This Means for How We Work Together
When I'm asking you questions and it starts to feel like an interrogation — "Walk me through exactly what happens after a prospect call," or "What triggers that step? Who decides?" — I'm not being obtuse. I'm mapping the system. I'm trying to understand the structure that's producing your current results before I start suggesting changes, because a change that doesn't address the structure is just another workaround.
A useful question to sit with: What problem in your firm have you solved more than twice?
If you've fixed a problem and it came back, and you fixed it again... that's the structure telling you something. The fix wasn't wrong. It just wasn't deep enough. That's where we should be digging.
The goal isn't to make your firm perfect. In fact, I don't think that's an acheivable goal. Because systems are never static — they're dynamic, they respond to changing conditions, and they require ongoing attention. The goal is to build a system that produces the outcomes you actually want, consistently enough that you're not spending your energy fighting the same fires over and over again.
That's a different kind of work than just cleaning up the CRM. And it's worth doing right.
If you're tired of solving the same problems over and over, reach out to me. I'm happy to help you get to the root issues and solve them once and for all.