The person behind QAMW — and why being the one who stays in the problem is both a personality trait and a professional methodology.
Growing up, I thought my dad's computer stuff was the nerdiest thing in the world.
Our house and garage were full of machines at every stage of building and use. I avoided helping him most of the time. But I couldn't avoid the arguments. My dad was a nerdy military man who was confident he knew everything. So was I. We argued about definitions, concepts, words. Once I used the word "innate" to describe someone's response and he swore I had it wrong. I didn't. I looked it up and held my ground.
That stubbornness stuck. So did the tech. Growing up surrounded by computers at every stage meant I was never afraid of them. I built PCs. Set up VoIP systems. Learned dinosaur-age coding languages when the main developer retired and nobody else would touch it. Built company-wide reporting systems from scratch. I became a techy jack of all trades, not because I planned it, but because I was always the person willing to stay in the problem until it was solved.
That willingness is what took me to a last-mile logistics startup drowning in a report that took 12 hours to build every week and was still 20% off at the end of it. They couldn't set goals. They couldn't plan. They just argued about whose numbers were right.
I went in and looked at everything. The data warehouse. The operations managers. The regional structures. What I found wasn't a data problem. The business had grown, added locations, changed how it operated. The software was still frozen in the version of the company that existed in its first quarter. Nobody had ever gone back to close that gap.
That's what I do. I find the space between how a business actually runs and how its systems think it runs. Smart people miss it. Senior engineers miss it. Executives miss it. Not because they aren't good at their jobs. Because closing that gap requires someone stubborn enough to keep looking after everyone else has moved on.
The girl who rolled her eyes at her dad's computer lab now does her best work when she's handed an unstructured beast of data and told nobody's been able to figure it out.
Gap exposer. Data destroyer.
Immersive means sitting with the people who actually do the work — not just reviewing documentation or interviewing leadership. The real system is rarely the documented one. It's in the workarounds ops managers built three years ago, the spreadsheet someone emails themselves every Friday, and the Slack message that functions as the company's actual data pipeline.
Most systems problems persist because everyone assumes someone else has already asked the obvious question. Nobody has. Immersive research means slowing down long enough to ask why a report is built the way it is, when the original business logic was last reviewed, and whether the tool still reflects how the company actually operates — or just how it operated when the tool was configured.
A gap identified but not closed is just a better-documented problem. The work isn't done when the audit is delivered — it's done when someone understands what changed, why it matters, and exactly what to do next. That's the difference between a report that gets read once and a system that actually runs differently on the other side of an engagement.
Start with a free 20-minute discovery call. No pitch — just an honest look at what's not working.