What FDEs Actually Do All Week
Ten clients, fifty hours, and a lot of context-switching.
Hey, Prasad here 👋 I’m the voice behind the weekly newsletter “Big Tech Careers.”
This week’s post comes from a special guest Milos Mandic, Forward Deployed Engineer at Lleverage and author of the FDE Hub newsletter, where he shares insights from his experience as an FDE and interviews others in the role.
If you’re curious about what it means to be a Forward Deployed Engineer, I highly recommend following him on LinkedIn and subscribing to his newsletter.
If you like the article, click the ❤️ icon. That helps me know you enjoy reading my content.
Over to you, Milos!
Ashish Prajapati is running a one-day live bootcamp for the NVIDIA Associate — AI Infrastructure and Operations (NCA-AIIO) certification on May 16th. Ashish is 5x NVIDIA certified and his self-paced NVIDIA courses on Udemy are top rated.
He's offering 50% off for Big Tech Careers readers this week.
Since I started writing FDE Hub newsletter, I’ve had dozens of people reach out saying they love what I’m sharing about the FDE role. The most common request? Tell us more about the day-to-day. The actual experience. What does a week actually look like?
Fair enough. Here’s a recent one. Ten clients, fifty hours, and enough context-switching to make your head spin.
A quick note: at larger companies like Palantir or OpenAI, FDEs typically go deep on one or two clients at a time. At a startup like Lleverage, I’m running parallel deployments across many clients simultaneously. It’s a different version of the role, less depth, more pattern recognition across contexts. Both are valid. This is the startup FDE experience.
Monday: Planning the Chaos
The week starts with a planning session. Me, the other FDEs, and our head of customer delivery sit down for an hour to review every active client and set priorities for the week.
This sounds corporate. It isn’t. It’s survival.
When you’re working with ten clients in parallel, you need to know which fires are smouldering before they become infernos. Which PoC is about to hit a deadline. Which client has been quiet for too long, which usually means they’re stuck and haven’t told us yet. Which prospect needs a scoping call before they lose momentum.
We use Linear to track everything. Each client has their own project, their own set of tasks, their own status. Without this, I’d be lost within a day.
After planning, the rest of Monday is a blur of calls. Status updates with existing clients. A pre-sales call with a prospect trying to figure out if what they want is even possible. By the time I look up, it’s 6pm and I haven’t written a single line of code.
This is more common than I’d like.
The Two Active Builds
I usually have two clients in active build mode at any given time, with the rest in earlier or later stages.
The first might be something like a document processing pipeline. On paper it sounds simple. Documents come in, structured data comes out. In practice, a single client will have half a dozen document types arriving from a dozen different sources, each one needing to be classified, routed, validated against business rules, and then pushed into a downstream system that has its own opinions about what valid data looks like.
You get to 80% quickly and it feels like the end is in sight. It isn’t. The core workflow runs. I can take a clean example, extract what’s needed, hand it off in the required format, and the demo lands well. Everything after that is the part nobody sees.
Documents arrive in formats that don’t quite match the spec. Fields that are mandatory in theory turn out to be optional in practice, and the agent has to know the difference. Two operators at the same client disagree about what the right answer should be on the same document, which means there isn’t really a ground truth, there’s a negotiation. Handwritten annotations confuse the OCR. A customer sends scanned PDFs at a resolution that makes the whole thing unreliable. The downstream system rejects an upload because of a field constraint nobody mentioned in the scoping call.
A lot of my building time goes into chasing these. Tightening prompts, adding context the model needs to disambiguate one document type from another, expanding the test set to catch failures we hadn’t seen yet, adding fallbacks for the cases where the agent should escalate to a human instead of guessing. None of it is glamorous. It’s the difference between a demo that impresses people and a system that runs in production without someone babysitting it.
The second build is usually earlier stage. We’ve proved the concept on a handful of input-output pairs and now we need to scale to a hundred or more, which is where the architecture that worked for the prototype starts to creak. A PoC is a magic trick. Production is plumbing. Moving between them often means rethinking decisions you made when you were just trying to prove the thing was possible at all.
This is also where coding agents have changed the shape of my week. I run Claude Code in the background on a lot of the grunt work, scaffolding test cases, refactoring messy prototype code, drafting integration glue against an API I’m still figuring out. It hasn’t reduced the thinking. If anything, it’s made clearer how much of the job was thinking in the first place. What it has done is compress the typing, which means the constraint moves further upstream. The bottleneck is no longer how fast I can build. It’s how quickly I can extract enough operational context from the client to know what to build next.
The Communication Sprawl
I’m logged into dozens of Slack workspaces and Microsoft Teams instances. Every client uses their own tools and we meet them where they are, so I have Slack for some, Teams for others, each with their own channels, their own notification sounds, their own conventions for what counts as urgent. Most clients also have my phone number, which means a real escalation can land as a WhatsApp message at 9pm on a Sunday. That hasn’t happened often, but it’s happened enough that I keep my phone within reach.
On top of that there are our internal tools. Linear for project tracking, Notion for documentation, Google Docs for shared specs and proposals, Excel for data analysis and quite often as a source of data, Postman for poking at APIs, and Claude and Claude Code threaded through most of it for writing, debugging, and thinking out loud.
Context-switching isn’t really about moving between projects. It’s about remembering which client uses which tool, which channel is for urgent issues versus general updates, and where I left a conversation three days ago when I was last in their world.
When Things Break
Every few weeks, something upstream goes down. A model provider has an incident, a cloud region wobbles, an auth service hiccups. When that happens, our clients have problems, and when our clients have problems, they message us.
Half a day disappears into firefighting. Checking status pages, sending updates to clients who are panicking, trying to figure out if there’s anything we can do to route around the outage. Often there isn’t, but you still have to check. You can have the perfect week mapped out and then an upstream provider takes you straight into reactive mode. The deep work you had blocked out waits another day.
We have monitoring in place to catch these issues early, which helps. It doesn’t eliminate the disruption.
The 50/50 Split
If I’m honest about time allocation, it’s roughly 50% meetings and 50% building. The meetings are client check-ins, internal planning, pre-sales calls, scoping sessions, status updates, and the occasional firefighting call. The building is actual coding, prompt engineering, testing, debugging, and feeding insights back to our product team about what primitives we need.
I try to protect Tuesdays and Thursdays for deep work. Four-hour blocks where I can actually make progress on complex problems. It doesn’t always hold. A client escalation or an urgent prospect call can blow up any day. But when I do get those blocks, that’s when the real work happens.
The short gaps between meetings, the 30 to 60 minutes here and there, are for small fixes and maintenance. You can’t architect a system in 45 minutes, but you can tweak a prompt, kick off an agent on a small refactor, respond to a client question, or review test results from an overnight run.
The People Part
Most of my conversations are with business stakeholders, not technical people. This surprised me at first. I expected to spend more time with engineers, but in practice I talk to technical people mainly when I need access to systems or help with integrations. The day-to-day work is with operations managers, department heads, and executives who are trying to figure out what AI can actually do for their business.
A lot of that work is translation. Explaining what’s possible, managing expectations about what AI agents can and can’t do, redirecting requests from “we want an AI that figures everything out automatically” to “let’s start with these specific inputs and outputs.” We found ourselves repeating the same explanations so often that we built a playbook. It’s a document we share with every client that covers what data we need from them, how we communicate, how they should test and give feedback, and how to capture the SOPs and business rules that the agent needs to do its job.
That last part is the one that matters most. Agents need the rules of your business written down somewhere before they can automate anything against them, and most clients have never written those rules down. The playbook sets that expectation before we write a single line of code.
Friday: Internal Focus
By Friday, the client calls slow down and the internal work ramps up. This is when we do team syncs, retrospectives, and product feedback sessions. The things that matter for the long term but get squeezed out when client work is intense.
The product feedback loop is one of the parts of this job I find most valuable. When you’re implementing the same patterns across multiple clients, you start to see what should be abstracted into the platform. I spend time with our product team talking through which primitives we keep building from scratch, because that usually means they should exist as features we configure instead of code we write every time. The interesting half of that conversation is the inverse: which patterns look repeatable but actually shouldn’t be productised, because the edge cases between clients are larger than the shared core. Knowing the difference is the part of the job you can only learn by sitting across many implementations at once.
What This Role Actually Requires
Looking at a typical week, a few things stand out.
First, you have to be comfortable with chaos. Ten clients, different tools, different stages, different problems, constant context-switching. If you need long stretches of uninterrupted focus to be productive, this role will break you.
Second, the technical work is real but fragmented. You’re not spending eight hours a day writing code. You’re spending two hours here, four hours there, and the rest in conversations that shape what that code needs to do. Coding agents have shifted that ratio a bit, but they haven’t changed it fundamentally.
Third, the business side is unavoidable. If you just want to build things and not talk to people, this isn’t the role. Most of my week is communication. Translating requirements, managing expectations, navigating stakeholder dynamics.
Fourth, you carry full context. One FDE per client. There’s no handoff to a delivery team. What you scope is what you build. This is exhausting but also clarifying. You can’t overpromise because you’re the one who has to deliver.
The Honest Version
If I had to name the thing that defines this role, it’s this: the work is less about building AI systems and more about understanding businesses well enough to know what to build.
The technical skills matter. You need to be able to code, to understand how LLMs work, to debug systems under pressure. But the differentiator is pattern recognition across messy human organisations. Seeing what’s actually blocking a client, which is rarely what they say is blocking them. Knowing when to push back and when to just build what they asked for.
Every week is different. Every client is different. The only constant is that my carefully planned Tuesday deep work block will probably get interrupted by something.
That’s the job.
I would like to extend a big thank you to Milos Mandic for sharing his insights with Big Tech Careers readers.
I encourage you to subscribe to his newsletter, FDE Hub, to learn more about the FDE role.
AI-Powered Big Tech Interview Prep for Tech ICs and Leaders
While everything I share in this newsletter is free, if you'd prefer the material in a structured course format — with a deep dive into behavioural interview preparation — I'm running a 1-day Big Tech Interview Workshop. Newsletter readers get an exclusive 30% discount.
 | A guest post by
|