I learned troubleshooting on a meditation cushion.

Odd start for a data guy. Let me explain.

As a kid I practised Zen meditation. The first lesson is the only one that ever mattered: observe before you react.

Twenty years in IT taught me the same thing works on software.

The bug is rarely where the error appears
The slowdown is rarely the tool everyone blames
The fix is obvious only after you have seen the real problem

I started as a data analyst. I became the person companies called after everyone else had guessed wrong. At one point I was flown to the Atlanta office to untangle configuration issues nobody there could crack.

It was never technical genius. It was sitting with the problem longer than anyone else was willing to.

Same habit, different decade

The systems got more complex and the noise around AI made root-cause thinking rarer, not more common. Everybody is in a hurry to prescribe. Almost nobody stops to diagnose.

So the work I do now is the work I have always done. Someone tells me what is wrong. I go and find out what is actually wrong. Those are usually two different things.

These days I do it for consultants and fractional executives, people who run a practice the way I run mine. The question is usually how to win more clients. The answer usually starts with the work around the client work: proposals written from scratch, prospects nobody followed up, the same update typed out for every client. Fix that, and there is room for both the clients you have and the next one.

I don't trust things that look fine

I am also building Alacrio, a work assistant that watches your inbox and calendar for the things you would otherwise miss. Underneath it is Tarkavi, a reasoning and dispatch engine I built across six structured sessions: scaffold, reasoning engine, action dispatcher, memory and feedback loop, proactive scheduler, and a full security audit.

The audit was the point. It caught cross-tenant data leaks, missing auth checks, and race conditions. Bugs that never show up in a demo and always show up in production, usually at 2am, usually as somebody's angry email.

46 tests passing. Every one of those issues fixed before a single user touched it.

I am telling you this because it is the standard the consulting work is built to, not because it is a client result. It is not one. It is how I work when nobody is watching, which is the only useful thing you can know about someone you are about to hire.

What I can and can't show you yet

This consulting offer is new, and I do not have published before and after numbers from it. I am not going to invent them, and I am not going to write a composite client and present it as real.

What I have done instead is build the measurement into the work. Every sprint starts by measuring what the target workflow actually costs, in week one, agreed in writing. Then again at day 30 and day 90.

So the numbers are coming, and when they appear here they will be real ones with a method behind them.

Observe first. Fix second.

That order changes everything, and it is the whole reason this business exists. If you want to know where your own week is going, that is four minutes and it costs nothing.

Take the Manual Work Scorecard →