필사 모드: The First 90 Days as an FDE — Mapping, Solo Tickets, and a Led Mission

• Why the 90 Days Must Be Designed
• Month One — Map the Environment, the Product, and the People
• Month Two — Handle Tickets Alone
• Month Three — Lead a Mission
• What Should Be Visible When the 90 Days End
• Practice by Doing

Why the 90 Days Must Be Designed

A regular engineer's onboarding has one layer: adapt to the new company's codebase and people. An FDE's onboarding has two. You are learning your own company's product and organization while simultaneously adapting to the systems and people of the customer you cover. Because two unfamiliar environments overlap, walking in without a plan means that three months later you have taken root in neither.

So the first quarter should be designed, not drifted through. The 90-day frame below is not copied from any company's program; it is a construct generalized from the structure of the FDE role. The skeleton has three stages: month one is mapping, month two is solo tickets, month three is a led mission. Fix each month's goal in one sentence and the weekly checklists follow naturally.

The principle underneath is the trust account. At a customer site, an FDE's voice comes not from the title but from accumulated trust, and trust accumulates not from one big win but from the repetition of small promises kept. The purpose of designing the 90 days is not a flashy debut; it is opening this account without going negative. Conversely, a bad first impression made in month one charges interest for the rest of the engagement. Every item in the checklists below is, in the end, a deposit into this account.

Month One — Map the Environment, the Product, and the People

The goal of the first month is not results; it is a map. The accuracy of the map you draw here sets the speed of the following two months.

• Week 1 — a full census of access. VPN, SSO, code repositories, the ticket system, and the paths into customer environments: check every account one by one and turn whatever does not work into a request list. Install your own product from scratch using only the documentation. Where the install blocks you is exactly where it blocks customers.
• Week 2 — the technical map of the customer environment. Draw the customer's system architecture as a diagram yourself, read the deployment path and the last three incident writeups. The parts you cannot draw become your question list.
• Week 3 — the people map. Sort out who at the customer decides, who actually uses the product, and who will be the champion on your side. Write down your own company's escalation path while you are at it. Meetings are still for observing at this stage.
• Week 4 — ticket shadowing. Watch a senior colleague handle tickets end to end, build an inventory of the runbooks that exist, and compile a glossary of the customer's abbreviations and vocabulary.

The trap of month one is impatience. Skip the mapping because you want to show something quickly, and the speed you gain in month two returns as an accident in month three.

Month Two — Handle Tickets Alone

The goal of the second month is the first deposit in the trust account. Completeness matters more than size.

• Weeks 5 and 6 — take low-risk tickets solo. Record the entire handling process, and run the customer communication yourself with a supervisor on CC. Whether the interim update went out when promised matters more than how fast you solved it.
• Weeks 7 and 8 — raise the ticket difficulty one notch and join incident response as a secondary. Pick one ticket you handled and write a recurrence-prevention proposal. That document often becomes your first quick win.

The trap of this month is hunger for speed. Trust accumulates from the regularity of communication, not the quickness of resolution. A delay that was announced in advance does not drain trust; a fast fix that arrives after radio silence leaves anxiety behind.

Month Three — Lead a Mission

The goal of the third month is to lead one small thing from start to finish.

• Weeks 9 and 10 — pick a two-week-sized project, one integration or one migration, and lead it. Before starting, write the success criteria down and agree on them with the customer. A project started without a criteria document can never truly be declared finished.
• Weeks 11 and 12 — execute, then leave a retrospective. Run a regular customer meeting alone, and pay your onboarding debt forward by fixing the onboarding docs where you got stuck. The amount by which the next person's 90 days shrink is your contribution.

What Should Be Visible When the 90 Days End

At the three-month mark, three questions reveal whether the onboarding worked. First, can you draw your customer's system diagram from a blank page? Second, can you explain that customer's stakeholder map — who decides, who uses? Third, when an incident report arrives, do you already know what your first 30 minutes look like?

If any of the three is blurry, go back to month-one mapping for that area alone. Onboarding is a circuit, not a straight line, and rewinding to a weak segment is itself the normal trajectory. The goal of month three is not to be perfect; it is to be someone who knows precisely where their own gaps are.

If all three have answers, onboarding is done. If the third is blurry, the next post is exactly that story: the incident diagnosis playbook.

Practice by Doing

The feel of those 90 days can be rehearsed in simulation first.

• FDE Career RPG — starting at low levels and earning access and trust is a miniature of onboarding month one.
• FDE Curriculum Roadmap — pre-check the technical items of your month-one map as a checklist.

FDE Complete Guide series

• Previous: The FDE Skill Map — Baselines, Working Levels, and Check Questions for 8 Domains
• Next: The FDE Incident Diagnosis Playbook — Six Steps from Access to Report