How I Work

Find the Constraint

Every system has one constraint. I find it first.

Every operation has a bottleneck — one thing that limits throughput more than anything else. Most teams try to improve everything at once. That spreads resources thin and produces marginal gains across the board while the actual constraint stays untouched.

I start by mapping the system end-to-end: workflow, handoffs, decision points, failure modes. The constraint is rarely where leadership thinks it is. It’s usually hiding two or three layers deep — in a manual data entry step nobody questions, in an approval chain that adds three days, in a piece of tribal knowledge that lives in one person’s head.

Fix the constraint, and the whole system accelerates. Optimize anything else first, and you just create a faster way to wait.

Simplify Before Automating

Question every requirement. Delete before building. Simplify before automating.

The most expensive AI project is the one that automates a process that shouldn’t exist. Before writing a single line of code, I audit the workflow. Every step gets challenged: Why does this exist? What happens if we remove it? Who added this requirement, and is the original reason still valid?

Most processes accumulate steps over time — workarounds for old problems, compliance measures for retired regulations, manual checks that cover for upstream failures. Stripping these out before building anything means the solution is smaller, cheaper, faster to ship, and easier to maintain.

Automation should make a clean process faster. It should never make a broken process permanent.

AI is the Last Step

AI is the last step, never the first.

When someone says "we need AI," what they usually mean is "we have a problem we can’t solve with our current tools." AI might be the answer. But so might a spreadsheet, a better dashboard, a process change, or a direct conversation between two departments that don’t talk to each other.

I work backward from the problem, not forward from the technology. If AI is the right tool, I’ll build it. If a $0 process fix eliminates the need entirely, I’ll tell you that instead. The goal is solving the problem, not deploying a model.

Read the Human Terrain

Read the human terrain — the politics, the resistance, the fear — not just the technical system.

Every technical system runs on a human system. The org chart, the incentive structures, the informal power dynamics, the person who’s been doing it this way for 15 years and sees your "optimization" as a threat to their job.

I learned this in Special Forces. You can build the most technically perfect solution in the world, and it dies on contact with the organization if you haven’t mapped the human terrain first. Who benefits from the current system? Who loses if it changes? What’s the real reason the last three improvement projects stalled?

Technology adoption is a people problem. I solve it like one.

Iterate, Don’t Plan

Build through rapid iteration, not waterfall plans.

Six-month AI roadmaps are fiction. The technology moves too fast, requirements shift as stakeholders see working prototypes, and the gap between "what we think we need" and "what actually works" only closes through testing.

I ship working versions fast — days or weeks, not months. Each iteration gets in front of real users, collects real feedback, and informs the next build. If something doesn’t work, we find out in week two, not month six.

The result is a solution shaped by reality, not by a slide deck from last quarter.