Section 39 · Compliance & Legal
Developer Onboarding
Audit developer onboarding experience - documentation, access, and day-one productivity
This guide walks you through auditing a project's developer onboarding experience - documentation, access, and day-one productivity.
The Goal: Day-One Productivity
A new developer should be able to make a meaningful contribution on their first day. This means:
- Clear onboarding path documented
- Access pre-arranged (not blocked waiting for approvals)
- Local development working quickly
- Enough context to understand the system
This guide verifies the supporting elements that make day-one productivity achievable.
Cross-reference: GIT-001 through GIT-003 cover clone-and-run experience. This section focuses on the broader onboarding context beyond local setup.
Before You Start
- Identify recent hires (if any) to gather feedback on actual onboarding experience
- Locate existing documentation (README, wiki, Notion, internal docs)
- Understand team size (smaller teams may have informal processes that work)
Onboarding Documentation
New developers need a clear path to follow. A checklist format provides progress tracking and ensures nothing is missed.
“How long until a new hire ships their first PR?”
All required access should be documented and requestable before day one. New devs shouldn't discover missing access mid-task.
“What access is a new dev still waiting on after week one?”
Technical Documentation
New developers need to understand how the system fits together. An architecture doc provides the mental model before diving into code.
“Could a new hire explain your system after day one?”
Complex or critical systems (payments, auth, integrations) need dedicated documentation beyond architecture overview.
“Payments went wrong — where does a new dev start?”
New developers need to know team conventions: branching, PRs, reviews, deployments.
“Could a contractor submit a PR without asking anyone?”
Access & Tooling
Automation reduces onboarding friction. This is a maturity indicator, not a baseline requirement.
“How many manual steps to fully onboard a new engineer?”
Shared IDE configuration ensures consistent developer experience (formatting, linting, extensions).
“New dev, fresh laptop — how long until their linter matches yours?”
Common issues and gotchas should be documented so new developers don't hit the same problems repeatedly.
“What's the most common new-hire question you answer twice a month?”