In this guide 6 sections
Onboard an augmented engineer in five working days. Create accounts in your company’s name before day one and grant repository and CI access. Get the project running locally, assign a named buddy and ship one small reviewed change by Friday. Split tasks between vendor and client.
Before day one: accounts in your name
Raise the access requests a week ahead. Delays here waste the first two days of a paid engineer. Create the email address, repository seat, ticket board login and chat account under your company’s own domain, and test each login yourself from a clean browser profile.
The vendor handles the laptop, antivirus, VPN client and signed confidentiality paperwork. You handle everything that touches your systems. Keep that line sharp. Nobody then waits on the wrong party.
Send a short welcome note before the start date with the standup time, the buddy’s name and a link to the architecture page.
- Company email and single sign-on seat
- Repository access limited to the needed projects
- Ticket board role and chat channels
- Password manager vault with the shared test logins
- Staging environment account, not production
Day one and two: repository, CI and local setup
Start with a thirty minute call on how the system fits together. Show the main services, the database, the queue and where deployment happens. A whiteboard sketch beats a forty page document.
Then let the engineer clone the repository and follow your README to a running local build, installing the runtime, seeding the database and starting the queue worker. Every gap they hit is a bug in the README. Fix it today.
Give read access to the CI pipeline on day one. Deploy rights come later. Make sure the engineer can run the test suite, and read one failing build log together with the buddy so the pipeline stops being a black box.
Name a buddy and pick the first task
The buddy is one of your own engineers, not the vendor’s lead. Their job is to answer questions within the hour, sit in the first two pull request reviews and explain why things are done the odd way they are.
Choose the first task in advance. It should touch one module, include a test and have a visible result. A copy change is too trivial. A payment refactor is far too big. Aim between.
Write the task as a ticket with acceptance criteria, the file paths to start from and the person who accepts it.
- Fix a validation message and add the unit test
- Add one field to an existing API response
- Replace a deprecated library call in a single module
- Close a small bug with a reproducible case
Days three to five: ship one small change
Aim to merge and deploy to staging by Thursday. A change in production by Friday is better still. Early shipping proves that access, pipeline and review all work, and it builds confidence on both sides.
Review the first pull requests closely but kindly. Comment on naming, test coverage and commit messages. Note anything the engineer would not know from outside, such as a house rule on feature flags.
On Friday, hold a fifteen minute retro. Ask what was missing, what was confusing and what took longest. Add each answer to the onboarding page.
Who handles what, and how to know it worked
Keep a two column list. Vendor: hardware, payroll, leave cover, background checks and the replacement process. Client: accounts, repository rights, environments, code review and task priority.
At the end of week one, check four things. Can the engineer build locally unaided? Did one change ship? Does the buddy trust the review quality? Is every account in your name?
If any answer is no, fix it before assigning larger work. Print the checklist. Tick it with the engineer on Friday.
First week onboarding checklist
Five columns for Monday to Friday and two rows for vendor and client make up this single-page grid. Under each day it lists accounts to create, repository and CI permissions, local setup milestones and buddy sessions. The first ticket sits in a box with its acceptance criteria. A footer records the access revocation date.
Open a blank worksheet to printQuestions owners ask
How long before an augmented engineer is productive?
Most reach useful work within a few weeks, depending on how well the repository is documented. The first merged change in week one is the better signal than a fixed target.
Should the engineer get production access in week one?
Rarely. Staging access first, then production read access for logs, and deploy rights only after a few reviewed changes. Grant each step to a named person and note the date.
What if our README is poor?
Then the engineer’s first days will expose it. Treat that as useful. Let them correct the README as they go, and review those edits as seriously as code.
Who pays for time spent on onboarding?
That is a contract matter. Many agreements bill from the first working day. Ask the vendor whether a short ramp-up discount or free overlap applies when a replacement joins.