APPROACH / CLIENT WORK
How I work with clients.
I learn how the work actually happens, make the constraints visible, and bring business, risk, and technical teams toward a solution they can put into practice. AI is one possible answer, not the starting assumption.
How is the work done today, where does it break down, and what would make it meaningfully better?
The answer may be a redesigned process, deterministic automation, or AI.01 / GETTING ORIENTED
Enter as a learner. Build domain fluency quickly.
I often join a project in a function where I am not initially the subject-matter expert. I start with the people who run the process: what they do, which decisions they make, where information comes from, and which exceptions consume their time. I review the artifacts and systems behind their answers until I can describe the current state back to the team accurately.
That is the basis for asking better questions—not a substitute for the client team’s expertise.
02 / CLIENT COLLABORATION
Keep different perspectives in the same design.
Executives, practitioners, risk stakeholders, and technical teams often see different parts of the same problem. I translate between them without flattening the constraints each group is responsible for.
01Business leaders
What outcome would make the change worthwhile?
A clear priority, scope, and measure of success.
02People doing the work
Where do handoffs, exceptions, and workarounds actually occur?
A current-state view grounded in daily practice.
03Risk and governance
Which decisions need evidence, review, or a named owner?
Control points designed into the workflow.
04Data and engineering
What can the data, systems, and delivery team support?
A feasible architecture and test boundary.
03 / FROM DISCOVERY TO DELIVERY
Make the path from problem to operating change explicit.
The shape of an engagement varies. These are the decisions I want a team to make together, and the working outputs that make progress reviewable.
- 01
Understand the current state.
Work with the team to trace the task, its data, handoffs, exceptions, and controls. Separate the stated problem from the friction people encounter in practice.
WORKING OUTPUTShared process map and problem definition - 02
Choose the intervention.
Compare process redesign, deterministic automation, and AI against the decision to be supported. Make data readiness, risk, effort, and ownership part of that choice.
WORKING OUTPUTOptions, trade-offs, and a recommended path - 03
Prove the important parts.
Build a bounded example with acceptance checks and realistic exception paths. Show what the prototype demonstrates—and what it does not yet validate.
WORKING OUTPUTTestable prototype and evaluation criteria - 04
Design the operating handoff.
Work through review roles, integration needs, monitoring, enablement, and the changes required in the surrounding process. A recommendation is not the end of delivery.
WORKING OUTPUTFuture-state workflow and adoption plan
- Process redesign
- Is an unclear handoff or decision creating the friction? Clarify the work and its owner first.
- Deterministic automation
- Are the inputs and rules explicit? Make the rule inspectable and test its exception paths.
- AI assistance
- Does the task need interpretation or synthesis? Define source evidence, evaluation, and human review.
This example summarizes the choices described above. It is not a proprietary method, a client artifact, or an approval framework.
HOW THIS SHOWS UP HERE
Inspect the decisions in the work.
These are independently owned software and fictional design exercises, not reproductions of client engagements. Professional experience and cleared outcomes are documented separately in my résumé.
LET’S TALK