Placing an engineer inside a client's team is the oldest model in consulting, and the easiest to do badly. The first quarter almost always goes fine: the engineer is new, motivated, and working through a backlog someone else groomed. The test is the second year. Most of our embedded engagements run beyond a year, several have run much longer, and the ones that last share some unglamorous habits.
The stack requirement is the easy half of the brief. Anyone can match a résumé to a technology list. What decides whether an embedded engineer is still valuable in month eighteen is judgement about the product: knowing when to push back on a ticket, when a shortcut will be paid for later, and when something outside their lane is about to become their problem.
When Switch Automation's VP of Engineering described our people as thinking beyond the code, about the product and the end user, that was the selection criterion working, not a lucky placement. We turn down placements where the fit is stack-only, because those are the ones that stall after the honeymoon.
An embedded engineer who works through a separate task list, reports through their consultancy, and appears in standups as a guest is a contractor with extra steps. The model works when the engineer is in the client's standups, the client's codebase and the client's on-call conversation, reviewed by the client's leads against the client's standards.
That sounds like the consultancy disappearing, and to a first approximation it should. What remains behind the scenes is the part clients do not see: someone senior checking in on the engagement, a bench of colleagues the engineer can pull on when a problem is outside their depth, and a replacement path if life intervenes. The engineer is embedded; the firm is still accountable.
The economics of embedding only make sense over time. Months one to three, the engineer is learning your domain on your budget. The return arrives in the long middle, when the same person who built the feature is the person maintaining it, and context that would take a new hire months to acquire is simply present.
Which is why churn is the model's failure mode. A consultancy that rotates embedded people every six months is selling you the expensive first quarter on repeat. Ask any firm offering embedded engineers one question: what is your median engagement length? The answer tells you whether they run the model or just advertise it.
Honesty requires the other half. Embedding fits when a team needs one deep capability it lacks: a senior engineer in a specific stack, an X++ developer inside an ERP programme, a platform engineer while you hire your own. It does not fit when there is no team to embed into, or when the real need is an outcome delivered end to end. Those cases want a dedicated squad or fixed-scope delivery, and pretending otherwise wastes everyone's year.
Marcel Rizzolo is Director of Coder Trove. The embedded model is described alongside our other engagement structures on the custom software practice page, with a working example in the Switch Automation case study.