By Alexander Rocket, founder of Rocketech
An outside developer starts on Monday. By Wednesday they’re still waiting for a repo invite, the staging password is in somebody’s DMs, and you’re paying for all of it.
Most of that goes away if you plan the week ahead of time. Set one goal: by Friday, a reviewed pull request from the new person is merged and running on staging. The rest of this plan works back from that goal.
The week before
Sign the paperwork first. The contract, the NDA and the clause on who owns the code all come before any invite.
Then start on access early, because the person may arrive sooner than your process is ready. IT staff augmentation moves fast by design. At Rocketech, someone already on our staff or in our pool starts in 3-5 days, and a new hire within 2 weeks. If your IT tickets take a week, you lose the time you were paying to save.
Name two people. The lead sets tasks and answers questions, and the new developer reports to them. The reviewer owns the first pull requests. These can be the same person, but it can’t be nobody. If no one has time to lead, hold off on adding people, because outside developers still need a manager.
Now the access list. Follow least privilege, which NIST defines as the minimum needed for the assigned tasks.
| System | Day one | Not yet |
|---|---|---|
| Git hosting | Write on the repos they’ll touch | Admin, org owner |
| CI | Read logs, re-run jobs | Edit pipeline secrets |
| Staging | Deploy through CI, test data | Direct superuser access |
| Production | Nothing | Everything, at least this week |
| Tracker and chat | Member of the team’s spaces | Finance and HR spaces |
| Secrets | Dev-only keys | The shared production .env |
On GitHub you don’t have to make them an org member. An outside collaborator gets only the repos you choose, and has to turn on 2FA first if your org requires it. Give them the Write role, which GitHub recommends for contributors who actively push.
Give them their own accounts. Shared logins make your audit logs useless, and removing one person later means changing the password for everyone. If you use a VPN, test the invite from outside the office before Monday.
Write each grant into one file as you go. You’ll want it on their last day.
Monday: the clean setup test
Start with a 20-minute call: what the product does, who pays for it, which parts break most often. Then get out of the way. Don’t pair through setup. Let them follow the README and note each place it breaks.
git clone git@github.com:acme/shop-api.git && cd shop-api
cp .env.example .env
docker compose up -d
npm ci && npm run db:seed && npm testIf this takes all day, that’s useful news, and it’s better to hear it now. Their first pull request should fix the README. It carries little risk and walks them through your whole path from branch to merge.
Keep only fake values in .env.example. The Twelve-Factor App offers a good test: could you open-source this code right now without leaking a credential? Check the Git history as well, because a new contributor gets all of it, including that key someone deleted last year.
Tuesday: repo rules
Let the rules do the policing, so nobody has to feel awkward about it. Put a branch protection rule on main that requires a pull request, a passing status check and at least one approval. GitHub turns off force pushes and branch deletion on protected branches by default.
Then add a CODEOWNERS file:
# .github/CODEOWNERS
* @acme/backend-leads
/billing/ @acme/payments
/infra/ @acme/devopsCode owners get asked for review automatically when a pull request touches their files, and you can make their approval required. They need write permission on the repo, or this won’t work. The new developer can now work anywhere, and the risky folders still get the right eyes.
Write your house rules on one page: branch names, commit style, how migrations run, what “done” means. People read one page.
Wednesday: a real task, kept small
Pick a real bug or a small feature from the backlog. A made-up exercise wastes everyone’s time, and payment code is too risky for a first task. Look for something that touches one area, has a clear finish line and needs a test.
Say the size out loud. Google’s review guide calls 100 lines a reasonable change and 1,000 lines usually too large. A big first pull request often means the person got stuck and kept going alone.
From today they’re in your standups and your tracker, like anyone else on the team. Agree on the hours you overlap and write them down. If you’re six hours apart, decide which hours you share and where questions go for the rest of the day.
Thursday: the first review
Google’s guide also sets one business day as the longest you should take to respond to a review request. Beat that on a first pull request. A slow first review teaches a new person to save up big batches and wait.
Look for these things:
- Does the change follow the patterns already in the code?
- Did a new dependency sneak in, and is there a reason for it?
- Is there a test that fails without the fix?
- Did they ask when the ticket was vague? Someone who guesses in silence costs more than someone who asks.
Mark each comment as blocking or optional. A newcomer can’t tell your firm rule from a passing thought.
Friday: ship it, then talk
Merge it and deploy to staging through CI, never from a laptop. Then take 15 minutes for three questions:
- What took longest?
- What did you have to ask that should be written down?
- What would you change about the setup?
Fix the top answer next week. Then go through the access file. Remove anything they didn’t use, and add only what next week’s task needs.
Plan the last day now
People move on, and this is where the access file pays off. Remove the collaborator, revoke their tokens and deploy keys, and close their chat account. Then change every secret they could read. OWASP’s cheat sheet on secrets points out that rotating keys by hand leads to mistakes, so automate it if you can.
Save this plan as a file in the repo. The next person you bring in starts from a list that’s been tested once.
