The decision to bring in an embedded engineer gets a lot of thought. The first week gets almost none, which is backwards, because week one is where the arrangement is actually decided. A strong engineer with no access and no context looks identical to a weak one for about ten days, and by then opinions have formed.
This is the checklist I would want on the other side of the table.
Before they start: access, or the week is gone
Access requests take longer than anyone plans for, and they are sequential, which is what makes them expensive. Repository, cloud console, CI, the ticket tracker, staging data, the design files, the internal chat, the VPN if there is one, and whatever single-sign-on gate wraps all of it.
Start this a week before day one. Not the day before, because the person who approves the third item is usually on holiday.
Threshold worth holding yourself to: if a new engineer cannot run the application locally and open a pull request by end of day two, the problem is your onboarding, not their ability. That is also the cheapest thing on this list to fix permanently, because every future hire benefits.
The context that actually matters
Not the org chart. Three things:
What the product does for whom, in two minutes. Said by someone who talks to customers, not read off a deck.
The current priority and why. One sentence. If nobody can produce it, that is worth knowing on day one rather than week four.
The map of the codebase's ugly parts. Where the legacy is, what nobody touches, which service surprises people. Every team has this knowledge and almost none of it is written down. Twenty minutes at a whiteboard saves a week of archaeology.
Give them something real on day one
The instinct is to start with a tiny throwaway task to be kind. It backfires. Trivial work produces no signal for you and no context for them.
Give them something small but genuine: a real bug with a real reporter, or a contained feature with a visible outcome. Small enough to finish inside the week, real enough that finishing it teaches them the deployment path, the review culture and where the tests live.
Deliberately include one ambiguity. A good engineer asks; a weaker one guesses. That single observation tells you more than any interview loop, and it is the same diagnostic worth using when you vet a development partner in the first place.
Name the one person they can interrupt
Every embedded engineer needs a designated human whose job includes answering their questions this week without irritation. Not the whole team, because diffuse responsibility means asking feels like an imposition, and an engineer who stops asking starts guessing.
Say it out loud on day one, to both of them. It costs the buddy maybe two hours across the week and is the highest-return two hours in the whole arrangement.
Distributed teams: make the overlap real
If the engineer works from another timezone, the overlap window is the whole ballgame. Two rules.
Put the overlap in the calendar as a recurring block rather than an intention, and use it for the things that genuinely need synchrony: decisions, unblocking, review discussion. Status does not need synchrony and should be written.
Then write more than feels necessary. Distributed teams that document well outperform co-located teams that do not, and the cost advantage of a distributed bench evaporates entirely if every question needs a live call to resolve.
What to measure by Friday
Not lines of code. Four signals, and you will have all of them by the end of week one.
- Did they ship something real? Merged and deployed, however small.
- Did they ask good questions? Specific, researched, arriving before the guess rather than after.
- Did they surface anything you did not know? Fresh eyes find things. Silence in week one is a mild worry.
- Would the buddy want them back? The most predictive question on the list, and the one people forget to ask.
If three of those four are yes, you have a working arrangement and can scale it. If two or fewer, deal with it now. That is precisely what a replacement window is for, and quietly hoping week three is better is the expensive path.
What this means for your team
- Treat access as a week-long lead item, not a day-one task. It is the single most common reason a first week is wasted.
- Fix the local-setup path once. Every subsequent engineer, employee or embedded, gets the benefit.
- Give real work immediately, with one deliberate ambiguity in it.
- Name the buddy out loud. Two hours of someone's week buys most of the ramp.
- Judge at Friday, not at week three. Early honest signals are what a replacement guarantee is for.
We publish a 72-hour shortlist, a first sprint inside 14 days and a replacement within 30 if the fit is wrong, and that last promise only works if you actually evaluate early. If you want to see how the first week would run against your codebase, tell us what the work looks like. If you are still weighing whether to hire instead, what an open senior role really costs has the arithmetic.