Forward Deployed Engineer is a title with a lot of consultancy sludge attached to it, so it is worth saying what it is not. It is not an account manager with a laptop. It is not a solutions architect who visits. It is not a delivery lead who translates between your team and an offshore one. It is a senior engineer who sits inside your team, writes code in your repository, and is measured on whether your thing works.
What follows is the shape of the first week. It is deliberately unimpressive. The impressive weeks come later, and only if this one is done properly.
Monday morning: access, and what it tells you
The first task is access, and the time it takes is the most honest diagnostic available about an engineering organisation. If a laptop, an SSO account, a repository grant and a non-production database credential take nine days, that fact is the story of the engagement, and it is better to say so on day one than to discover it on day thirty when the schedule slips.
So we ask for a specific, short list before the start date, and we ask for a named human who can unblock it:
- Read access to the repositories in scope, and to CI.
- Deploy access to one non-production environment.
- A seat in the standup, the team channel and the incident channel — the incident channel matters more than the standup.
- Whatever runbook exists, however out of date. The gap between the runbook and reality is a finding.
- The last three months of the incumbent product's audit log, and the last invoice.
- One named person with the authority to unblock any of the above within a day.
If several of those are impossible, that is not a reason to cancel. It is a reason to change the first two weeks from building to unblocking, and to say that out loud in the Friday note.
Monday afternoon: ship something trivial
The bar for day two is a merged pull request. It does not have to be a good pull request. A typo in the README counts. A missing null check counts. The point is not the change; it is that the path from a laptop to production has been walked end to end by somebody new, while there is still time to fix what is broken about it.
This finds things. It finds the CI secret that only exists on one engineer's machine, the review rule that requires an approver who is on leave, the deploy script that assumes a VPN, and the test suite that has been red for six weeks and everyone has learned to ignore. Every one of those would have cost a fortnight in month two. In week one they cost an afternoon and a conversation.
Tuesday: read the invoice and the audit log
Most engineers never see the contract for the software they are replacing. That is a mistake, because the contract explains the design. A per-seat licence tells you why viewer access is rationed. A per-host observability bill tells you why nobody instruments the batch jobs. A per-ticket support licence tells you why there are four shared logins.
So Tuesday is spent with two documents: the invoice and ninety days of audit log. The output is a ranked list of capabilities with a headcount against each, and the beginnings of the parity matrix — starting with the rows where the honest answer is going to be no.
Wednesday: sit with the people who use the thing
Not a workshop. Three or four conversations of forty minutes, at the desk of somebody who uses the incumbent daily, watching them do their actual work rather than describing it.
This is where the log stops being enough. The log records that someone created 40 items on a Monday morning. Only the person can tell you that they do it by hand every week because the import broke in 2024 and they never raised a ticket. That workaround is a requirement. It will not appear in any document produced by the vendor or by the client's own architecture team, and it is frequently the single most valuable thing learned in week one.
Thursday: the first architecture decision record
One page, in the client's repository, in their format if they have one. The first ADR is almost always dull — the data store, the authentication path, or where this system sits relative to their existing landing zone. Dull is correct. The purpose is to establish, in week one, that decisions get written down, dated, and argued with in a pull request rather than settled in a meeting nobody minuted.
The second purpose is a handover artefact. We write the handover from day one rather than day last. An engagement that ends with a knowledge transfer session has already failed; the knowledge should have been transferring continuously, in reviewable text, since the first Thursday.
Friday: a number and a date
The week ends with a note of about one page, sent to the sponsor and the team at the same time. It contains: what we are replacing and for whom, the capabilities ranked by actual usage, the parity rows that are already known to be no, the infrastructure cost estimate against their own cloud account, a build estimate in engineer-weeks, and a date.
The date will be wrong. It is a week-one date. It is written down anyway, because a wrong date that moves visibly is management information and a missing date is not.
What we deliberately do not do in week one
- No current-state document. Nobody reads them, they are stale on delivery, and producing one is how a consultancy bills a month before writing code.
- No opinions about the client's language, framework or branching strategy. We work in what is there. Changing it is a decision for month three, with evidence, if at all.
- No reorganisation of their repository, their tickets or their standup format.
- No promises about anything we have not costed, and no estimate without its assumptions attached.
- No new tooling introduced in week one, including ours.
What good looks like from the client side
By Friday of week one, the client should be able to point at a merged commit, an ADR, a ranked capability list, and a cost model with the arithmetic shown. They should also be able to name at least two things we have said we will not build.
And they should know that the engineer will still be there in week twelve. That is the part of the model that is hard to fake and expensive to run: the same named person, not a rotating bench, in the standup and in the on-call rotation, replaceable on two weeks notice in either direction.
An FDE is not the person who explains the plan. They are the person whose name is on the pull request.
None of this requires unusual talent. It requires that the engineer is senior enough to be trusted with a client's repository in week one, and that the firm is structured so that nobody is incentivised to spend the first month producing documents. Those two things are most of what the role is.
Prices quoted here are vendor list prices with the date we checked them. If a figure has gone stale, tell us and we will correct it — support@conseiltek.com.