The first 90 days decide how your customers, your team and you yourself see your work as a Forward Deployed Engineer. A good forward deployed engineer first 90 days plan has three phases: spend days 1 to 30 learning the product, platform and internal tools while shadowing customer calls and shipping one small fix; spend days 31 to 60 owning a customer workstream end to end, from discovery to a scoped POC; and spend days 61 to 90 taking one thing toward production, building a reusable asset and feeding what you learned back to product. This playbook gives you the checklists, artefacts, relationships and progress measures for each phase, plus the mistakes that slow most new FDEs down.
New to the role itself? Start with what a Forward Deployed Engineer is. This article assumes you have the offer, or soon will.
Why the first 90 days matter more for FDEs
In most engineering roles you can spend a quiet first month reading code. FDE onboarding is different, for three reasons.
- You are visible to customers early. The first time a customer's architect or risk officer meets you, they decide whether you are "the vendor's engineer who knows things" or "the new person we have to explain everything to".
- You work across too many systems to learn them all. Your company's platform, the customer's identity provider, their data sources, their ticketing tool, their change process, plus whatever models and frameworks the solution uses. You need a deliberate learning order, not a reading list.
- Trust is the real deliverable. Your manager wants to know when they can put you alone in front of a customer. Your customers want to know whether your estimates hold.
The path itself never changes: customer problem, discovery, data, architecture, integration, security, deployment, observability, evaluation, business outcome. What changes is how much of it you own: in month one you watch it, in month two you drive a slice, in month three you carry something to the far end.
Days 1-30 Days 31-60 Days 61-90
LEARN --> OWN A SLICE --> CARRY TO PROD
shadow discovery security review
small fix scoped POC eval + observability
notes write-ups handover + asset
|
v
feedback loop to product
Throughout this playbook we use one illustrative example. Consider Ananya, a new FDE at an enterprise AI platform company. After two weeks of internal onboarding she is attached to a private bank's Global Capability Centre in Hyderabad, where the team wants an internal assistant that answers operations staff questions from policy documents and raises ServiceNow tickets when a process breaks. Ananya and the bank are fictional; the patterns are common.
Days 1โ30: learn the product, the platform and the people
Month one is not about output. It is about becoming useful safely: knowing what your company sells, how it is deployed, how the internal machinery works, and how senior FDEs actually run engagements.
Learn the product the way a customer meets it
Install or provision your company's product from scratch using only the public documentation. Note every place you got stuck, every unclear error message and every step that needed tribal knowledge. This list becomes your first contribution: new FDEs are the only people who still see the onboarding friction customers see.
Then learn the platform underneath it. For an AI product that usually means: which model providers it supports (for example Amazon Bedrock, Azure OpenAI or Gemini), how retrieval works and where the vectors live, how agents call tools (often through MCP, the Model Context Protocol, or direct APIs), how identity flows from the customer's single sign-on into permission checks, and what gets logged and traced. By day 30, you should be able to draw the reference architecture from memory.
Learn the internal tools
Every FDE team has its own machinery: the repository of deployment templates, the internal ticket queue for product bugs, the escalation path to the platform team, the shared folder of past customer write-ups, the evaluation harness, and the dashboards on-call engineers watch. Ask your manager for a list, then actually use each tool once in the first two weeks.
Shadow customer calls, with a job
Ask to join as many customer calls as your senior colleagues will allow: discovery sessions, weekly status calls, architecture reviews, incident calls if there are any. Do not attend passively. Give yourself a job on every call:
- Take the notes and send them to the senior FDE within the hour for correction.
- Write down every question the customer asked that you could not have answered.
- Note who in the customer's team actually makes decisions, and who only speaks.
- After the call, ask the senior FDE one question: "What were you trying to find out that you didn't say aloud?"
That last question is where the real learning happens: experienced FDEs probe data access, budget ownership and security appetite in ways a newcomer cannot see.
Ship a small fix
Before day 30, merge something real. A broken example in the deployment template, a confusing log message, a missing retry on a connector, a documentation error you hit during your own install. The point is to go through your team's full release path once: review, CI, release notes, and seeing it live in a customer environment. Ananya's was a document loader fix: it silently skipped password-protected PDFs.
Days 1โ30 checklist
- Installed the product from public docs and filed a friction list.
- Can draw the reference architecture from memory, including identity, data, model and tool layers.
- Used every internal tool once: ticket queue, deployment templates, evaluation harness, dashboards.
- Shadowed at least one discovery call, one status call and one architecture review, with notes sent.
- Read the write-ups from the last few engagements similar to your first customer.
- Merged one small fix through the full release path.
- Had a one-to-one with each person listed in the relationships section below.
- Agreed with your manager, in writing, what "good" looks like at day 60 and day 90.
Days 31โ60: own a customer workstream
Month two is when you stop shadowing and start owning. Ask for a bounded workstream with a single customer: one use case, one integration, one data source. Not the whole account. Ownership means the customer knows your name, you run the meetings for that workstream, and status updates come from you.
Run your first discovery
Your first discovery session will feel slower than the ones you shadowed. That is fine. Prepare a short question list in advance, and make sure you leave with answers to the questions that kill projects later: what decision or task this improves, how success will be measured, which data sources are involved and who grants access, which users and roles exist, what the security and compliance constraints are, and who signs off. For a structured method, see how to find and prioritise enterprise AI use cases, and for running the room itself, the FDE customer workshop playbook.
For Ananya, discovery surfaced something the sales notes missed: operations staff were not allowed to see certain internal policy documents, and permissions lived in Active Directory groups synced to Microsoft Entra ID. Retrieval would have to filter by group membership, not just relevance. That one finding changed the architecture.
Build your first scoped POC
Scope the POC to answer a question, not to impress. "Can we answer the 40 most common operations questions from these three policy folders, with citations, respecting group permissions?" is a POC. "Build a smart assistant for operations" is a wish. Write down the success criteria before you write code, and build a small fixed test set of real questions with expected answers, agreed with a customer subject-matter expert.
Keep the POC honest: realistically messy documents, the customer's actual identity model, and a measured result. The stage gates that follow a POC are covered in depth in how FDEs take AI from POC to production; in month two you only need to get your first POC through its first gate.
Write things up
New FDEs underrate writing. In month two, every meaningful event should leave a written trace: discovery notes, a one-page design, a decision record when you choose between options, and a short POC result summary with what worked, what failed and what you would do next. Writing lets your manager and the customer see your judgement without being in every meeting.
Days 31โ60 checklist
- Own one named workstream with one customer, with your name on the plan.
- Ran a discovery session yourself and circulated notes within a day.
- Success criteria and a fixed test set agreed with a customer expert before building.
- POC built on realistic data and the real permission model, with a measured result.
- At least two architecture decision records written.
- Sent a weekly status update every week, including the bad weeks.
- Raised at least one product issue or feature gap from the field, with evidence.
- Asked a senior FDE to review one of your customer write-ups and acted on the feedback.
If you would rather rehearse discovery, POCs and write-ups before a real customer is watching, that is what the weekly Customer Engagement Lab in Cloudsoft's AI Forward Deployed Engineer course is built for: you run simulated customer sessions alongside the engineering labs, ending in the "GlobalBank" capstone engagement.
Days 61โ90: carry something toward production
By month three you should push one thing past the demo stage. It may not reach full production in 90 days, since enterprise approvals take as long as they take, but it should be visibly on its way, with the hard non-functional work started rather than deferred.
Security review
Book the customer's security review early; it is usually the longest lead time on the plan. Prepare a short pack: the architecture diagram with data flows, where data is stored and for how long, which model endpoints are called and in which region, how identity and authorisation work (including what the agent's own identity can do), how secrets are managed, how prompt injection and data leakage are handled, and what is logged. Answer questions in writing. For the threat model, see AI security for enterprise systems.
Evaluation
Turn your POC test set into a proper evaluation suite: more questions, edge cases, questions the user should be refused, and permission tests ("can a user outside the group see this document's content?"). Run it in CI so a prompt or model change cannot silently degrade quality. Produce an evaluation report the customer can read: what was tested, the scores against the agreed bar, known failure patterns and what you changed. Metric choices for retrieval systems are covered in RAG evaluation metrics.
Observability
Instrument the system so someone other than you can tell whether it is healthy: traces for each request through retrieval, model and tool calls; latency and error rates; token cost; user feedback; and alerts with named owners. Tools like Langfuse or LangSmith for LLM traces and OpenTelemetry for the wider system are common choices. See AI observability for what to capture.
Handover
Production means someone else can run it. Write a runbook: how to deploy and roll back, how to rotate secrets, how to re-index documents, what each alert means and what to do, known failure modes, and who to escalate to. Walk the customer's operations team through it and ask them to do one deploy or rollback while you watch. A handover nobody has rehearsed is not a handover.
Build one reusable asset
Look across what you built and pick one piece that the next FDE will need: a connector, an evaluation template, a Terraform module for the standard deployment, a permission-aware retrieval filter, a security review answer pack. Clean it up, document it and contribute it to your team's shared repository. In Ananya's case it was the group-based retrieval filter for Entra ID, which two other engagements went on to reuse.
Close the feedback loop to product
FDEs see the product where it meets reality. Turn that into a short written product feedback note: the three or four gaps that cost you the most time, each with evidence (customer, impact, workaround used) and a suggested fix. Send it to the product manager, then follow up. Reliable field signal is how a new FDE earns influence inside the company.
Days 61โ90 checklist
- Security review submitted with a written pack; open questions tracked to closure.
- Evaluation suite running in CI, with a customer-readable evaluation report.
- Traces, metrics, cost tracking and alerts live, each alert with an owner.
- Runbook written and rehearsed with the customer's operations team.
- One reusable asset contributed to the team repository, with documentation.
- Product feedback note sent with evidence, and at least one follow-up conversation.
- A day-90 review with your manager against the criteria agreed in month one.
The artefacts you should produce
An FDE's work is judged largely through artefacts, because most stakeholders never see your code. By day 90 you should be able to point to each of these.
| Artefact | When | What it contains | Main reader |
|---|---|---|---|
| Discovery notes | Days 31โ45 | Problem, success metric, users and roles, data sources and owners, constraints, open questions, next steps | Customer sponsor, your manager |
| Architecture decision records (ADRs) | From day 35 | Context, options considered, decision, consequences; one decision per record | Customer architects, future you |
| POC result summary | Days 50โ60 | Scope, test set, results against criteria, failures, recommendation | Sponsor, account team |
| Security review pack | Days 61โ75 | Data flows, storage, identity, secrets, model endpoints, threat handling, logging | Customer security team |
| Evaluation report | Days 65โ85 | Test coverage, scores against the bar, failure patterns, changes made | Sponsor, risk and quality owners |
| Runbook | Days 75โ90 | Deploy, rollback, re-index, alerts and responses, escalation | Customer operations team |
| Product feedback note | Days 80โ90 | Top field gaps with evidence and suggested fixes | Product manager |
A useful ADR is short. Ananya's first one was half a page: "Context: operations staff must not see restricted policy content. Options: separate indexes per group; metadata filter on group IDs at query time; post-retrieval filtering. Decision: metadata filter at query time, with group claims from the Entra ID token. Consequences: index must carry group metadata; re-sync job needed when document permissions change." That half page ended a re-debate when a new architect joined the customer team.
Relationships to build in your first 90 days
Skills got you hired; relationships decide how fast you can use them. Build these from month one.
- A senior FDE as your informal mentor. Someone who will review your write-ups and tell you what they really think. Ask for 30 minutes a week.
- Your manager. Agree expectations in writing at the start, and give them a short weekly update so they never have to chase you.
- Product managers. They need your field signal; you need their roadmap. Meet them before you have a complaint.
- Core platform engineers. When something breaks at an awkward hour, the engineer who knows you helps fastest. Bring them precise bug reports.
- The account or customer success lead. They know the commercial context: renewal timing, executive politics, past disappointments. Never surprise them in front of a customer.
- On the customer side: the business sponsor, the architect, the security reviewer, the data owner and at least one end user. The end user is the one most new FDEs forget, and the one whose feedback carries most weight in a pilot review.
A realistic sample week: Ananya in week 7
The week in the life of an experienced FDE shows a mature engagement. A new FDE's week looks different: more learning, more asking, more first attempts. Here is Ananya's week 7, when she owns the policy assistant workstream and her POC is nearly done.
| Day | Customer work | Internal work | Learning |
|---|---|---|---|
| Monday | Weekly status call she now runs; flags that scanned PDFs are hurting answer quality | Writes the week plan and shares it with her mentor | Reads two past engagement write-ups on document parsing |
| Tuesday | Works with the data owner to get a cleaner export of three policy folders | Files a product issue: the parser drops table content, with sample files and impact | Pairs for an hour with a platform engineer on the ingestion pipeline |
| Wednesday | Runs the test set; misses permissions test on two documents; fixes the metadata sync | Writes ADR on handling permission changes between re-indexes | Asks her mentor to review the ADR before sending |
| Thursday | Short session with three operations staff trying the POC; collects their questions verbatim | Adds their real questions to the test set | Shadows a senior FDE's security review on another account |
| Friday | Sends POC result summary: meets the bar on answer quality, permission tests now pass, scanned documents remain a known gap | Weekly update to her manager; books the security review slot for week 9 | Notes three things she would do differently next time |
Note the learning column: Thursday's shadowing of another account's security review is direct preparation for month three.
Mistakes new FDEs make
- Building before discovery is done. If you cannot state the success metric in one sentence, you are not ready to build.
- Saying yes to everything in the room. New FDEs want to please. Instead, write the request down, say when you will come back with an answer, and check scope with your senior or account lead.
- Demoing on clean data. A demo on hand-picked documents sets expectations that production cannot meet. Show real data and real limitations early.
- Hiding bad news until Friday. A blocked data access request on Tuesday is a small problem. The same block revealed in the executive review is a trust problem. Escalate early, in writing, with a proposed next step.
- Treating security and evaluation as month-four work. Both have long lead times. Start the conversations in month two.
- Building one-off code. If every engagement starts from scratch, you will not scale. Ask on day one which internal assets exist, and leave one behind by day 90.
- Not writing things down. If your decisions live only in chat threads, nobody can review your judgement, including your manager at appraisal time.
How to measure your own progress
Do not wait for your manager's review. Track these signals honestly every two weeks.
| Signal | Day 30 | Day 60 | Day 90 |
|---|---|---|---|
| Customer independence | Shadows calls, takes notes | Runs workstream calls alone | Customer contacts you directly with new problems |
| Shipping | One small fix merged | POC with measured result | Something past security review or in pilot |
| Writing | Clean call notes | Discovery notes and ADRs that need light edits | Evaluation report and runbook others reuse |
| Estimation | Not yet expected | Estimates sometimes slip; you flag it early | Most estimates hold; slips are explained |
| Team leverage | Uses existing assets | Files useful product issues | Has contributed one reusable asset |
| Senior help needed | Daily | A few times a week, for judgement calls | Mainly for unusual or high-risk decisions |
Two questions are worth asking yourself at day 90. First: could your manager put you alone on a new customer workstream next month without worrying? Second: is there something in production, or close to it, that would not exist without you? If both answers are yes, your first quarter worked. If not, the table shows you which row to fix.
Preparing before day one
Most of this playbook gets easier if you arrive having already done the work once in a safe setting: run discovery, built a permission-aware RAG system, wired an agent to a ticketing tool, written an evaluation suite, deployed to Kubernetes with CI/CD, and written a runbook. The skills employers look for in FDEs map closely onto the checklists above.
Rehearsing that loop on simulated customer engagements, before a real customer is watching, is the fastest way to shorten your own first quarter.
If you are earlier in your journey and still building Python, cloud and core AI foundations, the 16-week APEX AI, ML, Cloud and Security program is the better starting point; our APEX vs FDE PRO comparison helps you choose.
Frequently asked questions
What should a forward deployed engineer focus on in the first 30 days?
Learn the product by installing it from public docs, learn the platform architecture and internal tools, shadow customer calls with a specific job on each one, and merge one small fix through the full release path. The goal is to become useful safely, not to produce large output.
When should a new FDE take ownership of a customer workstream?
Usually in the second month, once you understand the product and have shadowed several customer calls. Start with a bounded workstream: one use case, one integration or one data source with a single customer, rather than a whole account.
Is it realistic to reach production within 90 days?
Not always. Enterprise security reviews, data access approvals and change processes set their own pace. A realistic day-90 goal is that one piece of work is clearly on its way to production, with the security review submitted, evaluation running in CI, observability live and a rehearsed runbook.
What documents does an FDE write in the first 90 days?
Discovery notes, architecture decision records, a POC result summary, a security review pack, an evaluation report, a runbook and a product feedback note. Most stakeholders judge an FDE through these artefacts because they rarely see the code.
How do I know if my first 90 days as an FDE went well?
Ask two questions. Could your manager put you alone on a new customer workstream without worrying? Is there something in production, or close to it, that would not exist without you? If both answers are yes, your first quarter worked.
What is the most common mistake new FDEs make?
Building before discovery is finished. A POC built on an unclear problem or on hand-picked clean data wastes time and sets false expectations. Agree the success metric, the data and a fixed test set with the customer before writing code.
Can I prepare for FDE onboarding before I get the job?
Yes. Practise the full loop on realistic projects: discovery, a permission-aware RAG system, an agent connected to enterprise tools, an evaluation suite, a Kubernetes deployment with CI/CD, and a runbook. Arriving with that experience makes every phase of the first 90 days faster.
Want to walk into your first FDE role having already run this loop? FDE PRO, Cloudsoft's Forward Deployed Engineer course in Hyderabad, runs 12 weeks: 120+ hours of live sessions, 60+ labs, a weekly Customer Engagement Lab and five enterprise projects, including the Enterprise Knowledge Assistant, the ServiceNow AI Agent via MCP and the Secure Banking AI Assistant, ending in the "GlobalBank" simulated customer engagement. Join in the classroom beside Ameerpet Metro or live online, with placement support until you're placed. For a free demo, call +91 96660 19191.
