IT staff augmentation<\/a> 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.<\/p>\n\n\n\nName 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.<\/p>\n\n\n\n
Now the access list. Follow least privilege, which NIST defines as the minimum needed for the assigned tasks.<\/p>\n\n\n\nSystem<\/th> Day one<\/th> Not yet<\/th><\/tr> Git hosting<\/td> Write on the repos they’ll touch<\/td> Admin, org owner<\/td><\/tr> CI<\/td> Read logs, re-run jobs<\/td> Edit pipeline secrets<\/td><\/tr> Staging<\/td> Deploy through CI, test data<\/td> Direct superuser access<\/td><\/tr> Production<\/td> Nothing<\/td> Everything, at least this week<\/td><\/tr> Tracker and chat<\/td> Member of the team’s spaces<\/td> Finance and HR spaces<\/td><\/tr> Secrets<\/td> Dev-only keys<\/td> The shared production .env<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nOn 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Write each grant into one file as you go. You’ll want it on their last day.<\/p>\n\n\n\n
<\/span>Monday: the clean setup test<\/span><\/h2>\n\n\n\nStart 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.<\/p>\n\n\n\n
git clone git@github.com:acme\/shop-api.git && cd shop-api\ncp .env.example .env\ndocker compose up -d\nnpm ci && npm run db:seed && npm test<\/code><\/pre>\n\n\n\nIf 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.<\/p>\n\n\n\n
Keep only fake values in .env.example<\/code>. 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.<\/p>\n\n\n\n<\/span>Tuesday: repo rules<\/span><\/h2>\n\n\n\nLet the rules do the policing, so nobody has to feel awkward about it. Put a branch protection rule on main<\/code> 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.<\/p>\n\n\n\nThen add a CODEOWNERS file:<\/p>\n\n\n\n
# .github\/CODEOWNERS\n* @acme\/backend-leads\n\/billing\/ @acme\/payments\n\/infra\/ @acme\/devops<\/code><\/pre>\n\n\n\nCode 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.<\/p>\n\n\n\n
Write your house rules on one page: branch names, commit style, how migrations run, what “done” means. People read one page.<\/p>\n\n\n\n
<\/span>Wednesday: a real task, kept small<\/span><\/h2>\n\n\n\nPick 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
<\/span>Thursday: the first review<\/span><\/h2>\n\n\n\nGoogle’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.<\/p>\n\n\n\n
Look for these things:<\/p>\n\n\n\n