There's no shortage of writing about what a forward deployed engineer is. There's almost none about what you should actually do in your first week inside an account.
This is one opinionated version. It's not the only one, and if yours differs I would rather read yours than defend mine.
Week one — access and the real map
Two jobs, and neither of them is code.
Start the access conversation on day one. Not when you're blocked — day one. Every credential, VPN profile, repository permission, data-warehouse role, and environment you will plausibly need in the next three months. It will take longer than anyone tells you, the request will be rejected once for a formatting reason, and the person who approves it is on leave. Beginning this in week three is the single most common self-inflicted delay in this job.
Draw the real map. Not the org chart. Ask three separate people to describe the current process and note where the descriptions diverge — the divergence is the interesting part. Find out who has to change their behaviour for this to work, and whether anyone has asked them. Find out who lost an argument when this project was approved. That person isn't your enemy, but they're a fact about your environment, and you would rather meet them in week one than week nine.
The question that consistently produces the most useful answer: "What did the last team who tried something like this get wrong?" People will tell you, at length, and it's usually the whole brief.
Weeks two to four — something visible, deliberately small
Ship something real, small, and visible before the environment is ready.
This feels wrong to good engineers. The foundations aren't laid, the data is a mess, the proper design is obvious and this isn't it. Do it anyway.
The reason isn't technical. A deployment is a political object inside the customer's organization, and it has sponsors whose credibility is attached to it. Every week without something to point at, that credibility erodes and the sceptics get quieter and more effective. A crude working thing in week three buys you the runway to build the real thing in week nine.
Pick something that touches genuine data, produces an output a non-engineer recognises, and that you're willing to throw away. Say out loud that you'll throw it away, so nobody mistakes it for the architecture.
Weeks four to eight — find the real problem
By now you know enough to tell whether the stated problem is the actual one. Frequently it isn't.
The request arrives as a solution. "We need a dashboard." Nobody wants a dashboard. They want to stop being surprised at the Monday meeting, and there are five ways to do that, of which a dashboard is the most expensive and the fourth most effective.
This is where the job is either done well or done expensively. Reframing isn't the same as refusing. The form that works: "Here's what I understand the underlying problem to be. Here's a smaller thing that addresses it, and here's what we wouldn't build. Have I got the problem right?" You're asking them to correct your understanding, not to admit they were wrong, and those land very differently.
Expect this conversation to be uncomfortable and expect to be right less often than you think. Sometimes the dashboard really is the answer because a VP needs to show it to a board, and that's a legitimate requirement even though it's not a technical one.
Weeks eight to twelve — build the thing, and build the exit
Now build properly, and build for a world without you.
The measure of a good deployment isn't that it works while you're there. It's that it still works six months after you leave, operated by people who don't have your context. That means the boring things: runbooks, sane failure modes, someone on their side who knows how it works, and a deliberate decision about what stays bespoke and what should go back to your product team.
That last one is the part that distinguishes this role from consulting. Somewhere in these ninety days you built something for this customer that four other customers will need. Say so, with evidence, in a form your product team can act on. If you don't, forward deployment is just contracting with a better title.
The failure modes
Building before mapping. You'll build the right thing for the wrong department.
Waiting for the environment. The environment is never ready. Ship something anyway.
Accepting the stated problem. You'll deliver exactly what was asked for and watch it go unused, and everyone will be too polite to tell you why.
Going native. Six months in, you know their systems better than your own product and you're arguing their side in internal meetings. Some of that's the job working correctly. Past a point it means the loop back to product has stopped, which is when you've become an expensive contractor without noticing.
Never leaving. If nobody on their side can operate it, you haven't finished. You've just become load-bearing.