Start with the operation
Most of the work I take on begins the same way: something in the organization costs more than it should, and no one can point to the line where the loss occurs. That is a diagnosable condition, and it is the place to begin.
Where I’m useful
The pattern is consistent. Work moves through more hands, systems, and approvals than the outcome requires, and the organization has already tried to fix it by buying software.
The tool did not fix it
A platform is in place, adoption is real, and the operation still behaves the way it did before. The arrangement underneath was never changed.
The work stalls between functions
Nothing is slow inside any single team. The time disappears at the handoffs, where ownership, sequence, and status stop being explicit.
Reporting arrives after the decision
The numbers are correct and too late to act on. Assembly cost, not analysis, is the constraint.
Capacity is the binding constraint
More work is required and headcount is not available. The question is what the existing operation could carry if it were arranged differently.
AI is on the roadmap
There is pressure to deploy something and no clear answer to what it would change. Deciding where automation carries real leverage is a systems question before it is a technology one.
How an engagement runs
Each phase produces something the organization keeps, and each one can be the last if the evidence says the next is not worth buying.
Diagnostic
Close observation of the work as performed, not as documented. The output is a written account of where the operation loses time, money, or capacity, and what is producing it. Two to four weeks, and it stands alone. Some organizations take it and act on it themselves.
Design
The smallest system that relieves the constraint identified in the diagnostic. Workflow, data, software, automation, organizational design, or a combination. The design names the measure it is meant to move and the baseline it moves from, before anything is built.
Build and deploy
Built against real cases rather than representative ones, 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
The engagement is complete when the measured change holds under normal operating conditions and the organization can run, explain, and change the system without me. Not at deployment.
Not every engagement needs all four. The diagnostic is frequently the whole job, and the honest answer at the end of one is sometimes that the operation does not need a system built for it.
How I work
Proximity
I work close to the operation, with the people doing the work, because that is the only place the real specification exists.
A named measure
Every engagement carries a measure and a baseline agreed at the start. If the number cannot be defined, the problem is not yet understood well enough to solve.
Software last
Technology is a component. Where the operation can be fixed without building anything, that is the recommendation.
No dependency
A system the organization cannot maintain without me is an unfinished system, not a retainer.
Begin with the diagnostic
If something in your operation costs more than it should and the line item is hard to find, that is the conversation worth having. LinkedIn is the best place to reach me.
Send a short description of what is happening and what it appears to be costing. Useful to include: the operation in question, the symptom you can observe, what has already been tried, and the measure you would want to see move. A paragraph is enough.
If you would rather write directly, jay@revuitysys.com.
Engagements run through Revuity Systems. Based in Los Angeles, working with organizations across the United States.