Engineering-led, value-led

Six weeks to production

A large telecoms infrastructure client was losing money on field-service visits that didn't need to happen. We ran the whole method end to end: intake, assessment, a production build, analysis, a plan to scale.

The build is a multimodal experience: customers capture photos and video of the install route, and an agent infers from the images whether an engineer really needs to visit. Because the reference set is known, the context scales without token use getting out of proportion. We tested several models on cost, latency, accuracy and other evals, and Claude Haiku 5.5 came out best on all of them.

Result: live in production in six weeks, and the client's senior stakeholders put the scaled business case in the tens of millions of pounds of realised value.

Building two FDE teams from nothing

These are the first FDE teams I've built from scratch, though not my first team: at Quantive I grew Presales across EMEA and the rest of the world from one to six. The principles carry over. There I hired sales engineers as the product experts, solution architects to make the solution stick in a real architecture, and value consultants to make it relevant to the market.

In FDE there are two roles. Strategists have done it before: they understand the theory deeply and manage all the moving parts. I find them in customer success on the vendor side, programme management on the client side, management consulting and transformation. Engineers really understand the implementation, test, learn and optimise at pace, and know what production needs secured. Usually they're developers who have delivered on the front line with customers, and sometimes the more technical sales engineers I've worked with.

Who I hire: people who are deeply curious, don't accept the status quo, are confident with every kind of person, and can deliver to production on a compressed timeline. FDE is not for the faint-hearted, but it's hugely rewarding to see ideas come to life and deliver real outcomes early.

So far: my team is six people (seven with me), hired in three months. We're part of a global FDE organisation that has hired 25 so far and is growing to about 50, and my team makes up 10 to 15% of that footprint.

The demo that couldn't go to production

However big the team gets, I believe everyone, leaders included, stays in the field. AI moves so fast that a step back puts you behind.

Speech-to-speech is a good example. The ambition was one native speech-to-speech model; practice is moving to delegation, a live model for the conversation and a back-end model for the reasoning and tool calls. On one deal, an earlier single-model design had shown high tool-calling accuracy and low latency. We couldn't reproduce it, so I dug into why. It was a prompt-driven demo, with no tools and no real architecture behind it, so it was never going to behave the same way in production. The lesson: judge every design against production constraints, not demo conditions.

Result: we followed the delegation guidance. In our evals, delegation called tools correctly more than 95% of the time, against 45% for the single speech-to-speech model, and latency stayed within 50 to 150 ms of each other. Marginally more expensive, but real, repeatable, testable and scalable. The debugging, evals and iterative design won us the deal.

From a plugin fix to a new template

Every project builds on the team's shared toolset: skills, extensions, playbooks and templates. The first release of our build plugin scaffolded agent projects over MCP, through an agent with tools for most build actions. To keep it safe and simple for everyone, some parts of the web app and its REST API were left out, and that blocked multimodal experiences where the agent takes interactive input from users.

The fix: add the missing endpoints as a REST action alongside the MCP tools. It unlocked rapid iteration, and that became a new template for Agent-to-UI (A2UI): real-time, interactive experiences for the people using the agent. Four projects use it so far.

The habit: when something works on one engagement, it goes into the shared toolset as a template or starter repo with an owner, so the next team starts from it rather than from scratch.

From the field into the product

Voice agents are a big part of my work. What we learned across several voice implementations went straight back to the product team, and it's driving a significant convergence in how speech-to-text, text-to-speech and the LLM work together for low-latency voice agents. I can't go into detail yet, but customers will feel it soon.

That link matters. FDE sits where sales, product and engineering, and customer success meet, and the line from the field into product is what keeps a company moving at the pace of AI. It's why our FDE teams sit in their own Labs organisation, reporting up to the Chief AI Officer.

When the result isn't the one you hoped for

Not every engagement lands the outcome, the value or the experience everyone expected. I've had tough but necessary conversations with C-level stakeholders: about their position on AI, why the result was the result (an FDE project produces plenty of data to review), and where we go next.

What makes them work is a charter agreed up front: what we'll do, what we hope to achieve, what each side puts in (often time, people and effort, not just money), by when, and what happens next if it succeeds or fails. Failing fast is sometimes the journey the group needs: far better now than when thousands or millions of users are relying on it. The charter keeps the conversation objective and pointed at an outcome both sides still want.