How to prepare your team for an embedded engineer

Vendors write about their own methodology. Almost nobody writes about what the customer has to do, and it decides more outcomes.

Before day one

Access, set up and tested. Repository, the data the work touches, development and staging environments, identity provider, ticketing, chat.

Tested means somebody logged in as the new person and confirmed each one works, rather than a ticket being closed. The most common cause of a slow start is an engineer sitting for four days with a laptop and no credentials, which costs exactly the same as an engineer releasing code.

If your security process cannot set up access for an external engineer in under a week, start it before the contract is signed. That is not a suggestion to weaken the process. It is a scheduling fact.

A worked example of what "tested" actually catches. A company grants a new engineer access to a data warehouse, the ticket closes, and everyone assumes it works. On day three the engineer finally tries the connection and finds the account was granted read access to the wrong schema, a copy from a project retired two years earlier. Nobody noticed for three days because nobody had tried logging in as that person. The fix took ten minutes once found. The three days it sat unfound cost more than the ten-minute fix ever could, and the only way to avoid that gap is to have somebody actually attempt the login before day one, not trust the ticketing system's own record of success.

A named person who removes obstacles. One person whose job includes answering "who owns this system" and "can I get read access to that table" within hours. Not a committee, not a shared inbox, not a rota.

A named decision-maker who can say no. This is the role people forget, and it is the reason engagements grow without control. Requests will arrive from every direction, each reasonable on its own. If nobody has the authority to decline one, scope grows by consensus and the production date keeps moving later. The vendor cannot do this for you: a vendor declining your colleague's request is a vendor creating a political problem.

What happens without this named role, described plainly. A sales lead asks for one extra field on the dashboard. A support lead asks for one extra filter. Neither request is unreasonable, and each takes the engineer half a day. By week six the system has absorbed fifteen half-days of requests that nobody weighed against the production date, and the date has quietly moved by three weeks with no single decision anyone can point to as the cause. A named decision-maker does not need to say no often. They need to exist, so that every request has somewhere to go other than straight to the engineer's task list.

The first week

Give them the real data. A cleaned-up copy hides the exact things they need to find: the nulls in a required column, the three spellings of the same category, the records from a 2019 migration with a different structure. If regulation prevents it, say so on day one and agree what the substitute is, rather than letting them discover the substitute is not realistic in week three.

Introduce the person who does the work, not only the manager who owns it. These are different people with different information. The manager knows the intended process; the operator knows the exception that covers 15 percent of cases.

Answer the production-path question honestly. They will ask what has to be true for a change to reach production, who signs each step, and how long each has historically taken. Give real durations rather than published targets. This answer sets the schedule more than the build estimate does.

Why the published target is usually wrong, and knowing that matters. A security review that is supposed to take three days often takes three weeks in practice, because the reviewer has other work and the request sits in a queue. If the embedded engineer plans against the published figure, the schedule is wrong from week one and stays wrong until the real number surfaces on its own, usually right when it costs the most to discover. Giving the real historic number up front, even when it is an uncomfortable one to say out loud, is the single most useful piece of information a customer can hand over in the first week.

Throughout

Share context, not tasks. An engineer who understands why the outcome matters makes better decisions than one working from a ticket. This is the single cheapest thing on the page and the most often skipped.

Include them fully. Daily team meetings, planning, the channels where problems get mentioned before they become tickets. People who see the whole picture catch problems earlier and take more ownership. Keeping an external engineer apart from your team is the most reliable way to get work that does not fit your team's needs.

Protect their building time. First Round Review puts the healthy split at roughly 20 percent customer-facing and 80 percent building. Your side controls this more than you think: every extra regular meeting comes out of the second number.

Read the findings. The list of things you were told that turned out not to be true is the most useful document of the first month and the one most commonly read too quickly.

Respond to the findings, do not just receive them. A findings document that gets acknowledged with a thumbs-up in a chat message and no follow-up teaches the engineer that surfacing problems does not lead anywhere, and the next findings document will be thinner and less honest as a result. Set aside real time, ideally a meeting, to go through the findings with the people who can act on them, and assign an owner to each one that needs a decision.

Name the inheritor early

Whoever will own this system after the vendor leaves should be identified when the system goes to production, not in the final week.

They attend the reviews. They see the incidents. They make some of the changes while the people who built it are still available. A system handed to somebody introduced at the end gets handed back within a quarter, as an emergency. Handover and exit covers the test that proves it worked.

If you do not have anyone to name, that is important information about whether you should be buying an outcome or building a capability. Three routes covers the choice.

What "involved" means in practice, not just in principle. It is not enough for the inheriting engineer to be copied on emails. They should sit in on the design reviews where the embedded engineer explains a decision, ask questions in those reviews rather than only afterward, and take ownership of at least one small, real piece of the system while the original team is still available to catch a mistake. An engineer who has only read the documentation has not inherited the system. An engineer who has made one supervised change to it has.

What to expect that will be uncomfortable

You will be told your data is worse than you think. It usually is. This is the finding with the highest value and the worst reception.

Somebody's process will be described accurately for the first time. Including the workaround they built and never mentioned. Handle that well, because the person who built the workaround is your best source of requirements and the easiest to alienate.

The plan will change. If a discovery process cannot change the plan, it is only for show and you have paid for a show. When forward deployed engineering is the wrong answer covers the case where the plan genuinely cannot move, in which case buy something else.

An engagement that produces no uncomfortable findings in the first fortnight has not looked hard enough. Quiet early weeks are a warning rather than a comfort.

The one-page checklist

Before day one: access tested, person who removes obstacles named, decision-maker named.

Week one: real data, the operator introduced, the production path answered with real durations.

By production: inheriting engineer named and involved.

Throughout: context shared, the person included, building time protected, findings actually read.

That is the whole customer side. It costs almost nothing and it is the difference between a deployment that succeeds and one that becomes a story about a vendor who did not deliver.