Your New FDE's First 90 Days

You just hired a great FDE. The temptation is obvious. Your biggest customer is on fire, the new hire is smart, so you send them in on Monday.

Don’t. Even strong FDEs need time to learn your product, your codebase, and how your team talks to customers. If their first customer meeting goes badly, the customer remembers. So does the new hire.

The opposite mistake is just as costly. Three months of reading docs turns an FDE into a spectator. The goal is a ramp that gets them shipping real code in week one and owning a real customer by day 90, with the difficulty climbing on purpose.

What the Good Onboarding Programs Have in Common

This plan borrows from programs that are published and battle-tested.

• Ship in week one. Gergely Orosz’s Good Onboarding, Great Onboarding at The Pragmatic Engineer notes that companies like DoorDash, Lyft, and Uber aim to have new engineers ship a change in their first week. The same piece recommends an assigned buddy from the first day and starting onboarding when the offer is accepted, not on day one.
• Layer the context. Lizzie Matusov’s five onboarding practices on LeadDev advises introducing the team, then the stack, then the domain, then the first project, and suggests shadowing customer calls to build user empathy.
• Use a buddy with a schedule. GitLab’s onboarding buddy guide asks buddies to meet on day one, hold at least two calls in the following week, and keep weekly calls through the first month.
• Move from shadow to lead. GitLab’s Solutions Architect onboarding is the closest public analog to FDE onboarding. New SAs shadow calls in month one, do ride-alongs and recorded demos in month two, and discuss taking over accounts in month three.

Customer-facing engineers need one more ingredient: a safe place to fail in front of a customer before it counts. That is what the middle of this plan is for.

Before Day One

Start the moment the offer is signed. Orosz and First Round Review’s onboarding timeline both stress this.

• Pick a buddy: a current FDE, not their manager. Clear time on the buddy’s calendar for the first month.
• Get laptop, accounts, and access to staging and internal tools ready. A new FDE waiting on credentials in week one is learning the wrong lesson.
• Pick the first customer they will eventually own. Choose a stable, friendly account with moderate complexity. Not your loudest customer.
• Write a one-page plan with the milestones below and send it before day one.

Week One: Learn the Product by Shipping It

The goal is confidence in the product and the codebase. No solo customer contact yet.

Milestones by Friday:

• Run the product end to end the way a customer would. Set up a fresh demo environment from scratch and write down every place it was confusing.
• Ship one small change to production. A bug fix, a config improvement, or a fix to the onboarding docs they just struggled with. Orosz recommends having new joiners improve the docs as they go.
• Sit in on at least three customer calls as a silent observer. Pick different stages: a scoping call, a deployment check-in, an escalation.
• Meet the people they will lean on: their buddy, a product engineer, the account lead for their future customer, and whoever runs support.

Manager check: A 30-minute 1:1 on Friday. Ask what surprised them and what still feels fuzzy.

Days 1-30: Shadow, Then Co-Pilot

The goal is to understand how your team deploys, then to do it with a net.

Weeks two and three: shadow a live deployment. Pair them with a senior FDE on an active account. They take notes in every customer meeting, then debrief right after. What did the customer really want? What did the senior FDE choose not to say? These debriefs are where judgment transfers.

Week three: run an internal role-play. Have a teammate play a difficult customer: a missed deadline, a scope fight, a security team blocking access. Our role-play script works for this. It is far cheaper to fumble here than in front of a real CTO.

Week four: own a scoped piece of real work. Inside the shadowed deployment, give them one integration or one workflow to build. They present it to the customer, with the senior FDE in the room.

Milestones by day 30:

• Has shipped several production changes, including at least one customer-facing piece of work.
• Can demo the core product to a technical audience without help.
• Has written a short deployment playbook draft from what they observed. Gaps in this document show you what to teach next.
• Buddy calls have happened weekly, following GitLab’s cadence.

Days 31-60: Lead With a Net

The goal is to run customer work themselves, with someone senior watching closely.

Hand over the first account. This is the stable, moderate account you picked before day one. The new FDE becomes the main technical contact. The senior FDE stays on the account, joins key meetings, and reviews plans before they go to the customer.

Let them run discovery. Before they build anything, have them lead a scoping session and write a one-page plan: the problem, the data, the users, what success looks like. Review it together before it goes to the customer. This is the decomposition skill from your interview, now on real ground. Our guide to interview questions for FDEs covers what good looks like.

Feed product. Ask them to file at least one well-written product request or bug from the field, with evidence. Marty Cagan’s writing on FDEs at SVPG argues the model only works when field learning makes its way back into the platform. Teach that habit early.

Milestones by day 60:

• Primary technical contact on one customer, with the account lead and customer both aware.
• Has led at least one discovery session and delivered a written plan.
• Has handled one hard customer moment, such as a delay, a no, or an outage, with a debrief afterward.
• Has filed field feedback to product that someone acted on or explicitly declined.

Days 61-90: Own It

The goal is independence on one account and readiness for a second.

Step the senior FDE back. They stop joining routine meetings and become an escalation point. The new FDE now owns the plan, the code, and the relationship.

Add a second, harder assignment. A new deployment in its scoping phase, or a tougher piece of an existing one. This is where they stretch, with a smaller net.

Do a 90-day review. Look at outcomes, not hours. What did they ship? How do their customers describe them? What did they teach the team?

Milestones by day 90:

• Running one account independently. The customer goes to them first.
• Contributing to a second deployment.
• Has updated the team’s deployment playbook based on their own experience.
• Can name the two or three skills they want to build next, and you agree.

The Hardest Customer Can Wait

Somewhere around month four, you can put this person on a difficult account. Not before.

Palantir’s own writing shows why the role takes time. In Who Wants to be a Delta?, a Palantir FDE describes trying at first to map her old backend role onto the new job, and only progressing once she accepted the role was different. A structured ramp shortens that adjustment. Throwing someone into a crisis extends it.

There is a counterpoint worth taking seriously. Nabeel Qureshi’s Reflections on Palantir describes a culture of getting on a plane first and asking questions later, and it worked for some people. But that was a company with deep FDE benches, a reading list, and many senior people to catch mistakes. Most startups hiring their first few FDEs have none of that. Build the net before you remove it.

Common Mistakes

• No buddy, or a buddy with no time. The buddy role needs space on the calendar, not just a name.
• A first account picked by urgency. Choose for learning, not for whatever is on fire.
• No written milestones. Without them, a 90-day review turns into a vibe check.
• Skipping the role-play. It feels awkward. It is also the cheapest way to see how someone handles pressure before a customer pays for the lesson.
• Never stepping back. If the senior FDE is still in every meeting at day 90, the ramp has not worked.

If you are still planning your team’s shape, read how many FDEs per customer to decide where your new hire fits.

Where We Come In

Forward Deployed Hiring vets every candidate on a technical screen and a live customer role-play before you meet them, so your new FDE arrives having already handled a tough customer moment once. You run the final interviews. It is free to interview our candidates. See how we vet.