"Integrated" gets used a lot in staff augmentation. It's on pitch decks and in sales calls, usually next to a checkmark. It rarely gets explained in a way that means much to the person actually living through it. Here's a closer look at what those first weeks tend to look like for an engineer joining a client's team through KWAN, and where the model shows up in practice rather than in a slide.
WHAT YOU’LL FIND IN THIS ARTICLE:
→ Why the first weeks actually matter more than they get credit for
→ Why integration looks different for a nearshore engineer specifically
→ What relocating engineers actually get on day one, beyond a laptop
→ What the first four weeks typically look like, and where KWAN's model shows up in them
→ What makes the difference between feeling integrated in two weeks versus two months
Most organisations treat the first weeks as a formality before the "real work" starts. The research says otherwise. Gallup found only 12% of employees strongly agree their organisation does a great job onboarding new hires, and treats that early period as the point where an emotional bond with the work either forms or doesn't.
The SHRM Foundation's guide to onboarding, by Talya Bauer, Ph.D., puts a number on the window: new hires get about 90 days to prove themselves. Bauer breaks onboarding into four levels: Compliance, Clarification, Culture, and Connection, and separately identifies three levels of onboarding practice: passive, high potential, and proactive. Only about 20% of organisations reach the proactive level, the one that actually delivers on Connection, linking a new hire to real relationships and information rather than just the paperwork and the rules. Connection is what determines whether someone feels part of a team, and it's the piece that's hardest to put on a checklist.
That research wasn't written with distributed teams in mind, but it applies more, not less, once the office disappears. Remote and hybrid work are now the norm rather than the exception in this industry: in the 2025 Stack Overflow Developer Survey, 32.4% of developers work fully remote and a further 37.1% work hybrid, globally. For an engineer joining a client's team from another country, there's no shared office to pick up who to ask about what, or what the unwritten rules around code review actually are.
That context has to be built on purpose. 12 ways staff augmentation aligns distributed teams covers the structural side; this is the lived version
Not every nearshore engineer relocates. Many are already in Portugal. For the ones who move internationally, integration starts more basically: knowing where to find a doctor, or who to call in an emergency.
That's one of the first things a People Experience Partner, or PEP, hands over: a Welcome Guide covering fourteen practical areas, from emergency numbers and housing platforms to the tax and social security numbers needed to work legally (NIF and NISS), banking, healthcare, and schooling. It closes on one line: "Your PEP is your career guide. For any question, project, integration, life in Portugal, or growth, talk to them first."
It matters for the same reason Bauer's framework points at: Connection isn't only about teammates. For someone who just moved countries, it starts with not feeling lost in the country itself.
A KWAN engineer typically has a short call with their PEP before day one even happens, separate from anyone measuring delivery. On many projects nobody plays that role, and the first contact beyond a direct manager is whatever survey HR sends weeks later. Here, that relationship usually exists before a line of code gets written.
Day one itself is logins and a calendar full of meetings with no context yet. The first standup is the strange one: everyone else has months of shared shorthand, and a new engineer usually just notes down what they don't understand to ask about later.
The first PR often takes longer than expected, less because the code is hard and more because nobody yet knows which linting rules are enforced or which reviewer cares about a detail nobody else mentions. The comments that come back teach more than the fix itself.
By the end of week one, it's normal to have shipped very little and read a lot more. Few teams say so out loud, which is why it can feel like falling behind when it's actually on schedule.
The first real check-in with a PEP tends to open with "how's it actually going," asked in a way that expects a real answer. That's when a small frustration, a meeting that runs long, a reviewer whose tone reads harsher than intended, gets named before it turns into something bigger. Nobody solves it dramatically. It just gets acknowledged, and it's often better a week later, because someone whose job isn't managing delivery was paying attention. On a project without that role, the same frustration tends to just sit there.
This is Bauer's "Connection" level, happening in practice rather than on a slide.
Around week three, a PR goes through with a single approving comment and no back-and-forth, the first real sign the team trusts the judgement behind the code, not just the code. Around the same time, someone might ask what an engineer thinks before a decision is made, not after. A second PEP check-in often happens around week four, with less to talk through, which is itself a sign the first one worked. By week four, in-jokes in team chat start landing, usually a better marker of integration than any project milestone.
Some engineers feel part of the team within two weeks; others take two months on equally capable, welcoming teams. The gap isn't talent or effort. It tends to come down to a few things:
Someone checks in who isn't the delivery manager. That relationship usually starts before day one, not after a missed deadline.
The first task comes with a clear "why." An identical ticket without context gets done just as competently, and integrates nobody.
Small contributions get acknowledged early, specifically, in week one rather than the first quarter.
Context gets explained, not just assigned, so a confusing standup comment becomes something to contribute to.
The basics outside work are covered too. For anyone relocating, not figuring out healthcare or banking alone removes background stress that has nothing to do with the codebase but affects focus on it anyway.
None of this is complicated. It's also the first thing skipped when onboarding is a checklist rather than a relationship, which is the gap between Bauer's third and fourth levels: understanding the culture isn't the same as being connected to the people in it.
The 88% of employees who, per Gallup, don't strongly agree their organisation onboards well aren't a rounding error. They're close to the difference between an engagement that compounds in value over a year and one that resets every few months with someone new, a distinction covered from the other side in staying longer is the underrated career move. The four weeks here aren't a soft add-on to the technical work; for a distributed team, they're a large part of what decides whether the technical work holds up at all.
A short call before day one, a proper check-in around week two on how things are actually going, and a follow-up around week four. The role sits apart from anyone measuring project output, which lets different friction surface earlier.
Yes. Engineers already based in Portugal skip that part but go through the same project-side onboarding: standups, first PR, PEP check-ins.
It varies more by structure than effort, from two weeks to two months on otherwise similar teams. The difference usually comes down to whether someone outside the delivery chain is paying attention early.
Not usually. Shipping little and reading a lot is normal for almost any new hire on an existing codebase. The concerning pattern is that ratio not shifting by week three or four.
The search happens again, and the team absorbs the delivery gap in between. A placement that integrates and stays protects the hiring investment in a way speed alone doesn't.
If this is the kind of setup you're looking for, have a look at our open roles.