I go deep, then come back up with words you can understand.
I'm a scientist who goes all the way down into a system or situation, then comes back up with a cohesive account of what's actually happening; one your engineers and executives can act on from the same page.
I go deep into complicated situations and come back with a clear account of how they actually work.
The situations that lead here.
Concrete situations, not categories. If one of these is your quarter, we should talk.
A system everyone depends on and nobody wants to touch, because the people who built it are gone.
An AI initiative where no two people give the same answer about what it actually does.
A team whose delivery slowed, and nobody can say precisely where.
An acquisition, and two stacks that have to be understood before they can be merged.
A vendor's claims that nobody internal is positioned to evaluate.
A production system that passes every test and is still producing something wrong.
Down into the mess, then back up into something you can act on.
Three moves, in sequence. The third is what makes the first two worth paying for: anyone can produce a 60-page findings document nobody reads.
Go down.
Into the code, the documents, the decision history, the interviews, as deep as the material goes.
Extract the chain.
What actually happens, in what order, driven by what. Not the architecture diagram, the real one.
Come back up.
Place it in a class of system whose behavior is already understood, so its known properties become available to your team.
What the work looks like.
A few representative engagements, going deep into a hairy system or situation and coming back with the account of how it works. The range runs from a room of executives to a production codebase.
Correct implementation, wrong operating point.
I went into a product built on mathematics from four different fields, chaotic maps, strange attractors, fractals, cellular automata, and came back with a single sentence that described what was wrong with all of it: correct implementation, wrong operating point. The silent defects were the proof that the descent happened; the one-sentence class was the point.
What the technology actually does
A leadership team was set to commit budget to an AI plan assembled from vendor decks. I gave them an independent read of what the technology can and can't actually do, in terms they could act on, before the spend.
An accurate model of their own tools
A team had wired an AI tool into a production workflow and couldn't say where to trust it. I mapped where it was reliable and where it wasn't, so they leaned on it where it earned trust and stopped where it didn't.
A roadmap that assumed too much
A proposed roadmap assumed capabilities the models don't reliably have. Tracing the assumptions back to what is actually known reclassified the hard part and reordered the plan around what would work.
The product, not the pitch
Ahead of a major purchase, a team wanted a vendor's performance claims checked against evidence. I verified and reproduced what could be, so the decision rested on what the product does, not what the deck says.
Three depths, one move.
All three are the same descent-and-return at different depths: go down, then come back up with something a team can act on. That covers a room of executives and a production codebase alike. Start wherever the question is.
Briefings & speaking
What the state of the art actually is, what it does, and what it means for this organization, delivered so an executive team can act on it. Includes conference and internal-event speaking.
- conference keynotes
- executive briefings
- internal events
Advisory
AI strategy, architecture review, and build-vs-buy, plus helping teams form an accurate working model of the tools they're already using, so they trust them exactly as far as the tools deserve.
- AI strategy
- architecture review
- build vs. buy
- team working model
Deep engagement
Going all the way into a system, a stack, a pipeline, or a team's working dynamic, and returning a cohesive account of how it operates. Delivered as written findings. The object is not always code.
- a vendor's claims
- a proposed roadmap
- a delivery process
- an acquired stack
- the production system
I'm a scientist, which means I come in from the outside with no stake in the existing explanation, architecture, or proposed solution. My job is to determine what is actually happening.
I go all the way down into a problem, then come back up with a cohesive account your whole team can act on. The critical step is classification: identifying what kind of system or problem you're actually dealing with, which properties matter, and what established body of knowledge applies to it. A problem that is classified correctly becomes much easier to diagnose.
The second advantage is independence. I have nothing to sell downstream and nothing to gain from the answer being reassuring. I'm there to make the situation legible. Finding what's broken along the way is often just a byproduct.
Enterprise delivery for Fortune 500s over many years.
Author of Discovered, Not Designed (2024).
Research published on Zenodo.
Notes2Tree makes structure visible.
Notes2Tree takes your material: notes, meeting transcripts, backlogs, code…and turns it into representations you can reason with. See hierarchy, sequence, process, causality, argument, and relationships that are difficult to see in the raw material.
Different views expose different properties of the same system, helping you understand how it works, diagnose where problems lie, and decide what to investigate next.