The feature request was a "Q3 roadmap item." A regional logistics client needed their dispatch screen to flag loads likely to miss their delivery window, a call the ops team made by eye at 4 p.m. daily. Their estimate said a quarter, because that's what roadmap items cost.
An embedded engineer shipped it Thursday afternoon. Four days. Same company, same data, roughly the same code anyooe would write. The ops lead reacted with delight, then suspicion: if this was four days, what had the last eighteen months of estimates been?
The client's team wasn't slow. Their context was. Why embedded engineers ship faster has almost nothing to do with talent and almost everything to do with collapsing the distance between the person with the problem and the person writing the code. Same engineer, different physics. The mechanics are below, and most of them are stealable without hiring anyone.
The Four-Day Feature
Reconstruct those four days and nothing magical appears. Monday: sit with dispatchers, watch them eyeball the board, learn that "miss the window" really means three different situations, only one of which they care about. Tuesday: wire drive-time data into a query against the load list. Wednesday: put a rough version on one dispatch screen and watch a real dispatcher use it wrong in an interesting way. Thursday: fix the interesting ways, ship it, buy coffee.
No breakthrough happened. What happened is that every delay the traditional process inserts between those steps got removed, one by one. That's the whole secret. Speed lives in the gaps between the work, and embedding is a systematic way of closing the gaps.
Why Embedded Engineers Ship Faster: It's Context, Not Talent
The uncomfortable truth for anyone who's sat through a three-month estimate: the actual coding in most business software is a small fraction of the calendar time. The rest is waiting. Waiting for requirements to be written down, waiting for approval, waiting for clarification, waiting for the next sprint, waiting for a review board that meets every other Thursday.
Do the calendar math on a four-hour task in a normal queue. It waits for ticket grooming, which meets Tuesdays. It misses the sprint cutoff by one day, which costs a week. It waits for a review board that convenes every other Thursday. Four hours of work, three weeks of calendar, and nobody in the chain was lazy or careless. The queue just charges rent on every handoff, and the rent compounds.
An embedded engineer doesn't code faster. They wait less, because the environment removes the reasons to wait. The user is ten feet away. The data is already understood from yesterday's shadowing. The approval is a conversation with the person who has the problem. Put the same engineer back in the ticket queue and they'll slow to the speed of the queue, because speed was never a property of the person. It's a property of the distance.
No Telephone Game
Watch a requirement travel the traditional path. The dispatcher says "flag loads that might be late." The ops manager translates that into a feature idea. The PM translates it into a ticket with acceptance criteria. The engineer reads the ticket, which by now says something like "display ETA warnings," and builds exactly that, and it's wrong, because "late" meant "late for the window the customer was promised," not "late per the GPS," and nobody wrote that down because nobody along the chain knew it mattered.
Each hop costs half the truth. The FDE's version of this process is standing next to the dispatcher at 3:50 p.m., watching them squint at the board, and asking "which of these would you actually call the customer about?" The answer to that question never survives the telephone game, and it's the difference between software people use and software that gets demoed once and dies. Cutting scope ruthlessly, as we cover in cutting MVP scope without killing the product, only works when you know what the scope actually is, and that knowledge lives at the user's desk.
Permission to Be Imperfect
Internal teams carry an invisible tax: everything they ship is presumed permanent. So the architecture committee reviews it, the security review schedules it, and the design system absorbs it. Most of that caution is rational for software that will serve ten thousand users for five years. It's suffocating for a workflow fix that serves twelve people and might change next quarter.
Embedded work runs on a different deal: ugly but running Friday, polished next week, replaced without ceremony if it turns out wrong. That deal has to be made explicitly, with the client, up front. When it is, the speed gain is absurd, because you're no longer paying the permanence tax on provisional things. The rapid prototyping playbook is essentially this deal turned into a method.
The Feedback Loop at Zero Distance
The deepest speed mechanism is the feedback loop, and how short you can make it. In a normal process, feedback travels the same telephone line as requirements: user mentions issue to manager, manager files ticket, ticket waits for sprint, fix ships weeks later, user has long since built a workaround and stopped caring.
Onsite, the loop looks like this: demo at 10 a.m., complaint by 10:15, fix by lunch, second demo at 2. A month of sprint-cycle feedback compresses into a day, and the feedback is better, because "I watched her hesitate on that button" is information no ticket has ever contained. Twenty loops in a week means the software gets tuned to the actual workflow while everyone still remembers building it.
I once timed both loops on the same kind of complaint, two different teams. Ticket-queue version: 23 days from "this screen is confusing" to deployed fix. Onsite version: one morning, including the argument about where the button should go.
What You Can Steal Without Hiring Anyone
None of this requires an embedded engineer. It requires deciding to act like one:
- Sit next to the user. Physically, for a day, before writing a line of code. Watch the actual workflow, not the documented one.
- Cut one approval. Pick the review step that exists out of habit rather than risk, and route this one project around it. See if the building falls down. It won't.
- Ship the ugly version to five friendly users. Not to everyone, not as a big launch. Five people who know it's rough and will tell you so by lunch.
- Schedule the demo first. A Friday demo for real users focuses a week of building better than any sprint ritual, which is the whole premise of demo-driven development.
The four-day feature wasn't a miracle. It was what normal engineering looks like when you stop paying taxes you forgot you were paying. The taxes have names: distance, telephone, permanence, delay. Remove two of them and your roadmap items start shipping on Thursdays too.