The Embedded Delivery Model

The premise: build software where the work happens

In a normal engineering job, the work happens at your desk. Tickets arrive, you write code, you push it, and somewhere downstream a customer presumably benefits. The feedback loop from customer to engineer is mediated by PMs, support tickets, NPS surveys, and sales calls. It is months long, and most of the signal is lost in translation.

FDE work inverts this. The work happens at the customer’s desk — literally. The FDE sits in the dispatcher’s office and watches the dispatcher work. The feedback loop from customer to engineer is zero hops and minutes long.

That single change — the physical proximity, the unmediated feedback, the customer in the room when you ship — is the engine of the FDE model. Everything else is downstream of it.

Why proximity matters more than you think

You can read a thousand pages of documentation about a logistics company and still not know that the dispatcher always has a paper printout taped to the side of her monitor with the names of the three drivers she doesn’t trust. You will not learn that fact from a Jira ticket. You will not learn it from a Zoom call. You will learn it when you sit next to her for four hours and notice she keeps glancing sideways.

The interesting domain knowledge is tacit. It lives in habits, in workarounds, in the things nobody bothered to write down because everyone already knows. The only way to extract tacit knowledge is to be there when it is being used.

This is the deepest justification for the embedded model:

The information needed to build the right system is not in any document. It exists only as observed behavior, and only an embedded engineer can observe it.

A spec written by someone who has never sat with the dispatcher will optimize for the wrong things. An FDE who has spent two days next to her will model the system around the three drivers she does not trust — because that constraint is the constraint shaping her real workflow.

The mechanics of being embedded

“Embedded” is not just a vibe. It is a specific operating mode with specific rituals.

Site visits

An FDE engagement typically opens with one or two weeks on-site, then settles into a cadence of recurring multi-day visits. The pattern varies by customer:

• High-stakes / classified work (defense, intelligence) — often full on-site for months. You badge in, you work behind their firewall, you go home at the end of the day.
• Enterprise commercial — a typical pattern is 3 days on site, 2 days remote, every other week.
• Pure on-prem deployments — first 4–6 weeks fully on site, then transition to remote with occasional visits.

The first week is rarely about writing code. It is about getting in the room — learning where people sit, who has lunch with whom, which conference room has the projector that actually works.

Sit-alongs

The single most valuable hour of an FDE’s week is a sit-along — pulling up a chair next to an operator and watching them work for 60 to 90 minutes without interrupting except to ask clarifying questions.

Things you will learn in a sit-along that you cannot learn any other way:

• Which screens they alt-tab between most often
• Which fields they always copy from one system to another (a screaming sign that you should automate the copy)
• Which alerts they have learned to ignore
• Which steps make them sigh
• Which steps they actively fear

A senior FDE will do 5–10 sit-alongs in the first two weeks of an engagement, with different roles, across different shifts.

Standups with the customer

You do not run an internal standup that the customer hears about secondhand. You run a joint standup that includes the customer’s relevant team members. Two reasons:

1. They tell you about real-world events you would miss (a driver quit, an SAP outage, a new contract starting Monday).
2. They watch you make progress in real time, which builds trust.

Demo Fridays

The closing ritual of the week is a demo to the customer’s stakeholders. Even if what you have to show is ugly. Especially if what you have to show is ugly — early demos of imperfect work are the fastest path to alignment, because the customer can see what you have understood about their problem and what you have not.

A good Demo Friday includes:

• 15 minutes of “here is what we built this week”
• 15 minutes of “here is what surprised us / what we learned”
• 15 minutes of stakeholder reactions and direction-setting
• A clear ask for next week

Skip Demo Fridays at your peril. Customers who do not see weekly progress assume there is none.

Office hours

A simple but underused ritual: park yourself in a public area of the customer’s office (a kitchen, an open desk, a conference room with the door open) for 1–2 hours a few times a week. Operators will wander in with questions they would never file a ticket about. Some of those questions are the seeds of the next thing you should build.

What this looks like on the FDE’s calendar

An honest week for an embedded FDE early in an engagement:

There is very little uninterrupted heads-down time. That is by design — the role is bandwidth-bound by conversations, not by code.

Why remote-style delivery fails for this work

You will be tempted, especially in a remote-friendly era, to push back on the on-site requirement. Many FDE engagements have indeed gone partially remote. But for new engagements with new customers solving unfamiliar problems, remote-first delivery has predictable failure modes:

1. You miss the tacit knowledge. No video call shows you the paper printout taped to the monitor.
2. You build to the spec, not the workflow. Specs are written by the customer’s stakeholders, who themselves do not know the workflow as well as their operators do.
3. Trust is slower to build. Trust is built by being seen working hard on the customer’s behalf. Hard to do over Slack.
4. Politics surface late. The IT director who is quietly going to block your deployment will be polite on Zoom and explicit in person. You want to find out in week 2, not week 10.
5. Demos lose their force. A demo in a conference room with eight stakeholders, with the dispatcher in the front row, is dramatically more persuasive than a screen share.

The right rule of thumb: embed in person for discovery and the first MVP; go hybrid for build; visit in person for deployment and adoption.

The customer’s experience

It is worth understanding what your embedded presence feels like to the customer. Customers do not always love it at first. The dispatcher does not know who you are. The IT director suspects you are auditing them. The procurement officer is annoyed you have a desk in their building.

Your job in week 1 is to:

• Be obviously useful to at least one operator
• Be obviously not a threat to anyone’s job
• Be specific about how long you are staying and what you are trying to accomplish
• Be respectful of customer norms — their building, their pace, their lunch hour

By week 3, with most healthy engagements, you have become “our FDE” — the customer talks about you in the possessive. That is the signal that the embedding has worked.

Anti-patterns to watch for

A few common ways the embedded model goes wrong:

• Going native. You start advocating for the customer against your own company. (You should be honest with both, but you are still your company’s representative.)
• Becoming the help desk. The customer asks you to fix their printer. Set a polite, firm boundary.
• Hoarding context. You learn things that your back-home colleagues need to know and never tell them. Write public notes.
• Building without showing. Two weeks of heads-down with no demo = a customer who has lost confidence in you.
• Optimizing for your comfort. Working from the hotel because the customer’s office is loud. Don’t. The office is where the signal is.

Preparing for your first on-site week

If you are about to do your first on-site engagement, prepare:

1. Pack a clean laptop. Many customers will require corporate device controls; some will not let you on their network at all and will issue you a customer laptop.
2. Read everything publicly available about the company. 10-Ks, press releases, glassdoor reviews, the LinkedIn profiles of the people you will meet.
3. Practice a one-minute self-introduction. Who you are, what you do, why you are there, how long you will be around.
4. Pre-write your week 1 questions. You will not remember them in the moment.
5. Have a notebook. Paper. People talk more openly to a person with a notebook than to a person with a laptop.

Key terms to remember

• Embedded engagement — the operating model where the FDE works at the customer’s site, not remotely
• Sit-along — observing an operator at work without interrupting
• Joint standup — daily standup that includes customer team members
• Demo Friday — weekly demo to the customer’s stakeholders
• Office hours — open, unstructured time available to anyone at the customer

What’s next

You understand the role and how it is delivered. Next we will dissect the FDE deployment loop — the weekly rhythm of discover → prototype → deploy → measure → iterate that turns embedded presence into shipped systems.