# By day 60, the client asks you first: a 90-day plan for a new FDE

> For the first two weeks you take on nothing of your own. By the third month, according to Cloudsoft's playbook, you should have taken one piece of work past the demo stage.

Original: https://fdetimes.net/en/guides/new-fde-first-90-days-plan/

Under Tandem's onboarding playbook, by day 60 the order has flipped: client questions reach the new FDE first, and the senior engineer is pulled in only for exceptions. Two months earlier, that same new FDE had not yet taken on any work of their own.

The distance between those two points is your first 90 days. As fde.academy describes it, the first two weeks usually go on internal learning and shadowing a senior FDE on a live engagement. Managers also deliberately hand newcomers low-risk, clearly scoped work first.

If you are about to accept an FDE offer, or have just moved over from software engineering, that slow pace can feel like being sidelined. In fact it is a progression, and you can climb it step by step rather than waiting to be given work. Note that the specific day milestones come from individual companies' playbooks; they are not an industry standard.

## What will you build, and what do you need first?

You will build a `90-day-plan.md` file in your personal notes repo. It has four sections: a call log, a question log, your day-30 account review, and a description of the scope you will take on.

You need three things: a live engagement you are allowed to shadow, a mentor who agrees to meet you regularly, and a calendar to mark the milestones. If it is not clear who your mentor is, ask your manager in the first week.

```markdown
# 90-day-plan.md  (simplified template)
## Milestones
- Weeks 1-2: internal learning, shadow a senior FDE
- Day 30: walk the mentor through the account
- Month 2: take on a low-risk scope
- Day 60: the client asks me first
- Month 3: one piece of work past the demo stage
- Day 90: decision on account ownership
## Call log
## Question log
## Scope
```

Check: every milestone must have a specific date on the calendar. Any milestone you cannot yet date is the first question to take to your manager.

## 1. Shadowing does not mean sitting and listening

Cloudsoft's 90-day playbook sets the first month's goal as becoming safely useful, not producing a lot. It also warns against attending calls passively: on every call, you should give yourself a task.

**Key point:** The first month is measured not by volume of work but by becoming safely useful.

That task might be listing every system the client mentions, or noting the commitments the senior FDE has just made. After the call, compare your notes with your mentor's. Wherever the two differ is where you have not yet understood.

```markdown
## Call log (hypothetical example)
2026-11-04 | Client: operations team
Self-assigned task: list the data sources
- What I captured: ERP, weekly inventory Excel file
- What my mentor added: an internal API I missed
```

Check: by the end of the first week, every call you attended must have a "Self-assigned task" line. Any blank line is a call where you only listened.

## 2. What to ask your mentor, and what to find yourself

Tandem builds its whole playbook on one distinction: context can be handed over, judgement cannot. So a senior engineer's time is best spent on judgement. For you, that becomes a concrete habit: classify each question before you take it to anyone.

Picture a retail account. "Where does the order data live?" is a context question; you can find the answer yourself in the docs, tickets or the call log. "Should we promise the client hourly alerts when the sync job only runs overnight?" is a judgement question, and that is what deserves your mentor's time.

```markdown
## Question log (illustrative example)
| Date | Question | Type | Who answers |
| 11-05 | Where does the order data live? | Context | Find it myself |
| 11-20 | Should we promise hourly alerts? | Judgement | Mentor |
```

Check: each week, count how many context questions you asked instead of looking up. That number should fall over time.

## 3. Day 30: walk your mentor through the account

Tandem schedules a check-in at day 30 in which the new FDE presents the entire account back to their mentor. You do the talking, and every point where you stumble shows which area you are still missing.

```markdown
## Account review (simplified outline)
1. What problem the client needs solved, and who makes the decisions
2. Systems and data sources in use
3. What has been promised to the client, and the deadlines
4. The biggest current risk
5. Three things still uncertain
```

Check: you must cover all five points without opening your notes. If point 3 is still empty, fill it before asking for your own scope in month 2, because you cannot keep a promise you do not know about.

## 4. Month 2: take on a small scope with real risk

Cloudsoft treats the second month as the point where you stop shadowing and start owning work. Fde.academy says the first piece of owned work is often full responsibility for a small client, where the risk is real but contained.

What does that scope look like? Supergood's job listing describes an FDE's work as client deployments, ongoing support and new integrations. The advice here is to take just one of those, with a single data source: if you take on two at once and everything breaks, you will not know where the fault lies.

```markdown
## Scope (hypothetical example)
Client: small retail chain X
Work type: new integration
Use case: out-of-stock alerts
Data source: one inventory table in the ERP
Out of scope: supplier data, user interface
```

Check: the "Out of scope" section must not be empty. It is the line you will point to when the client wants to add requests midway.

## 5. Day 60: the client asks you first

By day 60, according to Tandem, the new FDE receives client questions first and pulls in the senior engineer only for exceptions. For this milestone to run smoothly, you and your mentor should agree in advance on what counts as an exception.

A sensible approach is to use the question log: you handle context questions yourself, and pull your mentor in on anything that needs judgement about commitments, scope or client risk. Write that rule as three lines in your plan file so you can both see it.

## 6. Month 3 and day 90 are two different milestones

Cloudsoft's goal for the third month is to take one piece of work past the demo stage. One way to draw the line: a demo only needs to run once on hand-picked data, whereas something past the demo stage is usable by the client on real data without you standing next to it.

Fde.academy identifies the signs of readiness for less supervised work in the day 60-90 period: a deployment that works, and a relationship in which the client clearly trusts you. Tandem's day-90 milestone is something else: the mentor decides whether to keep ownership of the account or hand it over fully to the new FDE.

Fde.academy's two signs are exactly the evidence to bring to the day-90 conversation. Record them in your plan file as concrete items: which deployment is running, and which questions the client sent straight to you.

## Common mistakes

The most common mistake is wanting to ship something in week 2 to prove yourself. When your manager is deliberately giving you low-risk work first, running ahead of the plan tends to make you look careless rather than capable.

Another is taking every context question to your mentor, leaving them no time for judgement, the one thing you cannot learn on your own. Nor should you skip the account review because you feel you are already on top of things. If your company has no day-30 milestone, propose one yourself.

## How to put these 90 days on your CV and into interviews

Palantir describes its Forward Deployed Software Engineers as working directly with clients, often on site, and following projects from start to finish. If employers are looking for people who see a project through, your CV line should tell a complete loop: the scope you took on, and how far it went.

So do not write "participated in a client deployment project"; write "owned the ERP inventory integration for one client and took it from demo to production use".

When reading job descriptions, look at whether expectations for senior FDEs include mentoring newcomers. Vanta's Senior FDE listing, for example, explicitly mentions documenting best practices and mentoring teammates. In interviews, ask directly: "By day 60, who will the client ask first?"

The goal of the 90 days is not lines of code. It is the day the client asks you first, and you know which questions you can answer yourself and which ones need your mentor.

**Try this week:**

- Create a 90-day-plan.md file with four sections: call log, question log, day-30 account review, and scope description
- On your next client call, give yourself a specific task, such as noting every system and data source the client mentions, then ask your mentor to compare notes
- Schedule the day-30 check-in now, at which you will walk through the entire account without opening your notes

## Sources

- [Forward Deployed Engineer First 90 Days: What Actually Happens on the Job](https://fde.academy/blog/forward-deployed-engineer-first-90-days)

- [Your First 90 Days as a Forward Deployed Engineer: A Practical Playbook](https://cloudsoftsol.com/blog/fde-first-90-days/)

- [Onboarding a second FDE onto a live account: the ramp playbook, and the context it depends on](https://usetandem.ai/blog/onboarding-second-fde)

- [Forward Deployed Software Engineer (Palantir Technologies, Stockholm, Sweden)](https://jobs.lever.co/palantir/d084b769-6f53-4409-afa8-c183b059b384)

- [APIs for software that doesn't have APIs.](https://supergood.ai/careers/forward-deployed)

- [Senior Forward Deployed Software Engineer - Vanta | Built In](https://builtin.com/job/sr-forward-deployed-engineer/7502606)