Onboarding a New Software Developer

IT-side onboarding workflow for a new software developer, from pre-start provisioning through Day 1 access verification and a 30-day access review. Run by the IT lead in coordination with the engineering manager and assigned mentor.

4 sections 19 steps Collects data
1

Pre-Start Setup

  1. Capture start date, role, and team
    • The hiring manager confirms the start date, the developer's title (junior, senior, staff), and the product team. These values drive SCIM group assignment downstream — getting the team wrong means the developer lands without repo access on Day 1.

    Collects date Collects text Collects text
  2. Image and enroll the laptop in MDM
    • Enroll the laptop in Jamf, Intune, or Kandji per platform. Confirm FileVault or BitLocker is enforced and the EDR agent (CrowdStrike, SentinelOne, or Defender for Endpoint) is queued via the MDM profile so it lands on first boot.

  3. Create the IdP account with SCIM groups
    • Provision in Okta, Entra ID, or JumpCloud. Assign to the engineering baseline group plus the team-specific group captured above — SCIM will downstream-provision GitHub, Slack, the PagerDuty schedule, and other connected SaaS without manual seat assignment.

  4. Order a FIDO2 hardware key
    • Ship a YubiKey or Titan key to the developer's address ahead of the start date. SMS and TOTP MFA are not the bar — phishing-resistant MFA is the IdP policy default for new engineering hires.

  5. Refresh the dev onboarding runbook
    • Walk the runbook in IT Glue, Hudu, or Confluence. Tools change quarterly; a runbook last updated 8 months ago will send the new hire to a deprecated VPN client or a renamed Slack channel.

  6. Assign a mentor from the product team
2

Day One Provisioning

  1. Enroll the hardware key in the IdP
    • Walk the developer through FIDO2 enrollment in the IdP self-service portal. Register two factors where possible (primary key plus a backup) so a lost key doesn't trigger a break-glass workflow.

  2. Verify the EDR agent is reporting
    • Check the CrowdStrike or SentinelOne console for the new hostname and confirm the agent is healthy, signature-current, and tagged to the engineering policy. An MDM-enrolled laptop with a stale or absent EDR agent is a common gap.

  3. Add to PagerDuty and Slack channels
    • Add the developer to the team's Slack channels, the engineering-wide announcement channel, and the PagerDuty schedule as a shadow (not primary) until they have completed the on-call shadow shift.

  4. Walk SSO into baseline SaaS
    • Have the developer log into GitHub, Slack, the cloud console, the observability tool (Datadog, New Relic, Grafana), the PSA, and the password vault via the IdP launcher. Confirm each app loads without an additional prompt — a stuck SCIM provisioning often surfaces here.

    Collects list
  5. Troubleshoot SSO and SCIM gaps
    • Most failures trace to a missing SCIM group assignment or an app where the IdP push hasn't propagated. Check the IdP system log for the user's provisioning events; manually assign the missing app and re-run the SCIM push.

3

First Week Engineering Access

  1. Provision GitHub org and repo access
    • Add to the GitHub org via SCIM if connected; otherwise add to the engineering team and the product team's repo team. Enforce signed commits and require the developer to upload an SSH key tied to their hardware-key-protected workstation.

    Collects text
  2. Grant cloud IAM via SSO role mapping
    • Map the developer to the engineering-read or engineering-write role in AWS IAM Identity Center, Entra ID for Azure, or Workload Identity Federation in GCP. Avoid creating long-lived IAM users — federation through the IdP is the firm baseline so deprovisioning is single-source.

  3. Stand up the local dev environment
    • Walk the README in the team's primary repo. Confirm the developer can run the test suite locally, hit a dev API, and authenticate to the secrets manager (Vault, AWS Secrets Manager, Doppler). Capture friction points in the runbook for the next hire.

  4. Pair with the mentor on a first PR
    • The mentor pairs on a small, scoped change — a docs fix, a flake repair, a low-risk refactor. The goal is to walk the PR template, the CI pipeline, the review norms, and the deployment path end-to-end before the developer ships solo.

  5. Shadow the on-call rotation
    • Schedule one shadow shift on PagerDuty alongside the current primary. Confirm the developer can acknowledge a page on phone and laptop, open the runbook, and reach the war-room Slack channel.

4

30-Day Access Review

  1. Run an access review against the IdP
    • Pull the developer's app assignments from Okta or Entra ID and cross-check against what the team actually uses. Over-provisioned access (DocuSign admin, billing console) shows up here and gets removed before the SOC 2 quarterly review surfaces it.

  2. Hold the 30-day manager check-in
    • The engineering manager and IT lead meet with the developer to surface anything still broken — a vendor SaaS the team uses that wasn't on the SCIM push, a VPN profile that drops at the office, a missing repo. Capture the list before remediating.

    Collects list
  3. Remediate flagged provisioning gaps
    • Resolve each gap in the IdP or directly in the SaaS where SCIM isn't available. Update the onboarding runbook so the next hire doesn't hit the same gap — the runbook is the durable artifact of this workflow, not the ticket.

Use this template

Copy it to your account, customize the steps, and run it with your team in minutes.


Sections 4
Steps 19
Category Information Technology
Price Free to start
Need a different process

Browse hundreds of free templates across every team and industry.

Back to template library

Run Onboarding a New Software Developer with your team

Customize the steps, assign roles, set a schedule, and keep a complete record for every run.