Most remote onboarding is a laptop, a wiki link, and fourteen 30-minute intro calls. Three months later the engineer still DMs their manager to ask who owns the billing service. There is a cheaper fix almost nobody schedules on purpose: make the new hire’s first day the first day of your company offsite.
TL;DR
- The first five days set the trajectory for the next ninety. Whatever mental map of the org a remote hire builds in week one is the map they use all quarter.
- Flying an engineer from Bogotá, Lima or Mexico City to a US summit runs roughly $600-1,200 all-in (flight plus 3-4 nights of hotel). That is less than one week of a mid-level engineer’s fully loaded cost.
- The offsite buys the thing async onboarding never delivers: tacit context and a face-to-name index of who to ask.
- Design the agenda around people, not presentations. Cap structured content at three hours a day. The hallway is the product.
- No summit on the calendar? Run the same ritual asynchronously: named buddy, live pairing on day 1, first merged PR by day 3, demo in week 2.
- Track four numbers: time to first PR, time to first production deploy, time to first on-call shift, time to first independent decision.
Why day one decides day ninety
New hires spend their first week building an org map: who decides, who actually knows the system, who to avoid pinging on Fridays. Co-located hires build that map passively: by overhearing a standup, by watching who two people defer to in a hallway argument. Remote hires build it from Slack, which is a terrible instrument for it. Slack shows you who posts, not who matters.
The map that forms in week one is sticky. If a remote engineer’s week-one impression is “I don’t know who to ask, so I’ll figure it out myself,” you get an engineer who spends four hours on a problem a teammate would have answered in four minutes, and who keeps doing that in month three because the habit is set. That is the real cost of a bad first week, and it does not show up in any dashboard. It shows up as a quiet person who ships slowly and nobody can explain why.
A summit inverts it. Instead of thirty asynchronous impressions collected over six weeks, the engineer gets the whole picture in three days: the tone of arguments, who the actual tech lead is regardless of title, what leadership is worried about this quarter. Then they go home and use that context for a year.
What in-person week one actually buys you
Three things, and none of them are on the agenda:
Trust that survives text. After you have had dinner with someone, their terse PR comment reads as “busy,” not “hostile.” This is the single biggest failure mode of distributed teams and it is solved by roughly six hours of shared meals.
Tacit context. The reason the payments service is a monolith. The migration that went badly in 2024. Which parts of the codebase people are ashamed of. Nobody writes this down; everybody says it out loud at a bar.
A routing table. Not an org chart: a working list of “for auth questions, Priya; for anything Terraform, Marcus; for ‘is this a good idea’, the staff engineer who barely posts in Slack.” This alone can cut weeks off ramp.
There is a nearshore-specific bonus here. The flights are short (4-7 hours from most LATAM hubs, no red-eye across ten time zones), travel logistics are comparatively simple, and (critically) the relationships built in person get exercised during the same working hours afterward. An engineer who met your staff engineer on Tuesday can ping them at 10am their time and 11am yours on Thursday. In-person context decays fast when you can only use it in a 90-minute overlap window.
Running the numbers
| Item | Typical cost |
|---|---|
| Round-trip flight, LATAM hub to US city | $400-800 |
| Hotel, 3-4 nights | $450-700 |
| Meals and ground transport | $150-250 |
| Total per engineer | ~$1,000-1,700 |
Compare that against the alternative. A slow ramp does not cost you a line item. It costs you weeks of an engineer you are already paying, plus the senior time spent unblocking them. If in-person week one cuts even ten days off time-to-first-production-deploy, the trip pays for itself two or three times over on cost alone, before you count the retention effect. A person who has met the team is materially less likely to ghost in month two.
The mistake is treating the trip as a perk to be justified. It is a ramp accelerator with a measurable payback period. Budget it as onboarding, not as travel and entertainment.
Designing the summit agenda for one person
The instinct is to fill the new hire’s days with sessions. Resist it. Someone who sits through eleven hours of roadmap presentations learns nothing they could not have read.
Cap structured content at three hours per day. Everything else is unstructured contact time. Concretely:
- Two 1:1s per day, 30 minutes each, seated across from each other. Manager, tech lead, the PM they will work with, one person from an adjacent team, one person from support or sales who will tell them what customers actually complain about.
- One working session, not a briefing. Pair on a real ticket (even a trivial one) on day two. Shipping something small while physically next to a teammate is worth more than any architecture deck.
- Every meal assigned. Do not let the new person eat alone or default to the one other person they already met. Rotate them.
- One unstructured block per day. Whiteboard time, a walk, whatever. The good conversations happen in the gaps.
Also: send the pre-read before they fly. Architecture overview, glossary of internal acronyms, current quarter’s goals. Then nobody wastes summit time reading slides aloud.
No summit for four months? Run the async version
Most teams do not have an offsite conveniently scheduled for the new hire’s start date. The ritual still works. You just have to manufacture the density deliberately.
- Day 1: a named buddy, not a “reach out anytime.” A specific person with 5 hours blocked that week, explicitly responsible for the new hire’s questions. Ambiguous availability produces zero questions.
- Day 1: live pairing, video on, for at least 90 minutes. Environment setup done together, not from a README. Every broken step in your setup doc is a bug the new hire just found for you.
- Day 3: first merged PR. Small, real, in production code. Pre-select the ticket before they start. This is the single strongest signal of a healthy onboarding.
- Week 2: a demo to the team. Five minutes, live, of whatever they built. It forces visibility and gives everyone a reason to learn their name.
- Week 4: schedule the trip anyway. Plan the visit for the next summit or a team week. Something on the calendar beats a vague promise.
The checklist and the metrics
| Milestone | What should be true | Metric |
|---|---|---|
| Day 1 | Repo access, environment running, buddy named, ticket assigned, met manager face-to-face or on video | Environment green by end of day 1 |
| Week 1 | Met 8-10 people 1:1, first PR merged, knows who to ask for 3 domains | Time to first PR: ≤ 3 days |
| Day 30 | Shipped to production independently, participated in a design discussion, ran a ticket end-to-end | Time to first production deploy: ≤ 14 days |
| Day 90 | On-call rotation, reviews others’ PRs, makes scoping decisions without escalating | Time to first on-call shift: ≤ 60 days |
Three of these are easy to pull from your existing tooling. The fourth (time to first independent decision) is a manager’s judgment call and is the one that actually predicts whether the hire will be a strong contributor. Ask it explicitly at day 30 and day 90: has this person made a call I did not have to review?
If your remote hires are consistently blowing past these numbers, the problem is rarely the hires. It is that day one was a laptop and a wiki link.
Frequently Asked Questions
Is it worth flying someone in if they might not work out?
Yes, and you will find out faster. Three days of in-person contact surfaces communication and collaboration problems that take two months to appear over Slack. The trip is cheaper than a bad hire you keep for a full quarter because nobody had enough signal to act.
What if our summit is six months after their start date?
Run the async ritual on day one and send them to the summit when it happens. The in-person moment is still valuable at month six. It just does different work (deepening trust rather than building the initial map). Do not delay the start date to align with the offsite unless the gap is under three weeks.
Should the new hire present anything at the summit?
Only a short intro: background, what they will be working on, one non-work thing. Do not assign them a talk. Their job that week is to absorb and to be known, not to perform.
How many people should a new engineer meet in week one?
Eight to ten in real 1:1s, and no more. Beyond that, names stop sticking and every conversation gets shallower. Quality of contact beats volume: one 30-minute conversation is worth five drive-by intros.
What is the most common onboarding mistake with nearshore hires?
Treating them as a resource to be plugged in rather than a teammate to be integrated. That shows up as no buddy, no first ticket ready, and no invitation to team rituals. The result is an engineer who does exactly what they are asked and nothing more.
Does the first-PR-by-day-3 target work for senior hires too?
Yes, and it matters more for them. Senior engineers often stall in analysis for weeks. A small merged PR in the first 72 hours forces them through the whole pipeline (repo, review, CI, deploy) so they learn the system's shape before they start proposing changes to it.
