Onboarding a New Software Developer

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.