Forward Deployed Engineeris the work I was already doingbefore I saw the title.

Why leave a co-founder and CIO seat for an individual-contributor Forward Deployed Engineer role?

Because Forward Deployed Engineering is the work I love most, stripped of the agency overhead. As CIO my role drifted into running a client-services business; the part that lights me up is being in the room with a customer, turning an ambiguous problem into a shipped system. I stepped out of ELO's operating role in August 2026 and stayed on as co-founder and advisor precisely so I could take this seat properly. The titles matter less than the work — I have been hands-on every year of that chapter, still shipping TypeScript, Python and Go daily, and the thing I never wanted to give up was being the engineer in the customer's room owning the architecture. The leadership range comes along as a bonus: I can mentor across disciplines and lead a workstream when an engagement needs it, without the org chart having to say so.

Is he genuinely set up for relocation, on-site embedding and heavy customer travel?

Yes, and the ties are concrete rather than aspirational. London is the densest frontier-tech hub outside the US West Coast and gives the most customer proximity for embedded work — and my sister lives there. Norway is both personal and professional: my closest friend is in Oslo, I delivered the Frontgo and Vipps work there, and two ELO alumni now lead teams in the country. Canada is professional first — four years embedded with AudioBin and SkyTracks, plus delivery into Quebec. On paperwork: UK Global Talent is self-sponsored and I am actively pursuing it independently of any single role, with UK Skilled Worker, the EU Blue Card and Canada's Global Talent Stream all viable, and I qualify on experience rather than a degree, which most of those routes accept. I relocate as soon as the visa processes, commit to local business hours from day one, and treat heavy customer travel as how you learn the operational truth rather than as a burden. Travel bands on this role typically run from 20% to 75%; the pattern I already run is heavier than most of them.

His production AI is Claude-led with Gemini second. Why him for our model or platform?

I will say it plainly, in a customer's room too: my production stack is Claude-led, and the model or harness underneath gets picked per task rather than by vendor loyalty. But the Forward Deployed Engineer job is not about which model — it is about carrying frontier models into the messy reality of an enterprise: discovery, scoping, system design, rollout, and the evaluation-driven loop back to Product and Research. That skill is model-agnostic, and I have proven it in production. In practice I keep the client code model-agnostic anyway and focus on tool-calling architecture, retrieval and evals, because in production the best model is the one that does the job reliably and cost-effectively. I would rather be the engineer who is candid about where he is coming from and ramps visibly than the one who oversells.

You have never worked at a frontier lab, or inside a vendor of this category.

True, and it is a deployment role, not a research role. The job is carrying the lab's models into the messy reality of enterprise, and that is what I have done for nine years. The team does not need another model trainer; it needs someone with deployment callouses who can earn a strategic customer's trust, scope a use case end to end, contribute in the code and ship it reliably, then feed what the field learns back to Product and Research. There is also an advantage in coming from the buyer's side: as ELO's CIO I was the engineering leader who evaluated, rolled out and enforced tooling across teams, so I know first-hand every objection a VP of Engineering raises during a pilot — and what makes a tool spread through an organisation instead of stalling at one champion.

Is your stack actually a fit? This role often wants Python.

Squarely inside it, with one honest note. JavaScript, TypeScript and Go are my production core, and Python is where my AI and data work lives — VisaPros is Python and FastAPI microservices end to end. I will not pretend Python is my deepest production language. What I will say is that the discipline this role actually asks for — clean, testable, observable, scalable — is language-agnostic and exactly how I ship: typed contracts, CI gates, Jest, Cypress and Playwright suites, structured logging. Give me real features to build in Python from week one and I will carry those habits across; that ramp is measured in weeks.

How would you build evaluation for agent quality beyond trial and error?

The same way I treat compliance: designed in and measurable from day one, not bolted on. I would start by pinning down success criteria with the customer in their numbers, then build golden eval sets and captured traces so every change is graded on accuracy, safety and latency rather than vibes. Those scorecards go into CI so regressions are caught automatically, and I keep offline evals separate from production telemetry so real-world drift is visible. I already run a version of this: NewScriber's grounding evals gate every generated script against its source before synthesis, in daily production. What I have not yet built is the metric-driven harness that shapes a roadmap — that is a four-to-eight-week ramp, and it is on my list either way.

You have run the company for nine years. Can you be the technical lead in a pod where someone else owns the commercials?

That division of labour is exactly how ELO worked — I led scoping, architecture and delivery while a business counterpart handled pricing and contracts. Nine years of being accountable to clients without controlling every variable is good training for influence without authority. And frankly, shedding the commercial load is the point: I want more hours in the repository and in the customer's architecture, and fewer in contract negotiations. I know from the founder's side how rare it is to have someone senior who does not need managing — that is who I intend to be in the pod.

How would you run your first pilot?

Scope it like an experiment with a promised result. First, sit with the customer's engineering leadership and map the architecture and the constraints, including the security and data boundaries, because in an enterprise those decide what is even possible. Then define success in their numbers — hours not spent, queries deflected, review time saved — and instrument from day one so the rollout debate is evidence rather than opinion. Run it with one team and find the staff engineer whose workflow visibly improves; that person, not a slide, is what carries the tool through the organisation. Where rollout is blocked by something deep in the product, it goes back to the core team with a precise reproduction rather than a vague complaint. And write down everything that was slower than it should have been, because the playbook is the second deliverable of every early pilot.

You don't have a completed degree, and this role often lists one as required.

Correct, and it is named on the requirement ledger above as "ramping" rather than buried. Field of study is Computer Science & Engineering at North South University, not completed. That requirement is almost always written as "or equivalent practical experience", and nine years of shipping production systems — including the exact HIPAA, GDPR and multi-tenant auth work those degrees are meant to signal readiness for — is the practical-experience case. I would rather a hiring loop see the honest gap named plainly than discover it themselves later.

Isn't a page like this just a clever trick — engineered to sound tailor-made rather than being genuinely qualified?

Fair question, and the way to check it is to read the ledger, not the pitch. Every requirement is quoted in the industry's own words rather than paraphrased into something flattering, and the honest ramps are printed in the same table as the strengths — a marketing page does not volunteer its own weak spots. The method is the opposite of spin: rather than writing one generic pitch and hoping it lands, I took what this role actually demands and answered each line on its own terms. If your posting reads differently from this, that is worth a direct conversation — the underlying evidence does not change, only which parts of it matter most to you.

What happens when a customer relationship goes badly — a stalled pilot, a stakeholder who has gone cold?

It has happened, and the fix is always the same: get back to a shared, numeric definition of success before trying to fix the relationship. At Frontgo, requirement gaps and communication friction were a recurring risk on a pod I coordinated at arm's length from the client's own PM; the response was tighter weekly syncs and naming blockers explicitly rather than letting them go unspoken. A stalled pilot is usually a scoping failure from week one, not a technology failure — so I re-open the success criteria conversation rather than pushing harder on the same plan. And I would rather surface a doomed pilot early and reset it than let it limp to a quiet non-renewal.

After nine years setting your own direction, how do you actually take technical direction from someone else's architecture decisions?

I have done it inside every client engagement ELO ran — the client's platform, the client's constraints, my job to deliver inside them, not to relitigate their stack. Frontgo's codebase and roadmap were owned by their own PM; AudioBin and SkyTracks were architected next to their technical CTO, on his calls. Running a company does not mean I have only ever taken my own direction — client-services work is taking someone else's direction for a living. What I would push back on, the way I always have, is a decision that is technically unsound; what I would not do is relitigate a settled call because I would have made it differently.