A senior engineer should be committing meaningful code to an unfamiliar codebase within three days — not three weeks. The bottleneck is almost never talent; it’s a repeatable onboarding process. This is the exact sequence we run when we embed engineers into a client’s team: read the repo like a historian, get a running environment in an afternoon, ship one small reversible change, then join the sprint.
Every staff-augmentation provider promises “vetted senior engineers.” Almost none can tell you what those engineers do in their first 72 hours. That gap is where most of the wasted onboarding time hides — and it’s the difference between an embedded engineer and a contractor waiting for tickets.
Below is the onboarding playbook we run when a We Work Worldwide engineer joins an existing product team. It assumes nothing about the stack and everything about discipline. Steal it, whether or not you ever work with us.
Why onboarding — not hiring — is the real bottleneck
When a team says they need to “hire faster,” what they usually mean is they need working output faster. Those are different problems. You can drop a brilliant engineer into a 200k-line codebase and get nothing useful for a month if the onboarding is ad hoc: no seed data, a README that lied, tribal knowledge locked in one senior’s head.
The embedded model only works if onboarding is a process, not an event. Here is what that process looks like, day by day.
Day 0
Read the repository like a historian
Before writing a line of code, we mine the repo for the story it already tells. Git history is the most honest documentation a project has — it can’t go stale.
Where has the code actually changed most? Churn hotspots are where the risk and the domain complexity live:
# files with the most commits in the last year — your hotspotsngit log --since="1 year ago" --name-only --pretty=format: n | sort | uniq -c | sort -rn | head -25Who owns what, and who to ask? Even without a CODEOWNERS file, git tells you:
# top authors for a given pathngit shortlog -sn -- path/to/subsystemnn# when did this weird line get here, and why (read the PR)ngit log -p -S"suspiciousFunction" -- src/Then we read the schema before the application code. Migrations, in order, are the clearest map of the domain that exists — they show every entity, every relationship, and every decision the team reversed. A db/migrate or prisma/migrations directory read chronologically teaches you more in 30 minutes than a week of clicking through controllers.
Finally we map the entry points: the routes file, the job queue registrations, the cron definitions, the webhook handlers. Every codebase has a handful of doors into the system. List them and the mental model snaps into focus.
Day 1
A running environment before lunch
The single biggest predictor of a slow onboarding is a local environment that takes days to stand up. Our rule: if a new engineer can’t get the app running in an afternoon, that’s the first thing we fix — and we fix it for everyone.
We look for a one-command bootstrap. If it doesn’t exist, writing one is our first contribution:
# the target every repo should havenmake setup # deps, containers, migrations, seed datanmake dev # run itnmake test # prove it worksSeed data matters more than people admit. An empty database tells you nothing about how the product behaves. A realistic seed — a few tenants, some orders, an edge-case account — lets a new engineer use the product on day one and see the code from the user’s side.
Then we trace one smoke path end to end: a single real user action (sign up, place an order) followed from the HTTP request, through the service layer, into the database, and back. One path, fully understood, is worth more than skimming the whole codebase.
Day 2
The first pull request: small, safe, reversible
The first PR is not about impact. It’s about proving the whole loop works — branch, change, test, review, merge, deploy — and earning trust without risk. The best first change is small, boring, and observable.
- Small: a genuine fix or a papercut, not a refactor. Under ~50 lines.
- Reversible: behind a feature flag if it touches behaviour, so a rollback is one toggle, not a redeploy.
- Observable: if it changes anything user-facing, it ships with a log line or a metric so you can see it working in production.
This is also where we learn the team’s real review culture — the difference between the written standard and how PRs actually get merged. An embedded engineer adapts to your conventions, not the other way around.
Day 3
Join the sprint, not just the Slack
By day three the engineer is in standups, has read the current PRDs, and is picking up real sprint work. The tell of a well-onboarded engineer isn’t velocity — it’s that they start asking the right questions and pushing back. “This ticket assumes X, but the schema says Y — which is right?” is the sound of context, and context is the whole point of embedding.
The onboarding checklist we actually use
- Churn hotspots identified (
git logby file frequency) - Schema read chronologically through migrations
- Entry points mapped: routes, jobs, crons, webhooks
- Owners identified per subsystem
- App runs locally via a single documented command
- Realistic seed data loaded
- One smoke path traced request-to-database
- Test suite green locally
- Small, reversible PR opened and reviewed
- Change is observable in logs or metrics
- Team’s real review conventions learned
- In standups and reading current PRDs
- Owning a real sprint ticket
- Asking clarifying questions that surface hidden assumptions
What this looks like when it’s someone else’s job
This is the part a marketplace can’t sell you. A platform places a developer and steps back; whether that person is productive in three days or three weeks is your problem. Our model is the opposite: onboarding is our responsibility, because we’re measured on delivery, not placement.
That’s the same reason we can flip the engagement entirely and take full ownership of a build when a team would rather hand us the problem than the process. Embed into your team, or own the whole thing — either way the discipline above is what makes it work.
Frequently asked questions
Can an engineer really be productive in a codebase in 3 days?
A senior engineer following a structured onboarding can ship a small, real change by day three and take on sprint work immediately after. The constraint is rarely the engineer’s ability — it’s whether the team has a running environment, seed data, and a clear first task ready. Fix those and three days is realistic.
What slows engineer onboarding down the most?
A local environment that takes days to stand up, missing or unrealistic seed data, and a README that no longer matches reality. These are process failures, not talent failures, and each is fixable — usually as the new engineer’s first contribution.
How is an embedded engineer different from a contractor or freelancer?
A contractor waits for tickets and executes them. An embedded engineer joins your standups, reads your PRDs, adapts to your review conventions, and pushes back when a requirement conflicts with the code. The difference is context and ownership, not seniority.
Does We Work Worldwide only provide engineers, or can you build the whole product?
Both. We embed engineers into your existing team, or take full ownership of a build and deliver the solution like an agency — whichever fits how you want to work. See how that compares to marketplace and staff-augmentation providers.