The first 90 days as a Forward Deployed Engineer rarely match the mental image most new hires bring in. There's no dramatic customer crisis to solve on day one, no immediate hero moment. 

What actually happens is slower onboarding than expected, followed by a first assignment that feels smaller than you hoped, followed by a genuine wall around week six, followed, if you handle the wall well, by the first real signal that you're becoming trusted. 

This guide walks through that arc honestly, week by week, rather than describing an idealized version of the job.

Forward Deployed Engineer First 90 Days

Weeks 1-2: Onboarding Feels Slower Than You Expect

Most new FDEs expect to be embedded with a customer almost immediately. In practice, the first two weeks are usually internal: understanding the company's existing deployment patterns, getting access to the tools and systems you'll actually use, and often shadowing a more senior FDE on an active engagement rather than owning anything yourself. 

This feels anticlimactic after an interview process that emphasized ambiguity and customer ownership, and it's a common source of early frustration for engineers who expected to be thrown in immediately.

This slower start is deliberate at companies that do onboarding well. Understanding internal tooling, evaluation frameworks, and how the company's specific version of "discovery" actually works prevents a much more expensive mistake later: showing up to a customer engagement confident in skills that don't yet map to how this specific company actually operates.

Concretely, these two weeks typically involve reading through documentation on past customer engagements, getting credentials and access provisioned across a surprising number of internal systems, meeting the internal teams (product, sales, customer success) whose work intersects with FDE deployments, and sitting silently in at least one live customer call, taking notes rather than speaking. 

If the company runs a structured onboarding program, this is also when foundational training modules get completed, though the real learning happens more in the shadowing than in any formal curriculum.

Weeks 3-4: Your First Real Assignment

Your first assignment is rarely the highest-stakes engagement on the team's roster. Managers deliberately assign new FDEs to lower-risk, well-scoped work first, a smaller customer, a narrower technical scope, or a piece of a larger engagement rather than the whole thing. 

This isn't a signal of low trust, it's a genuinely sensible way to let a new engineer make mistakes on manageable stakes rather than a marquee account.

This is also when the gap between what you studied and what the job actually demands becomes concrete. Discovery conversations move faster and messier than any mock interview prepared you for. 

Customer stakeholders ask questions that don't map cleanly to the categories you practiced. This is normal, and it's exactly the adjustment period every FDE goes through regardless of how strong their preparation was beforehand.

A typical first assignment might look like: owning one specific integration within a larger deployment a senior FDE is running, or taking full ownership of a smaller customer whose stakes are real but contained. 

Either way, expect close-but-not-suffocating oversight, a manager or senior FDE checking in regularly, not because they distrust your technical ability, but because this is genuinely the first time you're applying it inside this specific company's customer context, tools, and expectations.

Weeks 5-8: The First Wall Most New FDEs Hit

Somewhere around week five or six, most new FDEs hit a specific kind of wall: a request from the customer that doesn't fit neatly into the scope you agreed on, or a technical problem that doesn't resolve the way your first assignment's problems did. This is often the first real test of judgment rather than technical skill. 

Do you quietly over-extend the scope to keep the customer happy, do you push back too hard and damage the relationship, or do you find the middle path of reshaping scope without ever making the customer feel refused.

This period is also when the earlier, slower onboarding pays off or doesn't. Engineers who used weeks 1-2 to genuinely absorb the company's evaluation and discovery patterns tend to navigate this wall faster than engineers who rushed through onboarding hoping to get to "real work" sooner. 

The wall doesn't feel like a technical problem at the moment, it feels like uncertainty about whether you're handling the relationship correctly, and that uncertainty is normal, not a sign you're failing.

A concrete version of this wall: a customer stakeholder asks, mid-engagement, whether the system can also handle a second use case that was never discussed during scoping. A new FDE without a senior mentor nearby has to decide, in the moment, whether saying yes without checking in first is being helpful or being reckless with the actual timeline. 

There's no universally correct answer, and part of what this period teaches is that the right response is usually to buy a small amount of time ("let me confirm this fits our timeline and get back to you tomorrow") rather than answering definitively on the spot either way.

Weeks 9-12: Your First Real Win

By the ninth or tenth week, most new FDEs who've navigated the earlier stages reasonably well get their first genuine, visible win, a deployment that ships, a customer relationship that clearly trusts them, or a technical problem solved independently that would have required senior help two months earlier. 

This win matters less for its specific content and more for what it signals internally: that you can be handed a real engagement without close supervision.

This is also typically when a new FDE starts contributing something back, a pattern noticed across the specific customer's systems, a suggestion for how the team's evaluation process could improve, a piece of documentation that didn't exist before. 

This marks the transition from "new hire being onboarded" to "team member who happens to be relatively new," a meaningfully different internal status even if the title hasn't changed.

This transition isn't always announced explicitly, it usually shows up in smaller, practical signals: being looped into a new customer's kickoff call without being asked to shadow first, a manager asking your opinion on scoping a new engagement rather than just informing you of the plan, or being given a slightly larger or more ambiguous piece of work than your original assignment without extensive hand-holding. 

None of these individually feel like a milestone at the moment, but collectively they mark the actual end of the onboarding period, regardless of what any formal 90-day review process says.

What Managers Are Actually Evaluating During This Window

Managers watching a new FDE through this period are rarely evaluating raw technical output as the primary signal, most new hires can code well enough by the time they're hired. What they're actually watching for:

• Judgment under the week 5-8 wall: How you handle the first genuinely ambiguous scope conflict tells a manager more than any clean technical delivery in the first month.
• Whether questions get sharper over time: New FDEs who ask better, more specific questions in week eight than week two are demonstrating real learning. Engineers whose questions stay generic are a quieter warning sign.
• How you respond to being told you're wrong: Discovery assumptions get corrected constantly in this role. Managers watch specifically for defensiveness versus genuine recalibration.
• Early signs of the habits senior FDEs rely on: Our piece on habits of successful Forward Deployed Engineers covers these directly, discovery discipline, real-time documentation, evaluation-first thinking. Managers are watching for the earliest versions of these habits forming, not full mastery yet.

How to Make the Most of Your First 90 Days

Resist the urge to rush past the slower weeks 1-2 onboarding just to feel productive sooner, the internal context you build there genuinely reduces mistakes later. Treat your first assignment as a chance to demonstrate judgment on manageable stakes, not as a disappointing consolation prize compared to a bigger engagement. 

When you hit the week 5-8 wall, and you likely will, resist the instinct to hide the uncertainty from your manager. Every FDE Roadmap includes moments where judgment matters more than certainty, so naming it directly ("I'm not sure whether I should extend scope here or push back") is a stronger signal than pretending you have it fully figured out.

Our guide on mistakes new Forward Deployed Engineers make covers the specific failure patterns that tend to surface exactly during this window.

A few additional habits worth adopting deliberately from day one, rather than waiting until they feel natural: ask your manager directly, early, what a strong first 90 days actually looks like in their eyes, since expectations vary meaningfully between companies and even between managers at the same company. 

Keep a running, private log of questions you had to ask more than once, since a repeated question is usually a sign of a gap worth closing systematically rather than continuing to ask around it.

And resist comparing your visible progress to peers who started at the same time, since the specific customer or assignment you land can shape how visible your early wins are in ways that have little to do with actual skill or trajectory.

TL;DR

‍The first 90 days as a Forward Deployed Engineer progress from onboarding and shadowing to managing your first customer project, overcoming early challenges, and earning trust. Success depends more on judgment, adaptability, and communication than technical skills alone.