Adding an external developer creates a short, awkward gap between signing an agreement and making a useful contribution. Most avoidable problems appear in that gap: access is broader than the task requires, the first ticket depends on undocumented knowledge, or nobody has agreed who can approve a release.
This external developer onboarding checklist turns the gap into four gates: scope, access, delivery and exit. A developer moves forward only when the evidence for the current gate exists. The aim is not more ceremony. It is a first pull request that can be reviewed without exposing unrelated systems or relying on guesswork.
Gate 1: Make the assignment testable
Start with a one-page assignment note. It should name the product area, expected outcome, first deliverable, technical owner, reviewer and systems that are explicitly out of scope. Add the working hours that need overlap and the channel for urgent questions.
Choose a first task that exercises the real workflow without sitting on the critical path. A documentation correction is too shallow; a production migration is too risky. A small defect or contained product change is usually more revealing because it requires the developer to run the project, understand a boundary, add or update a test and respond to review.
Before granting access, confirm these points:
- The task has an acceptance condition that another person can check;
- The developer knows who owns technical and product decisions;
- The repository, environment and data needed for the task are listed;
- Unavailable systems and prohibited data are named, not assumed;
- The escalation route covers both delivery blockers and security concerns.
This is also the point to choose the engagement boundary. A single specialist joining an existing squad may fit staff augmentation services. A stable unit responsible for a continuing workstream may fit a dedicated development team. The onboarding controls can be similar, but decision ownership is not.
Gate 2: Issue the smallest useful access set
Create an individual account. Shared credentials remove attribution and make offboarding harder. Require multi-factor authentication where the platform supports it, then assign the lowest repository and infrastructure role that allows the first task to be completed.
The UK National Cyber Security Centre recommends least privilege, multi-factor authentication and removal of credentials when they are no longer needed in its guidance on securing development environments. Its repository guidance also calls for activity to be attributable to an individual. GitHub's repository-role documentation gives a practical implementation: choose Read, Triage, Write, Maintain or Admin according to the function being performed.
Translate that guidance into an access register with six fields:
- System or repository.
- Named account.
- Role granted.
- Reason the task requires it.
- Owner who approved it.
- Review or removal date.
Do not copy the access of the last person who performed a similar job. Their responsibilities may have been broader. Begin with the first task, grant what it needs and record any later elevation as a separate decision.
Use development or masked data by default. If personal data is involved, confirm whether each organisation acts as controller or processor and ensure the contract reflects the real processing. The ICO explains that controller-processor contracts set responsibilities and liabilities in its contracts guidance. Exact roles and clauses need review by the responsible privacy or legal adviser; this checklist is not legal advice.
Secrets belong in the approved secrets manager, not in chat, tickets, local configuration committed to Git or a handover document. Production access should be a separate, justified request. If the developer will touch deployment infrastructure, agree the controls with whoever owns cloud, DevOps and support before the work begins.
Gate 3: Prove the delivery path with one change
A short live setup session can expose missing assumptions faster than a long handbook. Ask the developer to clone the repository, run the project and tests, locate the first task and explain the intended change back to the reviewer. Record any step that only worked because somebody supplied an unlisted command or permission. That is a documentation defect, not a new starter's failure.
The first pull request should demonstrate the normal route to production without being deployed merely to finish onboarding. Require the same checks used for established contributors:
- A focused change linked to the agreed task;
- Tests or a clear explanation of why the change does not need one;
- No secrets, personal data or unrelated formatting churn;
- Automated checks completed;
- Review by the named technical owner;
- Product acceptance where behaviour changes.
Give feedback on the code and on the delivery path. If the developer chose the wrong branch convention, missed a local quality check or waited hours for an approval, repair the system that allowed the ambiguity. The useful onboarding output is therefore twofold: a reviewed change and a short list of friction to remove before the next person joins.
Gate 4: Design offboarding before access expands
An exit plan is part of onboarding because temporary access has a habit of becoming permanent. Put the review date in the access register on day one. For a short assignment, it may match the expected end date. For continuing work, schedule a periodic check against current responsibilities.
The exit checklist should cover account suspension or removal, repository and cloud roles, VPN access, secrets that require rotation, company equipment, locally held data, open pull requests and ownership of unfinished work. Name the person responsible for running it. A calendar reminder without an owner is easy to ignore.
Also decide what happens when the scope changes. Moving from one repository to several, from development data to production data, or from contribution to release approval should reopen the access gate. Seniority does not replace a reason for access.
A Ten-working-day sequence
Use the gates as checkpoints rather than a rigid timetable:
- Before day one: Approve the assignment note, confirm contractual and data-handling responsibilities, create named accounts and prepare the first task.
- Day one: Verify identity and multi-factor authentication, review system boundaries, run the project and confirm communication routes.
- Days two to three: Trace the relevant code path, propose the change and update missing setup notes.
- Days four to six: Open the first pull request, run the standard checks and receive specific review feedback.
- Days seven to ten: Complete the change, record onboarding friction and review whether any access can be removed or must be justified for the next assignment.
A complex legacy system may take longer. A familiar stack may take less. The meaningful measure is not elapsed time; it is whether the team can point to evidence at each gate.
The Review record to keep
At the end of the sequence, keep a compact record: the assignment note, approved access register, first pull request, unresolved setup gaps and the next access-review date. Do not turn it into a duplicate personnel file or retain personal data without a reason.
The final conversation should ask three direct questions. Can the developer describe what they own and what they do not? Can the team trace every material permission to a current task? Can another reviewer reproduce the route from local change to approved pull request? A 'no' identifies the gate to reopen.
If you are planning external capacity and need to choose the working model before applying this checklist, contact the Programmers House team to discuss the scope and ownership boundary.