Nobody in your organization fully understands your most important systems.
That isn't a failure, it's how these things get built: dozens of people over many years, and the whole picture was never anyone's job. I'm a scientist who goes all the way down into a system, then comes back up with a cohesive account of how it actually works, one your engineers and executives can act on from the same page. I assemble it.
I go into systems no one fully understands and come back with a clear account of how they 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, and my field is complexity: making sense of systems whose behavior isn't legible from their parts, systems nobody designed top-down and nobody fully controls.
That is exactly what your most important systems present. Complexity science is the study of systems whose behavior isn't legible from their parts; I go all the way down, then come back up with an account your whole team can act on. Two things this buys that a delivery vendor cannot: classification, placing your system in a category whose behavior is already understood, and independence, no stake in the answer being reassuring. Finding what's broken along the way is a byproduct.
Prior enterprise delivery at Ford and CSX.
Author of Discovered, Not Designed (2024).
Research published on Zenodo.
Notes2Tree makes structure visible.
Notes2Tree takes your own material, notes, meeting transcripts, backlogs, code, and gets it into a shape where the structure already inside it becomes visible. A way to start reasoning about how your work actually hangs together, in the same spirit as an engagement.