Issue #2: Lessons from Running the Forward Deployed Engineering Function at a High-Growth Startup - Justin Sharps

Few functions are as talked-about, or as loosely defined, as forward-deployed engineering. Justin Sharps, Head of Forward Deployed Engineering at Encord, the data-development platform behind demanding AI systems in autonomous vehicles, drones and multimodal models, has grown the function in eight months from a capability the company kept borrowing into a dedicated team of engineers, deployment strategists and support. We sat down to discuss how he runs it.

The conversation below is lightly edited for length and clarity.

Let's start with the basics. Do you have a formal definition of the FDE inside Encord?

Yes, but it's subtle. Roughly, it's engineer for customer outcomes. And people say, well, doesn't everyone engineer for customer outcomes? Sure, every team does. The difference is that we're able to slam the accelerator on a customer outcome without having to worry about core product scalability. A product-and-engineering team weighs a lot of factors on every decision: how does this affect the interface everyone's using, how does this affect technical debt, how does this affect conceptual clarity. For the FDE team, once we’ve decided a particular initiative has the right strategic or tactical importance, gets the remit to drive towards outcomes while heavily discounting a lot of the traditional cost components of the equation.

That sounds like a deliberate carve-out. You became Head of FDE eight or nine months ago: did the function exist before that, or did you create it?

Yes and no. Every so often you'd find a case that needed real exploration, and we didn't have the formalized muscle for it, so we'd make ad-hoc capacity decisions and borrow people to cover it. As the company matured and our customers matured, larger enterprises, higher stakes, etc, rather than continuing to borrow capacity it became more worth it to make dedicated capacity available to ensure success. At that point, it’s time to put a name on it and grow it explicitly.

How big is it now that it has a name?

We’re growing quickly, so hard to put a number on it. This is counting everything that makes the function actually work, the engineering team yes, but also dedicated deployment strategists and support team which can organize into pods to make the most strategic initiatives successful.

You mentioned deployment strategists. How do you define that role at Encord: are they very technical, or less technical?

Somebody who's comfortable running a technical conversation, but who doesn't have to ship or write code themselves. They translate between high-level business requirements and what a viable workflow actually looks like, and critically, across multiple working contexts. It's rarely "someone uploads data and clicks a few buttons." It's more like: data comes in here, goes through a process, gets sent for external review because of a compliance requirement, and an updated version appears on the platform later. So you pull back and work with different stakeholders on what matters at the high level, then talk to the people doing the daily work and say, "I see, your tool sends to here and there, let me put together this data-flow diagram and find the bottlenecks." Then the engineering team comes in and makes those bottlenecks go away. The strategist needs that instinct, but they don't need to turn around and implement a tree graph or a database index.

How do you decide which customers get a forward-deployed team?

Everything has to be qualified. A lot of customers sign onto the platform, and as the platform's surface grows it handles more cases with no specialized engagement needed. But when there are notable gaps, I'll chat with the heads of engineering and product on the core side, depending on where it falls. Is this a large lift? On the roadmap, or an opportunity to validate something new? Then we'll break off a pod to go figure out what's there and build it. And it doesn't have to be sustainable. They can write their own tables, create their own indices, run their own code path, because the team owns its own technical debt. If it works — the customer is satisfied and it’s driving adoption and value, that’s the best form of product validation there is. You're not showing a mock. You're looking at how much data went through the workflow. "Great, we've captured 30% of all their data workflows." Clearly there's something real here. There are categories of engagement, but I don't have a unique form for them. It's not "select your engagement type from a dropdown."

You mentioned categories of engagement. Are there any typical ones? Can you give us a few examples?

On-premise deployments are a big one. The moment it's on-prem, we have to make sure the application infrastructure and layout are right-sized to the customer's environment, which means a full-stack engineer is involved from day one, plus a deployment strategist meeting the three-to-ten people who all need their voice heard. And you hit things like, "great, we'll hook up to your on-prem database," an old version of IBM DB2, say. That's not a standard AWS plug-in-and-go. The other big category is custom data protocols. We specialize in physical and multimodal AI, so a lot of it comes with standard formats: point clouds, ROS bags for physical AI; video, JPEGs for computer vision. But sometimes a customer has so much data sitting in their internal storage systems that we have to build a custom integration to ingest it into the platform.

A custom integration like that could run long. Do you put a time frame on these engagements?

Yes and no. Is there a time frame? Yes. Is it the same for each one? No. What you do is talk to the counterparties until you can t-shirt-size the thing, in line with that outcome-based discussion. We don't say "we'll do X hours of engineering," because hours are never accurate, and what you're really delivering is a capability that wasn't there before. So we put a t-shirt size on it and describe the qualitative change the business needs to see: your data reviewers will access data at this throughput and make these changes because of the functionality we build. Then you back out from that in a scoping session. For this to be true, we need the integration, the custom piece validated, an authentication bridge. Then you land a rough timeline, on the order of months or quarters. And you wade in. Sometimes unknowns come up, and people are by and large reasonable. If something comes up that didn’t surface in scoping, you go back to the table and ask, “okay, how does this change things?”

Going back to the table is where a lot of teams lose money. Scoping custom work can be difficult: do you have any best practices here? How do you handle scope creep?

Nobody appreciates nickel-and-diming. It's about finding a counterparty who understands the difference between a bit of scope creep and an actual perspective shift. My rule of thumb: we'll t-shirt-size this, and roughly 20% slip is goodwill. If we thought six-to-eight weeks and it ends up ten, nobody's losing their shirt. Things come up. But if you're at week six of a six-week engagement and you're 50% in, it's time for a review: categorically, was something there that shouldn't have been? And honestly, I've been surprised how collaborative that turns out. People say, "I didn't realize this was happening in my own data set. You did more than I expected." It wasn't the thing they set out to learn, but it wouldn't have surfaced unless they'd brought someone like us in. Managing that with people, more often than not, turns things really collaborative.

Is the customer's own technical capability part of how you qualify a deal? If they can't fully follow what you built, even genuinely strong work can end up looking like you underdelivered.

Good question. Let me take it in two parts. With a technically educated counterparty, conversations go smoothly. You say, "we're looking at a three-month engagement, and if you want the dedicated time of an engineer or two, this isn't trivial," and they get it. "Makes sense, let me take it to the budget committee." In other cases it's not that people won't get the wallet out; it's that they ask, "why can't you just do X?" And it's like, well, if you could just do X, everyone would. That shows up more in enterprise cases, where the education journey is just longer. You have to get people to be realistic about what a successful engagement looks like. It's not "here's the thing I want, ship it in a year." You want your first deliverable in twelve months? That's an incredibly risky proposition. I'd aim for something that sounds off-piste but that we can deliver in three months and that proves the directionality is right. Then you convince people why those smaller proof points are necessary. That's a more common symptom than qualification, honestly. You qualify, then you change the motion based on the level of sophistication.

All of that rests on the people you put in front of the customer. How do you hire for these roles: engineers, deployment strategists, support?

With a lot of effort. On the FDE side: they have to be an engineer. I interview a lot of people who are "FDE at such-and-such," and over the course of even the screening call it becomes clear they're actually a solutions architect, or a solutions engineer, or support. If the job asks them to design a table structure to serve queries at speed, or a data flow moving items out of two databases across a queue into a third and they struggle — then the answer is a flat no, that won’t work here. We’re doing data engineering at scale across multiple modalities; you have to understand how audio works with video, the layout of a video file, how to work with these at scale. So the exam is hard engineering: system design and data structures and algorithms, but always contextualized in a realistic situation. Being able to reverse a binary tree from memory is less important than being able to recognize patterns and bottlenecks in production code and reason between the different layers of the tech stack. On the deployment-strategist side, the good signals are someone who's been customer-facing before, plus high agency: a founder's associate, an early-stage-startup background, someone who can work across a problem. There's no checklist. It's: here's an account with a problem, go talk to the first person, then whoever they send you to, sense-make, and put the plan together. High agency, diligence, attention to detail, technical intuition.

High agency is top of that list. How do you actually measure it: references, tests?

References are always a good idea, but its presence has some tells as well. If there's a personal story that involves agency, it's obvious: "this wasn't going as well as we expected." "So you folded up shop?" “No, we got on a plane”, or “we slept overnight in the office to make it on time.” These are strong indicators, and easy to verify. Its absence is trickier, since particularly humble people will miss the chance to show it if you don't prompt right. Which is why part of the interview is building trust, getting on the same wavelength, because in a high-agency environment you have to know they'll do the thing you need them to do. And here's the thing: asking "tell me about a time you showed high agency" has never once led to a good interview for me. It's always "what was the most important thing to you when you were doing X," and you follow that through, and suddenly this person really cared about something, and you dig it out. You have to share a bit of yourself too. That's how you find what makes people tick.

Has that list changed in the last six months, because coding agents are so good now?

Not too much, honestly. Maybe the one place it's changed is how much full-stacking is required from day zero. It used to be very preferable that someone was 70/30, back-to-front or front-to-back. Now, as long as the engineering fundamentals are there, you could be 90/10 and Codex handles the rest. But if someone's missing the foundational pieces, what's actually happening when I sort a list, that you had to create these temporaries or make a copy, they won't spot when the AI does something silly. And seemingly the AI does fewer silly things now, which is exactly the trap: if you don't know what good looks like, you can't stand in front of one of our most important customers, cross your heart, and promise them it's great. That test still has to be done by a person.

Which brings us to AI slop. What do you think about it, and do you have to fight against it?

Mainly in the interview. We've explored how to make an AI-resilient process, and it hasn't always been a resounding success, mostly because the models were leapfrogging so fast. We had a good challenge for some of the older versions; it relied on the candidate concisely distilling what needed to be done and what didn't, so the thing actually worked. "How few prompts can you solve this in" gave you real signal on seniority. Then a recent model comes along, and you just paste in the customer's problem statement and the best solution basically falls out the end with zero thought. So the slop problem is real, and it made something clear: it's not too much to ask that someone demonstrate their own authentic understanding at the data-structure and hardware level, because that intuition is what tells you when to reach for the AI and when not to. I'm not comfortable having 17,000 lines of AI-generated code inside our most significant integration without someone willing to say, "this is the structure, these are the modules, here's where it'll scale and here's where it'll break." If the only thing that's vetted it is the AI, and the AI hasn't even been fed the customer's codebase or architecture, you're taking way too much for granted.

Do you actually travel to clients? How embedded are you?

Great question, and it speaks to the forward-deployed motion directly. I'd say we're more forward-deployed than some, less than others. It's not the four-day-consulting model where you're in the seat next to someone for three months. It's frequent calls, and almost always an in-person component: several days to establish relationships and see what things are actually like on the ground. But once you've seen what's happening, you don't need to stay for months. “Great, I’ve met you in person, I’ve literally seen the day-to-day, and likely gave it a shot myself.” Now I've got the intuition. And if you need to go back in a couple of months for the next phase, that's always on the table.

Have you productised anything that came out of the FDE engagements?

Because we're not on-site for three or six months at a stretch, the FDE and product teams are already pretty integrated. We show up at the same briefings, we're in the same channels. When something needs doing in an engagement, it goes through that matrix: is it on the roadmap, should it be accelerated, is it not on the roadmap at all? Someone does it, and we report back: "we shipped this last month, here's what was easy to build on and here's what was a real faff." The product team takes that advice. Sometimes we'll do a visitor pattern where the FDE takes a little time before their next engagement to polish something off. But it's not "on assignment, then back to core."

The other thing that comes with that intensity is burnout. How do you fight against it in your FDE function?

You have to stay tight with the team and make sure people manage their own workload. It's a high-agency part of the org. I'm not handing out edicts, I'm talking about outcomes and timelines and "let me know where you need support." We check in regularly on where the bottlenecks are and where people need capacity. It's easy to work yourself into burnout, because you find people who are genuinely passionate, and you shouldn't be surprised that they work hard at it. So helping people regulate their own workload is a regular part of the job.

Last one. One piece of advice for others setting up a forward-deployed motion?

Be specific about the gap the forward-deployed motion is filling, and decide how you're going to concisely articulate it. For us: FDE at Encord crosses technical gaps to solve for customer outcomes on customer timelines. They own technical debt and discount typical eng/prod concerns. There's a mandate to engineer for customer outcomes, and to discount the other things that weigh on the scales for the core team. That means they have to be engineers, they have to enjoy working hard, and they have to deliver in a real product context to a customer. When you stand this motion up, people will ask, "wait, what's the purpose: is it support, is it solutions, is it engineering without a roadmap?" Unless you yourself are laser-focused on the gap being filled, you'll never answer that cleanly. Articulate it.

And if you wanted to read more interviews like this with FDE practitioners subscribe to this newsletter!