Engineering Onboarding & Access Checklist Markdown Table Template
An engineering onboarding checklist turns what the team knows informally into a sequence a new hire can follow without guessing whom to ask. The new engineer reads it every morning of the first weeks, the buddy uses it to know what to help with next, the manager uses it to spot stalls, and IT or security uses it to make sure access is granted in the right order and nothing is forgotten.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
The order matters more than the length. Access comes before environment setup, a working local environment comes before the first change, and the first change should be small enough to ship to staging within the first week. Each row needs a done-state that someone else can verify: “npm test passes locally with zero failures” can be checked, “get familiar with the codebase” cannot, and unverifiable rows are where onboarding quietly drags on.
One Markdown detail catches almost everyone: GitHub task-list syntax ([x] and [ ]) does not render as checkboxes inside table cells. You get literal brackets, and nothing is clickable. Use emoji status values such as ✅ and ⬜ in the table, or keep the table as the reference plan and track progress with a separate task list in the new hire’s onboarding issue; checkboxes in tables covers the options.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Timeline Milestone | left :--- | A relative time plus a short phase label, such as Day 1: Access or Week 1: First PR, sorted chronologically. Relative days make the template reusable for every hire; put real calendar dates only into the copy made for a specific person. |
| Onboarding Action Item | left :--- | One action per row, starting with a verb and ending in an observable result. “Clone the repository and run npm run dev until the app loads on localhost” tells the new hire exactly when they are done and tells the buddy what to check. |
| Tool / Resource | left :--- | The specific system, document, or command, ideally as a link to the internal page. Pin versions where they matter (Node.js 22, a specific Xcode) and keep them identical to the README, so the checklist and the setup docs never disagree. |
| Assisting Mentor | left :--- | A role in the reusable template (Tech Lead, Peer Buddy) and a real name in each hire’s copy. One person per row; “the team” means the new hire has to work out whom to interrupt, which is exactly what the checklist should prevent. |
| Status | center :---: | A fixed vocabulary with emoji, centered: ✅ Done, 🔄 In progress, ⬜ Not started, 📅 Scheduled. Do not use [x] or [ ] here, because task-list markers render only at the start of list items, never inside table cells. |
How to Fill It In
- 1Ask the last two or three hires what blocked them and read the questions they posted in team chat during their first month. Those blockers become rows; anything nobody struggled with can be a single line or dropped.
- 2Get the access list from whoever owns identity: SSO groups, GitHub teams, cloud roles, on-call tooling. Order it by least privilege, with read access first, write access when the first PR is ready, and production access only after a reviewed change ships.
- 3Run the local setup yourself on a clean machine or fresh container, following only the written instructions. Every step you had to improvise is a bug in the docs; fix the README before it reaches the next hire.
- 4Copy the template into a per-hire issue or page, replace roles with names, and convert relative days into dates. Confirm each mentor has the time blocked out before the start date.
- 5Review the checklist with the new hire at the end of week one and month one. Ask them to update the template with anything that was wrong or missing, since they are the only person who just experienced it fresh.
Ready-to-Paste Variations
Emoji status version
The template with status values that render correctly on GitHub, GitLab, and most wikis. The emoji carry the state; the words keep it readable for screen readers and plain-text diffs.
| Milestone | Action item | Resource | Mentor | Status |
| :--- | :--- | :--- | :--- | :---: |
| Day 1: Access | Sign in with SSO and enrol a hardware security key | IT portal | IT Support | ✅ Done |
| Day 1: Access | Join the GitHub org and the `@org/web` team (read) | GitHub | Tech Lead | ✅ Done |
| Day 2: Environment | Run `npm run dev` until the app loads locally | README | Peer Buddy | 🔄 In progress |
| Week 1: First PR | Fix the assigned starter issue and deploy to staging | Issue tracker | Tech Lead | ⬜ Not started |
| Month 1: On-call | Shadow one on-call shift | Paging tool | Eng Manager | 📅 Scheduled |Access provisioning matrix
For IT and security: every system, the level granted, who approves it, and whether offboarding must revoke it. The same table doubles as the offboarding checklist.
| System | Access level | Approved by | Granted on | Revoke at offboarding |
| :--- | :--- | :--- | :---: | :---: |
| SSO / identity provider | Employee group | IT | Day 1 | Yes |
| GitHub | `@org/web` team, read → write after first PR | Tech Lead | Day 1 / Week 1 | Yes |
| Staging cloud account | Developer role | Platform Team | Day 2 | Yes |
| Production cloud account | Read-only, then on-call role | Eng Manager | Month 1 | Yes |
| Paging and on-call tool | Responder | Eng Manager | Month 1 | Yes |30-60-90 day outcomes
A higher-level companion for the manager conversation. Each phase has one goal and evidence that it was reached.
| Phase | Goal | Evidence of done | Check-in |
| :--- | :--- | :--- | :--- |
| Days 1–30 | Ship small changes independently | Three merged PRs, one deployed to production | Day 30 with manager |
| Days 31–60 | Own a small feature end to end | Feature behind a flag, design doc reviewed | Day 60 with manager |
| Days 61–90 | Join the on-call rotation | One primary shift handled with a buddy as backup | Day 90 with manager |Common Mistakes
Using
[x] Completeand[ ] Pendingin the Status column.Task-list markers only render at the start of list items, so inside a table they show as literal brackets. Use ✅/⬜ emoji in the cell, or move the trackable list to a GitHub issue and keep the table as the plan.
Rows that cannot be verified, such as “understand the architecture”.
Rewrite each row around evidence: “Walk the buddy through a request from the load balancer to the database using the architecture doc”. If nobody can tell whether it happened, it will never be marked done.
Granting write and production access on day one to save time.
Grant read access first and add write and production access at the milestones where they are needed. The access matrix makes this explicit and gives offboarding a complete list to revoke.
A template that nobody updates after the hire who found the problems.
Make updating the template part of the month-one review, done by the new hire. Fixes then arrive while the problems are still fresh instead of being rediscovered by the next person.
Related Markdown Table Templates
Browse all 50 templatesPros & Cons Architectural Decision (ADR)
Evaluate technical tradeoffs, architectural decisions, library selections, and deployment approaches with balanced pros and cons.
User Persona & Customer Journey Matrix
Product design persona matrix defining target customer archetypes, job titles, core workflow pain points, and technical requirements.
Software Release Changelog & Notes
Semantic versioning changelog recording release versions, deployment dates, feature highlights, bugfixes, and breaking updates.
Engineering Onboarding & Access Checklist: Frequently Asked Questions
Can I put clickable checkboxes in a Markdown table?
Not with standard syntax. GitHub renders - [ ] task lists only as list items, never inside table cells, and raw HTML checkbox inputs are stripped or disabled by most sanitizers. Use emoji in the table and a real task list beneath it for tracking.
Where should the onboarding checklist live?
Keep the template next to the code it describes, for example as an issue template in .github/ISSUE_TEMPLATE/, so setup steps change in the same PR as the code. Each hire then gets their own issue created from it, with names and dates filled in.
What should a new engineer’s first task be?
A real but small change that goes through the full path: branch, review, CI, merge, and deploy to staging. The point is to exercise every tool and permission early, so access problems surface in week one instead of during the first serious feature.
How detailed should Day 1 be?
Very detailed, because the new hire has the least context then. Later phases can be broader goals; by month one, rows should look more like outcomes than instructions, and the 30-60-90 table can take over.