Before day one
Every account created and tested: repository, CI, cloud console with the right scope, staging, ticket tracker, design tool, chat, calendar. An engineer who spends day one requesting access has learned that they are peripheral.
A written brief: what the product does, who the customers are, what is currently on fire. Two pages, not a wiki.
A named buddy. "Ask in the channel" is how a remote engineer stays silent for three weeks.
Week one — ship something tiny
Pick a small, real, low-risk task with a merge at the end of it. A copy fix, a missing test, a small bug. The goal is not the output; it is to run the whole pipeline once — clone, branch, review, CI, merge, deploy — while someone is watching who can unblock them.
Have them write down every point of friction. A new person is the only one who can still see what is broken about your setup, and that visibility expires in about two weeks.
Weeks two and three — hand over ownership
Give one bounded area they own: a service, a feature, a screen. Ownership means they make decisions in it without asking first, and it is the difference between a team member and a ticket queue.
This is the step companies skip, and skipping it is why the engagement feels flat by month three. A senior engineer with no authority will do exactly what is asked, which is the worst possible use of a senior engineer.
Put them in front of the actual stakeholder. If a product manager describes the problem directly, you get engineering input on the requirement. If it goes through a translator, you get compliance.
Week four — check the working agreement, not the output
The month-one review should be about process, not velocity: Are meetings at a workable hour for both sides? Is the feedback loop fast enough? Is anything blocked on a timezone gap that could be solved by writing it down instead?
Ask directly what they are unsure about. Brazilian professional culture tends toward politeness with a new client, and a direct invitation to criticize is often needed before the real answer arrives.
The four failure modes
Treating them as a vendor. Excluding someone from planning and then wondering why they lack context.
The single point of contact. When one person is the only channel, the engagement stops whenever that person is on vacation.
No ownership. Discussed above; it is the most common one.
Silent dissatisfaction. Problems surface late in cross-cultural remote teams. Schedule a direct one-to-one in week two and ask an uncomfortable question on purpose.
Key takeaways
- All access provisioned and tested before day one.
- A named buddy, not a channel.
- A merged pull request in week one, however small.
- One owned area by week three, with real decision authority.
- Month-one review about the working agreement, not velocity.