SIGNALS FRAMEWORK
Organizations are constantly sending signals about what's working, what's getting in the way, and what's ready to change.
Sometimes these signals are obvious:
👀 “Our CRM is a mess.”
👀 “Decisions are taking too long.”
👀 “People keep creating workarounds.”
👀 “Our teams aren't communicating.”
👀 “We've hired great people, but we're still struggling.”
Other times, the signals are quieter.
🤔 Meetings multiply.
🤔 Information starts living in spreadsheets.
🤔 Leaders become the bottleneck.
🤔 People develop their own ways of doing things.
🤔 A new system is introduced, but everyone keeps using the old one.
It's tempting to treat each of these as an individual problem.
✔️ Fix the CRM.
✔️ Improve communication.
✔️ Add a process.
✔️ Implement the new technology.
But the visible problem isn't always the real problem.
How do you find the real problem?...
When I work with an organization, I don't want to start by deciding what needs to be fixed. I want to understand what the organization is telling us.
That means listening to leaders and teams, looking at how work actually happens, understanding how decisions get made, seeing where information moves or gets stuck, and paying attention to the systems and tools people rely on.
① I look at the goal first:
Where are we trying to go?
② Then I ask:
What's getting in the way?
How are people actually working?
Where does work get stuck?
How do decisions get made?
Are the systems supporting the way people work?
What's changing around the organization?
The goal isn't to collect information for the sake of collecting it.
It's to connect the signals.
A CRM problem → that might actually be an ownership problem
A communication problem → that might actually be a decision problem.
A process problem → that might actually be the result of teams designing their own solutions because the organization never established a shared way of working.
An AI problem → that might actually be a process problem.
Once the patterns become clear, we can make better decisions about what actually needs to change.
And that's the point.
The Signals Framework isn't about finding problems. It's about understanding what those problems are telling us.
From there, the work becomes much more practical:
Understand → Identify → Design → Build → Measure → Transfer
The work doesn't end with a recommendation.
The goal is to build something that works, establish how we'll know it's working, and leave the team with the systems, knowledge, and capability to continue without me.
That's what it means to listen to the organization before deciding what to change.