(2/3) A Week in the Life of a Forward-Deployed Engineer
Ask five companies what fraction of a forward-deployed engineer's week is customer-facing and you get five answers. Palantir has historically put time-with-customer around 25%; Commure has estimated up to 50%; the job posts analyzed by Bloomberry advertise everything in between, plus travel. The number won't settle, and after running these engagements from the deploying side, I think I know why: the customer-facing share isn't a property of the role. It's a property of the week. Early weeks are heavy on people and light on code; by mid-mission the ratio inverts. Anyone quoting you a fixed percentage is describing their averages, not the job.
So instead of a percentage, let me give you the week itself. In the first post of this series I argued that 95% of GenAI pilots die in deployment, not in the model. This post is the anatomy of the alternative — what the person actually does, hour by hour, when deployment is treated as the job instead of the afterthought. I'll use our own engagements as the reference, because they're the ones I can describe without guessing.
The week that matters most happens before day one
The least visible part of a forward deployment is that it starts before the engineer arrives. In our model, the onboarding is prepared in advance: access requests filed, the repository map and the first week's plan written, the people the engineer will need named — before day one, not discovered during it. I've been the contractor who spent his first nine days waiting for a VPN token, and I've been the ops engineer watching a new arrival burn a sprint reverse-engineering an undocumented deploy pipeline. Both are normal in this industry. Both are a choice.
The reason we can prepare it is structural, and it's the part of the forward-deployed doctrine that gets ignored: the engineer is backed. Someone whose job is the engagement — in our case a delivery manager, on projects that warrant one — negotiates the accesses and the day-one plan while the match is closing. The 72 hours we quote for the match would be a vanity metric if day one landed on an unprepared runway.
Monday belongs to their standup, not ours
The defining habit of the embedded engineer: they attend the client's rituals, not the vendor's. Monday morning is the client's standup, in the client's tracker, against the client's sprint goals. Deliverables are the client's tickets. If the client's definition of done includes a runbook entry and a demo to the workflow owner, that's the definition that counts.
This sounds trivial and it is the entire difference between embedded and outsourced. The outsourced team has its own standup, its own board and its own definition of done, and reconciliation between the two worlds happens in a weekly sync — which is where context goes to die. The embedded engineer has no second world. The mechanism that makes forward deployment work is subtraction: remove the layer between the engineer and reality.
What fills the rest of Monday is rarely glamorous. Reading the incident channel's weekend backlog. Chasing the data owner who approved read access in principle but not in the IAM console. Sitting with the operations lead who actually runs the workflow the AI feature is supposed to change, and hearing what the ticket system never captures — "we skip that field because it's always wrong."
The code is the smaller half, and it's the wrong thing to maximize
Mid-week is the build: integration code, evaluation harnesses, the guardrails and fallbacks that separate a demo from a system someone will trust at 3 a.m. It's real engineering — our vetting passes 3% of candidates precisely because this part can't be faked — yet on a deployment mission, the lines of code are the smaller half of the value.
The larger half is decisions that never reach a repository. Which of the four candidate workflows to automate first, because one has a P&L line and three have opinions. Whether the legacy API's rate limit means batching tonight or a queue next month. Which failure mode gets a human fallback and which gets a hard stop. An engineer optimizing for commits would get these wrong by never noticing they were questions. This is why "how much of the week is coding" is the wrong interview question for an FDE — the honest answer is "as much as the mission needs this week," and the useful trait is judging which week you're in.
Friday's check-in is an early-warning system, not a status report
Every week ends with a check-in — two of them, and the second one is the point. One with the client: progress against the mission, blockers, the next week's shape. One with the engineer, separately: how the engagement feels from the inside. Problems surface on the engineer's side of the table one to two weeks before they show up in a standup — the scope that's quietly doubling, the stakeholder who stopped answering, the wobble that hasn't become a slip yet. When a project phase heats up, weekly becomes daily.
The cadence is also what makes the safety net honest. Our replacement guarantee — a substitute presented within 7 days, inside the first 30, at no cost — would be a lottery ticket if nobody was watching for the signal that triggers it. Guarantees are only as good as the instrumentation behind them; the check-in is the instrumentation.
The mission has an end, and the end is planned on day one
The strongest objection to everything above: isn't this just a good contractor with extra meetings? The difference is the shape of the engagement. A contractor engagement extends until someone decides otherwise, and usually ends the way a lease ends — notice given, keys returned, whatever's left in the apartment is your problem. A forward deployment is mission-scoped: the exit criteria are written at the start, and the final week is a deliverable in itself. Documentation of what was built. Working accounts handed over. Credentials closed out, with a safe delete of corporate content that an auditor could reconstruct.
I'll concede the counter-case honestly: if what you need is durable, open-ended capacity inside a team that already runs tight onboarding, weekly one-on-ones and a real leaver process, you don't need the doctrine — you need a good engineer, and plain staff augmentation will serve you fine. The arc earns its keep when the engagement is a mission — ship the AI workflow, stand up the platform, land the migration — where the ending is a certainty and the only question is whether it was designed.
What I'd ask for before any embedded engagement, ours included
- The day-one plan, in writing, before day one. If the answer is "we'll set up a kickoff call," the deployment is yours to run.
- Whose standup does the engineer attend? Any answer that includes a second, vendor-side board means reconciliation overhead you'll pay weekly.
- Who talks to the engineer when I'm not in the room, and how often? One check-in is a status report; two is an early-warning system.
- What triggers the replacement clause, and who's watching for the trigger? A guarantee without instrumentation is decoration.
- Show me the last week of a finished mission. The handover checklist, not the testimonial.
The week of a forward-deployed engineer doesn't average into a tidy percentage, and that's the tell that it's a real deployment: the mix follows the mission. What stays constant is the structure around the week — prepared before it starts, instrumented while it runs, designed to end. The next post puts numbers on that structure: what the doctrine costs, what plain capacity costs, and when each is the right purchase. And if the week I've just described is the one your AI roadmap is missing, this is the role we deploy.
