What I actually do

Two kinds of engagement, priced and scoped differently, because they're solving different problems. Most clients need the second one.

Lane two — the majority of my work

Operations & process consulting

You have a bottleneck, and you're not convinced software is the answer. You're probably right. I come in, look at how the work actually moves through your organization, and tell you what's really causing the delay.

A whiteboard divided into To do, In progress and Done columns, with handwritten sticky notes in each

Typical starting symptoms

  • One person is manually moving data between systems, and everything queues behind them.
  • Approvals stall because nobody agreed who decides what, at what threshold.
  • The numbers people need to make a decision live somewhere they can't reach in time.
  • A process was designed for a smaller organization and nobody has revisited it since.
  • You're being sold a platform and you want an independent read before you sign.

What you get

  • A current-state map of how the work really happens — workarounds included.
  • Stakeholder interviews across every group the change would touch, not just the person who hired me.
  • An independent test of vendor capability claims against your actual systems.
  • A phased recommendation where phase one is low-risk, reversible, and worth doing on its own.
  • A written rationale you can hand to a board or a finance committee.

Sometimes the deliverable is "don't do this." That's a legitimate outcome and you'll still get the full reasoning behind it. Knowing which project not to fund is worth more than most projects.

See a worked example

Lane one

When AI is already in the picture

Two versions of this, and they need opposite things.

Someone working at a laptop on an ordinary desk beside cardboard file boxes

A. Something you deployed isn't working

An automation stopped firing and nobody noticed for weeks. A tool went in and adoption never happened. Output that was fine in the demo is unreliable in production. Or the person who built it has left.

  • Diagnosis of what actually broke — the model, the data, the integration, or the process around it. It is usually the last one.
  • A straight answer on whether it's worth repairing, replacing, or switching off.
  • If it's worth keeping: documentation and a maintenance path so it isn't one person's private knowledge again.

B. You want to try something small before committing

You've heard enough about AI to want a real answer for your own organization, but not enough to justify a platform contract. Good instinct. The right next step is one narrow pilot, not a strategy.

  • One specific, bounded use case — chosen because it's measurable, not because it demos well.
  • A fixed scope, a fixed end date, and a defined "this worked / this didn't" test agreed up front.
  • Reversible by design. Nothing your team can't walk away from.
  • An honest write-up at the end, including when the answer is that it isn't worth scaling.
What a pilot can cover

How engagements are structured

Every engagement starts with a free 30-minute conversation, and I'll tell you in that call whether I think I'm the right person. After that, work is scoped in phases with a defined deliverable at the end of each one, so you're never committing to an open-ended project.

I work solo. You're not getting a pitch team and then a junior. The person in the discovery meeting is the person doing the work.

Start with a conversation

Thirty minutes, no charge, no obligation — and a straight answer about whether this is worth pursuing.