What does week one look like?
Morning: sit with the operations team at the start of their day and watch what arrives, in what form, and what happens to it. A PDF ledger. A folder of scanned applications. A queue of tickets. The engineer asks the questions a specification never answers: what happens when this field is blank, who decides when two records are the same person, what goes wrong at month-end.
Afternoon: map the workflow as it actually runs, including the workarounds. Find out which systems hold the data and who can grant access. Make a shortlist of two or three tasks where automation or AI would pay off measurably, and a longer list of things that look automatable but are not worth it. By the end of the week the engineer can describe the team's job better than the brief did.
What does week three look like?
Morning: build against live data, or a mirror of it, depending on the client's policy. The engineer is now writing the extraction, matching or generation logic for the chosen use case, with the access scoped to that task and every action logged from the start.
Afternoon: put the half-built version in front of the people who do the job and watch them use it. This is where most of the real design happens. The analyst points out that the number in the third column is always wrong on Fridays. The agent explains why a confirmation has to go to two numbers for some clients. The engineer changes the system that evening. By the end of the pilot, the working version has been shaped by the people who will use it, which is why it gets used.
What does a day after launch look like?
Morning: check the monitoring. Did last night's run complete? Anything flagged for human review? Any inputs the system could not read with confidence? Handle the exceptions, or confirm the team handled them.
Afternoon: improve. A new document format from a supplier. A request to extend the pipeline to a second report. A threshold that is too cautious. The engineer who built the system makes the change, because they understand why it was built the way it was. At FetchSky this stage is a retainer; every client moves onto one after delivery, with the builder still on the rota.
What is the job not?
It is not sitting in a room building from a document and emerging six months later with a demo. It is not configuring one vendor's product. And it is not attending meetings about the work instead of doing it. The defining feature of the role is proximity to the problem, and a forward deployed engineer who is never near the operations team is not one. See forward deployed engineers for how an engagement is structured, and the engineering partner guide for the alternatives.
Frequently asked questions
How much of the job is coding?
Roughly half, averaged over an engagement. Less in week one, more in the build weeks, and a steady share after launch.
Does the engineer work on site?
Often in the first weeks, where it helps most. Remote embedded work in the client's hours is common afterwards.
Who does the engineer report to?
Day to day, the client's sponsor. Technically, their own firm, which provides specialists when needed.
What does the engineer do when the pilot shows the idea will not work?
Says so, with the evidence. A pilot that ends with "stop" after six weeks is a good outcome.