A business owner called me last year with a question I've heard a dozen times: "So if I hire one of you, what actually happens? Like, on Monday. What do you do?" Fair question. Most consulting answers involve a slide deck with a chevron diagram and the word "synergize" somewhere in the footer. This is the non-chevron version, written for people who want to know what they're buying before they sign.
The FDE engagement process looks chaotic from the outside because the engineer is sitting in your break room instead of a WeWork across town, but underneath it's a repeatable five-phase machine: scope, shadow, prototype, harden, hand off. Engagements that skip a phase fail in predictable ways. Engagements that run all five tend to end with software people actually use.
If you haven't read what a forward deployed engineer actually is, start there. This post assumes you know the species and want the lifecycle.
Here's the whole thing, phase by phase, with the weeks and the failure modes included.
Phase Zero: The Scoping Week
Before any contract, there's a walk-through. A good FDE wants to see the operation, not the pitch deck. You walk the floor, you meet the person who'll own the project, and you leave with a one-sentence problem: "Receivers can't close a truck without three systems open" or "Month-end close takes nine days because of manual matching."
If the client can't produce that sentence, the engagement isn't ready. The scoping week also produces the pilot price and the kill criteria, the explicit list of what would make both sides walk away. Writing down the failure conditions up front sounds pessimistic. It's actually the most optimistic document in the whole engagement, because it means both sides plan to succeed on purpose.
Phase One: Shadow and Map (Days 1–10)
The first two weeks, the FDE writes almost no code. Instead they sit with the people who do the work, and they map the workflow as it actually happens, not as the procedure binder claims. This is the phase that separates the model from staff augmentation, where you're handed tickets on day one. An FDE who starts with tickets is just a contractor with better marketing.
What comes out of shadowing: a process map annotated with every workaround, every sticky note, every "oh, we don't do it that way on Fridays." Plus a prioritized pain list ranked by the people who feel the pain, which is never the same ranking the executives gave you. Expect a couple of surprises that rewrite the scope. That's the phase working as designed.
A beverage distributor taught me why the pain ranking matters. The executives ranked real-time inventory as the top pain. The receivers ranked the label printer that jammed on every third pallet. Fixing the printer workflow, a barcode retry and a reprint button, saved more hours in week one than the entire inventory dashboard did in month one. Shadowing is where you catch that mismatch before it becomes three weeks of beautifully engineered irrelevance.
Phase Two: The Ugly Prototype (Weeks 2–4)
Now the code starts, and the rule is: something real in front of users by the end of week three at the latest. Not a demo environment. The actual tool, doing one thing, for actual operators. It will be ugly. The first version of a receiving tool I shipped had a button labeled "DO THE THING" because naming felt premature. Users loved it, because it saved them eleven minutes a truck.
The cadence in this phase is short loops: build two days, show the users, adjust. The users from shadowing are now your design team. Their feedback is brutal and specific, which is exactly what you want. An FDE spends this phase splitting product thinking with whoever owns the outcome client-side, similar to how the FDE and product manager roles divide the work, except the loop is measured in days instead of sprints.
Phase Three: Hardening and Rollout (Weeks 4–8)
This is the unglamorous middle where the real value gets built. The prototype proved the workflow; now it needs authentication, error handling, the edge cases the floor hits twice a month, and integrations with the systems that already exist. Hardening routinely takes twice as long as the prototype, and stakeholders get twitchy because the visible progress slows. A good FDE over-communicates here: weekly notes, honest burndown, no surprises.
The twitchiness is worth addressing head-on, because this is the phase where sponsors start asking why the exciting part stopped. The honest answer is that the exciting part was the cheap part. Making a tool survive a scanner with a cracked screen, a Wi-Fi dead zone by the loading dock, and a user who closes the browser mid-scan is the work. Nobody applauds error handling, but everybody notices its absence at 4 p.m. on a Friday.
Rollout happens inside this phase, not after it. You onboard one team, watch them for a week, fix what breaks, then expand. Training is mostly unnecessary if the tool was designed with the floor, a quick walkthrough and a laminated card by the scanner usually does it.
Phase Four: Handoff Without Drama (Weeks 9–12)
The last phase is leaving, and it deserves as much rigor as arriving. The artifacts: a runbook a tired on-call person can follow at 3 a.m., documentation of the decisions and not just the code, and at least one person client-side who has operated the system without you in the room. We call it the bus test. If your departure means the system dies, you didn't finish the job.
My runbook test is mean but useful: could the client's least technical manager recover from the most common failure at 3 a.m. using only this document? If the answer is no, the handoff isn't done. One engagement ended with a laminated card taped inside the server cabinet listing the three commands that fix 90% of issues, and that card got more use than the forty-page wiki ever did.
There's a spectrum of endings: a clean goodbye, a light retainer for a few hours a month, or a follow-on engagement for the next workflow. All three are fine. The only bad ending is the quiet fade where nobody's sure who owns the thing now.
The FDE Engagement Process at a Glance
Compress it and the whole machine looks like this: one week to scope, two weeks to shadow, three weeks to a working prototype, four to six weeks of hardening and rollout, two weeks of deliberate handoff. Call it ten to twelve weeks for a typical single-workflow engagement, with real users on real software from week three onward.
The phases overlap and the weeks flex, but the order doesn't. Shadow before you build. Ship before you harden. Hand off on purpose. Engagements that honor the sequence feel fast. Engagements that don't feel like a very expensive mystery.