ABOUT RHO
Your business probably didn’t become complicated all at once.
If you lead a growing ecommerce, retail, or founder-led company, the systems that support the business probably grew the same way the business did:
One decision at a time. A new report got built because someone needed an answer. A new process was created because the old one couldn’t quite handle what came next. Someone figured out how two systems fit together. Someone else became the person who remembered why a metric was defined a certain way. Those decisions worked.
The business grew up.
I’ve spent my career inside this problem.
At Purple, I inherited a reporting environment with thousands of dashboards.
Eventually, I deletedover 2,000of them. They weren’t there because people were careless. They accumulated because the business was moving quickly and people were solving the problems in front of them.
I’ve seen the same pattern in code, data models, reports, spreadsheets, processes, and teams. The business grows. The systems grow with it. And eventually, nobody can see the whole thing anymore.
You may recognize some version of this.
You have a hundred models and regularly use a fraction of them. Different teams use slightly different definitions for the same number. A meeting that should be about making a decision turns into a debate about which report is right.
A process works because a few experienced people know how to make it work. Someone remembers why a decision was made three years ago, but it was never really documented.
The information exists.
The systems exist.
The people are capable.
But more and more of the business depends on someone remembering how everything connects.
That dependency gets expensive.
At first, it looks like inconvenience. A report takes longer to validate. A project gets delayed. Someone has to explain the same decision again. An executive becomes the person stitching it all together.
Then one of those people leaves. And suddenly the company doesn’t just lose a person. It loses the reasoning, history, and connections that person held together.
The questions get harder as the business grows.
Sales affects inventory.
Inventory affects warehouse capacity.
Returns affect finance, merchandising, operations, and the customer experience.
Marketing data needs to connect to what customers actually buy.
AI and automation create new possibilities, but they depend on information the business can actually trust.
At that point, another dashboard rarely solves the whole problem.
You need to understand what the friction is telling you.
That’s where I come in.
I’m a BI architect.
I work in the space between technology, data, business decisions, and the people who understand how the company actually works.
My job is to help make the hidden connections visible.
Sometimes that means simplifying a reporting environment.
Sometimes it means rebuilding a data model.
Sometimes it means documenting decisions that have been living in someone’s head.
Sometimes it means discovering that the technical problem everyone has been trying to solve isn’t really a technical problem at all.
I don’t start by gathering requirements.
A lot of technical projects begin with a seemingly reasonable question:
What do you want us to build?
The business is expected to describe the finished solution before anyone has really explored the problem. So everyone works hard to document the requirements. Then the solution gets delivered. And the conversation goes something like this:
“That’s not what I asked for.”
“But it meets the requirements.”
Both sides leave frustrated.
The business starts to feel like the technical team doesn’t understand how the business actually works. The technical team feels like it did exactly what was asked. And over time, the relationship gets worse.
Business teams learn that they have to be extraordinarily precise about every request. They start trying to design the solution themselves because they’re afraid that anything left ambiguous will come back wrong.
Technical teams become increasingly dependent on detailed requirements because that’s how success is being measured. Now the people closest to the problem are being asked to prescribe the technical solution, while the people best equipped to build the solution are being asked to follow the prescription.
I work differently.
I start with the person, the problem, and the pain it is creating. I research how the problem actually shows up in the business. Then I build something quickly. A prototype. Something concrete enough to react to.
A CFO once gave me the clearest explanation of why this works:
“Give me something to look at.”
That stuck with me.
People struggle to design a solution from a blank page. Give them something real and the conversation changes:
This part is right.
That isn’t what I meant.
What if we looked at it this way?
Now that I can see it, here’s what I actually need.
That feedback isn’t a failure of the requirements.
It’s part of discovering the solution.
Start by following the friction.
The process is simple:
- Bring the thing that feels harder than it should.A report nobody trusts. A process that depends on one person. A project that keeps stalling. A decision you can’t quite get comfortable with.
- Follow it to what’s really driving it.We connect the facts, test assumptions, surface contradictions, and look for the dependencies underneath the visible problem.
- Decide what deserves attention next.You leave with a clearer view of what matters, why it matters, and what needs a closer look.
Good systems should preserve what makes the business work.
Growth creates pressure to formalize things. That doesn’t mean replacing judgment with process or turning a creative company into a bureaucracy. The goal is to preserve the knowledge, flexibility, customer understanding, and decision-making that helped the company succeed.
Build enough structure around those strengths that they can survive the next stage of growth.
You shouldn't have to be the one stitching it all together.
The decisions shouldn’t live in someone’s memory. The definitions shouldn’t depend on who happens to be in the room. The connections between teams, systems, and processes shouldn’t disappear when someone leaves.
The system should carry that memory for you.
It should preserve what was decided, show how the pieces connect, and make conflicting assumptions easier to see. So your people can spend less time remembering how the business works and more time thinking, creating, and deciding what comes next.
That’s why I created Follow the Friction.
Bring the problem that keeps pulling at your attention.
We’ll start there.