What a forward-deployed engineer actually does all day

What a forward-deployed engineer actually does all day usually starts with them not touching a keyboard.

Week one is shadowing. You sit next to the people who do the work — reps filling in field reports, operators walking the floor between units — and you say almost nothing. You are not there to pitch a solution. You are there to find out where the friction actually is, which is rarely where the client thinks it is. A stakeholder tells you the bottleneck is the software. The person doing the job tells you, without meaning to, that the bottleneck is a form nobody designed for how the job actually happens. Those two answers are usually different, and only one of them is useful.

This is also where you find the constraints that never make it into a deck: who actually has access to which system, what data exists versus what people assume exists, what happens when the network drops in the field, what a manager will and won't let you change on day one. None of this is glamorous. All of it determines whether anything you build later survives contact with the operation.

By week two you're mapping the business, not the codebase. In a business with several interlocking operations — procurement feeding production, production feeding a byproduct stream, that byproduct feeding another line entirely — you can't design around one piece without understanding what it does to the others. You walk the floor. You ask the same question to five different people and note where their answers disagree, because that disagreement is usually the real process, not the documented one.

Then the plumbing starts, and it takes longer than anyone outside the project expects.

• Getting read access to systems that were never meant to be integrated
• Figuring out who owns a spreadsheet that's secretly load-bearing
• Building the boring intake — a check-in app, a data pipe, an auth flow — before any model touches anything
• Reconciling what a system of record says against what people on the ground say, and finding out the ground is usually right

This is most of an engagement's actual hours, and it's the part almost nobody sees in a case study. If field reps are logging visits by memory at the end of the day, you don't start with a model — you start with making the input trustworthy: GPS-verified check-ins, so what gets recorded is what happened, not what someone remembers happening six hours later. If a plant's procurement and process-control systems don't talk to each other, you don't start with a forecasting layer — you start with getting them to agree on the same numbers.

Only once that foundation exists does the AI part show up, and by then it's often the easiest step. The daily reporting that took a rep close to an hour turns into fewer than ten minutes once the input is structured and half the fields fill themselves in. Multiply that across five hundred reps and you get several hundred hours of selling time back a day — not because the model is clever, but because the plumbing underneath it stopped fighting the person using it.

The last stretch is adoption, and it's where a lot of embeds quietly fail elsewhere. You don't hand over a system and leave. You watch people actually use it, fix the thing that's annoying but wasn't in the spec, document the parts of the system that live only in your head so they don't stay there. An engagement built strategy-to-production in eight weeks is worth nothing if the client can't run it without you in week nine — so ownership, end to end, fully documented, is the actual deliverable, not a footnote to it.

None of this matches the popular idea of an AI engineer as someone who mostly trains or prompts models. Most of the week is listening, then wiring, then handing off. The modelling is real but small. That's also why MarsLab's own process front-loads a working session before any commitment — going through where the data lives, who touches it, what it costs today — because if that session doesn't turn up a measurable delta, the honest answer is to say so, not to build something anyway.