The Data Sorcerer
You come to me with a question.
I'll give you a vector by close of business,
and a magnitude in two days.
// who I am
I spent 20+ years at Verizon doing something most data people don't get to do: staying long enough to actually know the data, instead of just querying it.
There's a difference between a wizard and a sorcerer. A wizard studies — meticulously, slowly — and eventually hands you a beautiful, complex dashboard that only they know how to read. A sorcerer already has the power innate and can provide the answers you seek from his long accumulated knowledge.
I was in the room when the data was built. I don't need weeks to study it — I need minutes to draw on it. That's where the nickname came from. A VP I worked under, both of us D&D players, needed a title that actually described what I did. Not "analyst." Not "wizard." Sorcerer.
Give me a fire drill, and I'll tell you by end of day whether your promotion is statistically significant and worth continuing. Give me two more days, and I'll tell you exactly how many dollars it's worth. Speed first, precision close behind — not the other way around.
// how I work
Every spreadsheet I hand off comes with the SQL behind it. If I'm on vacation, someone else just runs the query. No bus-factor-of-one nonsense.
I was one of the first people tapped to work in Verizon's new BigQuery environment, and instead of waiting for requirements, I started building the "Lego blocks" — small, reusable, minimum-viable components that later became the foundation the rest of the department's systems were built on. That's the real trick behind fast answers: the backend work is already done before you ask the question. By the time there's a fire drill, I'm not starting from zero — I'm just assembling pieces I built months earlier.
Most of my career moves weren't applications — they were people I'd worked with reaching out years later because they remembered what I could do.
I use Claude Code daily. I know where it earns its keep, and I know where a deterministic, boring answer is still the right one.
// the sorcerer, applied
The Sorcerer thing isn't just a fun title — it's how I actually work when a problem shows up sideways.
A dashboard was bleeding $70 every time someone refreshed it.
Nobody had flagged it — it just looked like normal compute. I traced it to a single value buried in unstructured text, forcing a full regex scan of a massive table on every refresh. The fix wasn't clever code, it was seeing the invisible cost: pull that value out once, upstream, into its own column. $70 became a rounding error.
A $9M/quarter leak that was invisible until the money was already gone.
Trade-in offer value was being measured 45 days after the fact — accurate, but useless, like reading yesterday's stock price to make today's trade. I built a same-day model instead. Same rigor, delivered while it still mattered.
When a schema breaks, someone has to be in the room who remembers why it was built that way.
I was one of four people who rewrote how the company measured revenue per account from the ground up. The boring part was the six months of rulings. The important part was building it to survive device categories that didn't exist yet — so nobody would have to relitigate it later. It's still the standard.
That's the actual trick. Not magic — two decades of pattern recognition, and enough range to go from "put this fire out by 5pm" to "rebuild the foundation so it doesn't happen again."
// portfolio
Work in progress — projects added as they're built.