The badge said VISITOR in letters you could read from orbit. It also, the security guard informed me, had to be worn "above the waist, clip facing out," which is how I spent my first morning at a regional food distributor learning that lanyards have rules. By lunch I had toured a freezer the size of my apartment, learned that the pickers called the old scanner software "the brick," and found the actual reason orders ran late. It was not the reason in the kickoff deck.
That is the job. An embedded engineer working onsite with clients is not a consultant who occasionally visits; the visiting is the work. The software you need to build lives in the gap between how people describe their process and what they actually do at 6 a.m. when a truck is idling at the dock, and that gap is only visible from a plastic chair next to the label printer.
Here is the short version. Working onsite with clients means embedding where the work happens so you can watch real workflows, earn the trust of the people who will use your software, and catch requirements that never survive into documents. Expect plant tours, dress codes, and two to four onsite days a week early in an engagement. The proximity is not overhead. It is the discovery mechanism.
An Embedded Engineer Working Onsite With Clients Sees the Real System
Every company runs two systems: the one in the process diagram and the one in the break room. The process diagram says invoices go from inbox to approval to payment. The break room version involves Carol, a spreadsheet named FINAL_v7_real.xlsx, and a ritual nobody has questioned since 2019. Remote work gets you the first system. Being there gets you the second one, and the second one is what your software has to survive.
This is the core premise of what a forward deployed engineer actually is: the deployment is forward, into the client's building, because that is where the requirements are hiding. Video calls are fine for status. They are terrible for noticing that the warehouse supervisor keeps a laminated cheat sheet taped over the official instructions, which means the official instructions are fiction.
Say you are rebuilding an order-entry flow. On a call, the ops manager walks you through the happy path in nine tidy steps. Onsite, you watch a rep handle a real order and count seventeen steps, four of which exist because of a pricing edge case from a customer who left three years ago. No document was ever going to tell you that. The building did.
Take the Tour Like You Mean It
Week one onsite almost always includes a tour, and most engineers waste it by treating it as a courtesy. It is not a courtesy. It is the cheapest user research you will ever get, and it contains a dress rehearsal of every problem you will spend the next three months solving.
Follow the physical flow of the thing the company makes or moves. If it is a distributor, walk the path of a pallet from dock to shelf to truck. If it is a clinic, trace a patient's paperwork. Ask the questions that feel dumb, and ask them loudly enough that people can correct you: "Wait, you scan it twice?" Somebody will say "oh, that's because of the Henderson account," and you will learn more in that sentence than in the entire stakeholder interview schedule.
Take notes where people can see you taking notes. It signals that their answers matter, and it gives them permission to keep talking. The engineer who glides through the tour nodding and then vanishes into a laptop gets the tour version of the truth forever.
Earning Trust on the Floor
The people who will use your software have been burned before. Some vendor, some internal team, some well-dressed person with a gantt chart promised them a system and delivered a login screen that added forty minutes to their day. You arrive pre-distrusted, and no amount of technical brilliance fixes that. Only usefulness does.
I call it the thermometer rule: fix one small, real, annoying thing in your first week, the way a thermometer proves it works before anyone trusts the forecast. At the food distributor, the receiving team re-typed carrier reference numbers from emails into a tracking sheet, roughly ninety times a day. I wrote a scrappy little parser that pulled the numbers automatically. It took an afternoon. It saved them an hour daily, and more importantly it bought me the right to ask naive questions for the rest of the engagement without anyone checking my badge.
Learn names fast, including the night shift and the people who are not in any meeting you will ever attend. And be honest about the job title, because "forward deployed engineer" means nothing to a forklift driver; the FDE title problem is real, and "I'm the person making the scanner thing less awful" is a better introduction than any job description.
Dress Codes, Badges, and Hairnets
Match the environment, not the consulting brochure. If the floor wears steel toes, you wear steel toes. If the office is polos and lanyards, the blazer you packed reads as a costume, and so does the startup hoodie. The goal is to be visually boring so the interesting thing about you is that you listen and ship.
Yes, this includes the hairnet, the safety glasses, the escorted-only zones, and the sign-in tablet that makes you watch a six-minute safety video on every single visit. Watch the video. Every site ritual you comply with cheerfully is a small deposit in the trust account, and every eye-roll is a withdrawal you cannot afford.
The Onsite-Remote Math
Being onsite is expensive, in travel and in your own deep-work hours, so treat it as a budget with a purpose. A cadence that works for a lot of engagements: three to four days a week onsite for the first two or three weeks while you map the real system and build trust, then taper to one or two days once you are shipping, with remote weeks for heavy build sprints where you need silence more than hallway intel.
Be honest with the client about this math. They are often paying for your travel, and "I will be there Tuesday and Wednesday" lands better than a vague promise of availability. It also creates a rhythm: onsite days are for watching, asking, and demoing; remote days are for building. When a client understands that split, they start saving their best questions for your onsite days, which makes those days worth the flight.
Mistakes That Burn Bridge Time
Conference-room camping is the classic failure mode: technically onsite, functionally remote, sitting in a booked meeting room on the same video calls you could have taken from home. If your laptop never leaves the conference room, you are paying travel prices for a webcam.
The second is clipboard consulting: interviewing people like you are writing a report about them instead of building for them. FDEs ship outcomes, not assessments, and the outcome-based engineering mindset applies doubly onsite, where every hour of watching should end in something shipped or something decided.
Third, promising features on day one. The floor will pitch you forty ideas by Wednesday, all of them reasonable. Write them down, rank them later, commit to nothing before you understand the system. And do not ignore the night shift; if the process runs twenty-four hours and you only ever see nine of them, you have built software for a company that does not exist.
The building is the documentation. Show up, comply with the lanyard rules, fix something small fast, and the rest of the engagement gets easier every single week.