The New McKinsey: A Conversation with Jove Zhong
Head of FDE at Cresta
Jove Zhong leads Forward Deployed Engineering at Cresta, where his team builds AI agents for contact centres handling real calls, real bookings, and real money. Before Cresta, he co-founded a database infrastructure company and spent over two decades at IBM and Splunk as an engineer and engineering director. We sat down to talk about what FDEs actually do, why the role exists, and what it takes to hire for it.
You can also watch the full conversation on YouTube.
You’ve been in tech for over 20 years across engineering, management, and founding companies. What made you want to become an FDE?
I’ve always enjoyed making things happen. Managing people and growing teams is something I’m good at, but I really enjoy getting my hands dirty. In my previous roles, I was a full-stack engineer writing a lot of code. When I joined Cresta, I came in as a Forward Deployed Engineer first. I wanted to know how to do the work before I took on leading the team.
Now I’m about half IC, half leadership. I still spend time observing how my engineers work, looking for places we can improve our process and tooling. But I’m not just an FDE manager sitting in meetings all day.
At Cresta, the FDE team sits inside engineering, not go-to-market. Why does that matter?
FDE stands for engineer, right? We write a lot of code. I don’t really write many slides. Most of our time, my whole team, we’re writing code, writing prompts, refining test frameworks, wiring things together. We’re talking about very technical parts of the end-to-end AI solution we deliver to customers. We are part of the product.
The other piece is our goal isn’t just to deliver for a single customer. We need to bring lessons learned from the field back to the product team. Should we add a thinking model? Should we refine our test automation? Should we build continuous learning into our prompts? All of that is product work.
Without FDE, it’s very difficult for a customer to build their own AI agent that calls their APIs, implements their business logic, makes their customers happy. But it’s also difficult for our product engineers to do this because they’re focused on reusable components and common features. FDE is the person in the middle wiring things together.
If we sat in go-to-market, we’d be optimising for closing deals. Sitting in engineering means we optimise for building something that works and making the platform better.
You work with airlines, healthcare, fintech. How do you extract the business rules from a customer when half of them aren’t even written down?
Different companies have different levels of maturity. Some have detailed SOPs. Some have a single guideline somewhere. Some have multi-page instructions full of screenshots that aren’t friendly for AI to parse. Sometimes it’s completely outdated.
Here’s the thing: SOPs are almost nice-to-have for humans because people know how to adapt to situations. But for AI agents, they’re almost must-have. Otherwise, you’re letting the LLM guess what to do, and you’ll get surprises. Sometimes pleasant, sometimes terrible.
So we spend a lot of time with the customer to refine their SOP and make it work for AI agents. Sometimes they add a new API. Sometimes they fix bugs. Sometimes we add guardrails or helper messages to make things more deterministic.
Here’s my hot take: we’re almost the new McKinsey.
That’s a bold claim. Explain.
In the past, companies paid a lot of money to bring in consultants. They’d read your meeting minutes, check your slide decks, refine your mission statement, and give you a bunch of suggestions on paper. But it’s just slides. It’s just a document.
We’re different because we build a working solution. And that solution has to handle real customer calls, do real upsells, solve real issues. We have a feedback loop because everything is data-driven. Whether the customer is happy, whether we can handle more cases, whether we can reduce call time. All of that is measurable.
By building the AI solution, we’re also refining the SOP. A broken or incomplete SOP will never make an AI agent work. So we’re giving customers suggestions by building something better for them, not just handing them a nice slide deck. In the past, people called this digital transformation. Now we’re helping customers become AI-native.
You mentioned that getting from 80% to close to 100% is where FDE earns its keep. What does that last 20% actually look like?
Everyone knows LLMs hallucinate. Even the best models from OpenAI, Anthropic, Google. It’s always there. No matter how good your prompt is, no matter how many tools you register.
Say you register 40 different tools and tell the LLM very clearly: call this tool when you need to verify a zip code, do XYZ. It’s not always going to work. Maybe it calls the right tool 9 out of 10 times. What about that last one?
For a demo, you might get lucky. But in reality, if you’re making mistakes at 10%, 5%, even 1%, it can be miserable. People share news about someone getting a car for $1 because a chatbot made a mistake. That’s the kind of thing that ends up on the front page.
So that last 20% is building all the systems around the agent. Guardrails. Other LLMs as judges. PII checking. If the main agent is about to say something wrong, another agent cuts it off or corrects it. Getting that last mile done in a systematic way, where you might make a mistake once but never twice, that takes real effort.
How do you make an agent actually learn from its mistakes? Everyone asks if AI is smart enough to never repeat the same error.
Fundamentally, almost every LLM conversation is stateless. You don’t change the model. You just accumulate conversation history and send it to the next call.
If you handle thousands of calls every day and every conversation is unique, there’s no automatic learning. You have to design for it. You do retros. You understand what happened in each conversation. Did the agent give the right response? What did the human reviewers rank it?
You discover edge cases and feed them back in. Daily, nightly, weekly, with humans in the loop. The system has to accumulate lessons and make the next conversations better.
None of this comes for free. The model itself is stateless. It will make the same mistake again and again if you don’t build the infrastructure to prevent it.
Building these systems requires a specific kind of engineer. Jove has reviewed thousands of applications trying to find them.
You’ve reviewed thousands of applications for FDE roles. What are you actually looking for?
I don’t hide my criteria. I don’t want to make hiring harder. I want to meet more promising candidates.
I spend maybe five or ten seconds on each resume. I can’t research every single one. So I look for basics: Are they in North America? Did they come from a strong university? What technical stack do they use?
If people are talking about buzzwords like ISO certifications and change management, I get worried. I want to see technical terms. Python-based LLM frameworks, observability tools, test evals. We don’t want to hire someone who’s good at Python and then spend six months training them on AI.
I also don’t hire anyone with less than one year of full-time experience. FDE isn’t just technical work. You need to understand customer-facing work. You need to know how to say no, how to challenge people, how to push clients. You can’t just be a follower waiting for a senior person to troubleshoot for you.
What kind of background actually sets someone up for success?
People with founding engineer backgrounds or who’ve been founders themselves. A few things stand out about them.
First, they’ve worked hard in challenging environments before. They know nothing is easy. They’re open to tight schedules and solving problems under pressure.
Second, they have the mindset of “I will make this happen whatever it takes.” They don’t wait for PR approval. They don’t wait for someone to give them a task. They drive things. They fix things. It’s okay to break things as long as you fix them fast.
I’m also open to hiring senior people with leadership experience. But our current priority is building AI agents efficiently with best practices. So I really value people who are hands-on.
Even with the right people, FDEs face constant skepticism about what the role actually is.
What’s something FDEs do that people don’t really understand from the outside?
I’m past the age where I want to convince people who don’t get it. If someone thinks this is just a glorified consultant, good luck.
But if you’re working on AI-related enterprise solutions, the FDE model works. Maybe it’s not the only way, but it works. There are real challenges with current AI: the models, the toolchains, the theory. It’s very easy for clients to get lost. It’s also easy for platform engineers or regular software engineers to get lost. They don’t understand what the customer really wants. Their API, their bugs, their vibe.
FDE fills that gap. We bring knowledge and patterns from the AI world together with the customer’s actual API and business logic to make something that works.
There’s a lot of talk about whether FDE is just “delivery engineer” with a nicer title. What do you say to that?
Short answer: FDE for AI agents is absolutely a delivery role. It delivers. I’m not offended by “AI delivery engineer.”
But there are important differences from classic delivery setups. First, the AI context. Without AI agents, FDE is just a fancy title. With AI agents, the job is glued to prompts, tools, safety policies, observability, and rapid iteration based on real conversations.
Second, the product feedback loop. We’re not billing hours, walking away, and leaving a forked codebase behind. Our agents run on a shared platform. The pain we experience on one project becomes a feature request or a better default for the next project.
Third, the lifecycle. A typical project has an intense front-loaded period where the FDE is almost embedded with the customer, then a long tail of lighter involvement. We’re not living on-site for years.
Call it whatever you want. I just care that we deliver working agents that customers renew and expand.
Last question: What’s your take on the future of FDE?
It’s no longer a world where you build something and sell it to many customers out of the box. You have to make sure the AI solution works for the customer’s API, their business logic, their vibe.
In the end, you can still charge a lot. The deal sizes justify the cost of an FDE team. But pure PLG doesn’t work for complex AI. Someone has to do the hard part of turning “we want AI” into something that actually answers calls and changes bookings today.
Right now, that someone is called FDE.
Jove Zhong is Head of Forward Deployed Engineering at Cresta. He’s hiring FDEs in the US and Canada.