Start with the operation
Most of the work I take on starts the same way: something in the organization costs more than it should, and nobody can point to the line where the loss happens. You can diagnose a condition like that, and it’s the right place to begin.
Where I’m useful
The pattern repeats with surprising regularity. Work passes through more hands, systems, and approvals than the result needs, and somewhere along the way the organization has already tried to fix it by buying software.
The tool did not fix it
The platform’s in place and people genuinely use it, yet the operation still behaves the way it did before, because nobody changed the arrangement underneath.
The work stalls between functions
Look at any one team on its own and the pace seems reasonable enough. The time goes missing at the handoffs, where nobody’s quite sure anymore who owns the work, what comes next, or where it stands.
Reporting arrives after the decision
The numbers are right and they arrive too late to act on, because the slow part is gathering and assembling them. The analysis itself rarely holds anything up.
Capacity is the binding constraint
There’s more work coming in and the headcount isn’t there to meet it, so the useful question is how much more the existing operation could carry if it were arranged differently.
AI is on the roadmap
There’s pressure to deploy something and no clear answer about what it would change. Deciding where automation carries real leverage is a question about how the work moves, and it needs answering before anyone picks a technology.
How an engagement runs
Every phase leaves the organization with something it keeps, and any phase can be the last one if the evidence says the next isn’t worth buying.
Diagnostic
Close observation of the work as people actually do it, which has usually drifted some distance from the version that was written down. The output is a written account of where the operation loses time, money, or capacity, and what’s causing it. The diagnostic takes two to four weeks and stands on its own, and some organizations take it and act on it themselves.
Design
The smallest system that relieves the constraint the diagnostic found, whether that’s workflow, data, software, automation, organizational design, or some mix of them. Before anything gets built, the design names the measure it’s meant to move and the baseline it starts from.
Build and deploy
Built against actual cases pulled from the work, and deployed into live conditions. Volume, exceptions, and habit surface requirements no interview will, so this phase is expected to change the design at least once.
Hold and hand off
Going live is a milestone along the way. The engagement ends later, once the measured change holds under normal operating conditions and the organization can run, explain, and change the system without me.
Not every engagement needs all four. Often the diagnostic is the whole job, and sometimes the honest answer at the end of it is that the operation doesn’t need a system built for it at all.
How I work
Proximity
I work close to the operation, alongside the people doing the work, because that’s the only place the real specification lives, most of it in their heads and habits.
A named measure
Every engagement carries a measure and a baseline we agree on at the start. If we can’t define the number yet, we don’t understand the problem well enough to solve it.
Software last
Technology is a component, and if the operation can be fixed without building anything, that’s what I’ll recommend.
No dependency
If the organization can’t maintain the system without me, I haven’t finished building it.
Common questions
What does an engagement cost?
Engagements are priced by scope, with no hourly billing. The diagnostic is quoted as a fixed fee before it starts. Design, build, and deployment get priced once the diagnostic has shown what actually needs building, which is also why there’s no published rate card.
Do you work on-site or remotely?
Close to the operation, wherever that happens to be. The diagnostic works best in person, since the whole point is to watch the work as it’s actually performed. Build and deployment run remotely where the work allows and on-site where it doesn’t.
What size or type of organization is this for?
Engagements have run from enterprise operations to regulated environments where confidentiality is a condition of the work. What matters isn’t the size of the company, it’s a cost that could be diagnosed and hasn’t been yet.
What if the diagnostic finds nothing worth building?
Finding nothing worth building is still a real result, and a useful one to have before spending money on a build. The diagnostic stands on its own, and some organizations take the finding and act on it themselves. Commissioning one doesn’t commit you to design or build.
Is the work confidential?
Yes. Every engagement is confidential by default, which is why some of the case studies here don’t name the client.
Do you provide ongoing support after handoff?
There’s no standing retainer. An engagement is complete when the organization can run, explain, and change the system without me, and if I still have to keep it running, the work isn’t finished.
Begin with the diagnostic
If something in your operation costs more than it should and you can’t quite find the line item, I’d like to hear about it. LinkedIn is the best place to reach me.
Send a short note on what’s happening and what it seems to be costing you. Useful things to include are the operation in question, the symptom you can see, what’s already been tried, and the measure you’d want to see move. A paragraph is plenty.
Engagements run through Revuity Systems. I’m based in Los Angeles and work with organizations across the United States.