The onboarding doc your managers swore they'd get to. As a template.
What goes in a new-hire onboarding document? The company, the team, who owns what, why things are the way they are and what is happening now. Copy the template below, in a version for your role. Fill it in yourself, or have Firstweek write it from your tools.
What goes in a new-hire onboarding document?
Ten sections, and every one of them answers a question the new hire would otherwise ask a teammate: why this role exists, the company in one page, the team, who owns what, why things are the way they are, what is happening now, the first 90 days, the people to meet, the open questions for the manager, and the sources behind every claim.
The sections that matter most are the ones that never make it into a checklist: who owns what, and why. They are the ones a manager keeps meaning to write.
The core template
This part is the same for every role. Copy it, then add your role's sections from the list below.
Why this role exists. What changed in the business that made us hire this role, and what success looks like at 90 days.
The company in one page. What we sell, to whom, and the three things leadership is focused on this quarter.
Your team. Who is on it, what each person owns, and who to ask about what.
Who owns what. The systems, accounts, projects or services you will touch, with the current owner of each.
Why things are the way they are. The decisions a newcomer would question (pricing, architecture, process), with the reason and a link to the thread or doc where it was decided.
What is happening now. What is on fire, what is in flight, and what is deliberately paused.
Your first 90 days. Week one, day 30, day 60, day 90. Specific work, not "get to know the team".
People to meet. Name, role, why to meet them, and the one question to ask each.
Open questions for your manager. What we know we haven't written down yet.
Sources. A link to the thread, page or record behind every claim above.
Versions for six roles
Each version is the core template plus the sections that role's context lives in. Copy it as plain Markdown.
Account executive
A new AE needs the accounts and the deal history before the playbook. The pricing logic and the owner of each account are the parts that live in threads.
Add these sections
Accounts you inherit. For each: owner, stage, last contact, how the relationship got here, and who the real decision-maker is.
Deals in flight. Amount, stage, next step, and who is involved on both sides.
How we price and discount. The current approach, why it changed, and who approves an exception.
Competitors you will hear about. Who comes up, where we win and lose, and the thread or call where we learned it.
Who to ask in RevOps and solutions. The person for each recurring question, and what they own.
# Welcome, [Name]
## Why this role exists
What changed in the business that made us hire this role, and what success looks like at 90 days.
## The company in one page
What we sell, to whom, and the three things leadership is focused on this quarter.
## Your team
Who is on it, what each person owns, and who to ask about what.
## Who owns what
The systems, accounts, projects or services you will touch, with the current owner of each.
## Why things are the way they are
The decisions a newcomer would question (pricing, architecture, process), with the reason and a link to the thread or doc where it was decided.
## What is happening now
What is on fire, what is in flight, and what is deliberately paused.
## Your first 90 days
Week one, day 30, day 60, day 90. Specific work, not "get to know the team".
## People to meet
Name, role, why to meet them, and the one question to ask each.
## Open questions for your manager
What we know we haven't written down yet.
## Sources
A link to the thread, page or record behind every claim above.
## Accounts you inherit
For each: owner, stage, last contact, how the relationship got here, and who the real decision-maker is.
## Deals in flight
Amount, stage, next step, and who is involved on both sides.
## How we price and discount
The current approach, why it changed, and who approves an exception.
## Competitors you will hear about
Who comes up, where we win and lose, and the thread or call where we learned it.
## Who to ask in RevOps and solutions
The person for each recurring question, and what they own.
Customer success manager
A new CSM inherits accounts mid-story. What was promised, and by whom, matters more than the health score.
Add these sections
Accounts you inherit. For each: health, renewal date, champions, open escalations, and what was promised.
History worth knowing. Why they bought, past incidents, contract quirks, and anything the last CSM would say out loud.
The escalation path. Who to pull in for what, and how fast each one answers.
Product gaps customers keep raising. The request, the accounts asking, and what was said back.
# Welcome, [Name]
## Why this role exists
What changed in the business that made us hire this role, and what success looks like at 90 days.
## The company in one page
What we sell, to whom, and the three things leadership is focused on this quarter.
## Your team
Who is on it, what each person owns, and who to ask about what.
## Who owns what
The systems, accounts, projects or services you will touch, with the current owner of each.
## Why things are the way they are
The decisions a newcomer would question (pricing, architecture, process), with the reason and a link to the thread or doc where it was decided.
## What is happening now
What is on fire, what is in flight, and what is deliberately paused.
## Your first 90 days
Week one, day 30, day 60, day 90. Specific work, not "get to know the team".
## People to meet
Name, role, why to meet them, and the one question to ask each.
## Open questions for your manager
What we know we haven't written down yet.
## Sources
A link to the thread, page or record behind every claim above.
## Accounts you inherit
For each: health, renewal date, champions, open escalations, and what was promised.
## History worth knowing
Why they bought, past incidents, contract quirks, and anything the last CSM would say out loud.
## The escalation path
Who to pull in for what, and how fast each one answers.
## Product gaps customers keep raising
The request, the accounts asking, and what was said back.
Software engineer
A new engineer needs the system map and the reasons, not just the repository. The reasons are in old pull requests and Slack threads.
Add these sections
The system map. The services, who owns each, and how a request moves between them.
Why it is built this way. The constraints and decisions behind the odd parts, with links to the pull request, ticket or thread.
How a change ships, and who gets paged. Review, deploy, rollback, and the on-call rotation.
Known landmines. The fragile jobs and the services nobody wants to touch, and why.
Your first pull request. A small, real change, who reviews it, and what good looks like.
# Welcome, [Name]
## Why this role exists
What changed in the business that made us hire this role, and what success looks like at 90 days.
## The company in one page
What we sell, to whom, and the three things leadership is focused on this quarter.
## Your team
Who is on it, what each person owns, and who to ask about what.
## Who owns what
The systems, accounts, projects or services you will touch, with the current owner of each.
## Why things are the way they are
The decisions a newcomer would question (pricing, architecture, process), with the reason and a link to the thread or doc where it was decided.
## What is happening now
What is on fire, what is in flight, and what is deliberately paused.
## Your first 90 days
Week one, day 30, day 60, day 90. Specific work, not "get to know the team".
## People to meet
Name, role, why to meet them, and the one question to ask each.
## Open questions for your manager
What we know we haven't written down yet.
## Sources
A link to the thread, page or record behind every claim above.
## The system map
The services, who owns each, and how a request moves between them.
## Why it is built this way
The constraints and decisions behind the odd parts, with links to the pull request, ticket or thread.
## How a change ships, and who gets paged
Review, deploy, rollback, and the on-call rotation.
## Known landmines
The fragile jobs and the services nobody wants to touch, and why.
## Your first pull request
A small, real change, who reviews it, and what good looks like.
Product manager
A new PM inherits a roadmap and the arguments that shaped it. What was dropped, and why, is the part nobody wrote down in one place.
Add these sections
The roadmap, and why. What is committed, what was dropped, and the reason for each.
Customers and what they ask for. The accounts that matter, the requests that repeat, and who owns each relationship.
Metrics we trust, and ones we don't. Where each number comes from and how much to believe it.
Decisions in flight. What is undecided, who decides, and by when.
Stakeholders. Who needs to be involved in what, and how they prefer to be.
# Welcome, [Name]
## Why this role exists
What changed in the business that made us hire this role, and what success looks like at 90 days.
## The company in one page
What we sell, to whom, and the three things leadership is focused on this quarter.
## Your team
Who is on it, what each person owns, and who to ask about what.
## Who owns what
The systems, accounts, projects or services you will touch, with the current owner of each.
## Why things are the way they are
The decisions a newcomer would question (pricing, architecture, process), with the reason and a link to the thread or doc where it was decided.
## What is happening now
What is on fire, what is in flight, and what is deliberately paused.
## Your first 90 days
Week one, day 30, day 60, day 90. Specific work, not "get to know the team".
## People to meet
Name, role, why to meet them, and the one question to ask each.
## Open questions for your manager
What we know we haven't written down yet.
## Sources
A link to the thread, page or record behind every claim above.
## The roadmap, and why
What is committed, what was dropped, and the reason for each.
## Customers and what they ask for
The accounts that matter, the requests that repeat, and who owns each relationship.
## Metrics we trust, and ones we don't
Where each number comes from and how much to believe it.
## Decisions in flight
What is undecided, who decides, and by when.
## Stakeholders
Who needs to be involved in what, and how they prefer to be.
Implementation lead
A new implementation lead knows the compliance training. They need the customer history and the reasons the last rollout went the way it did. For digital health teams: draw this only from sources you have confirmed contain no PHI.
Add these sections
Customers you will work with. For each: where they are in rollout, what has happened so far, and who the people are.
Why the last rollout went the way it did. What slowed it, what was fixed, and what you would do differently.
Integration quirks and custom work. What was built for whom, and why.
What every security review asks. The recurring questions and where the answers live.
Handoffs. What sales promised, what implementation hands to support, and where those usually drift.
# Welcome, [Name]
## Why this role exists
What changed in the business that made us hire this role, and what success looks like at 90 days.
## The company in one page
What we sell, to whom, and the three things leadership is focused on this quarter.
## Your team
Who is on it, what each person owns, and who to ask about what.
## Who owns what
The systems, accounts, projects or services you will touch, with the current owner of each.
## Why things are the way they are
The decisions a newcomer would question (pricing, architecture, process), with the reason and a link to the thread or doc where it was decided.
## What is happening now
What is on fire, what is in flight, and what is deliberately paused.
## Your first 90 days
Week one, day 30, day 60, day 90. Specific work, not "get to know the team".
## People to meet
Name, role, why to meet them, and the one question to ask each.
## Open questions for your manager
What we know we haven't written down yet.
## Sources
A link to the thread, page or record behind every claim above.
## Customers you will work with
For each: where they are in rollout, what has happened so far, and who the people are.
## Why the last rollout went the way it did
What slowed it, what was fixed, and what you would do differently.
## Integration quirks and custom work
What was built for whom, and why.
## What every security review asks
The recurring questions and where the answers live.
## Handoffs
What sales promised, what implementation hands to support, and where those usually drift.
Relationship manager
A new relationship manager inherits a book of client relationships, and the history behind each one is the work. Keep every statement linked to its record, so the manager and an auditor can both check it.
Add these sections
Clients you inherit. For each: relationship history, products held, last contact, and open commitments.
Who each client trusts. The people at the client, and the people here they already know.
What has been pitched and declined. The offer, the date, and the reason given.
Commitments already made. Service promises, fee arrangements and anything agreed informally, with the record.
Procedures that apply. The relevant procedure for each client type, and where it was last applied.
# Welcome, [Name]
## Why this role exists
What changed in the business that made us hire this role, and what success looks like at 90 days.
## The company in one page
What we sell, to whom, and the three things leadership is focused on this quarter.
## Your team
Who is on it, what each person owns, and who to ask about what.
## Who owns what
The systems, accounts, projects or services you will touch, with the current owner of each.
## Why things are the way they are
The decisions a newcomer would question (pricing, architecture, process), with the reason and a link to the thread or doc where it was decided.
## What is happening now
What is on fire, what is in flight, and what is deliberately paused.
## Your first 90 days
Week one, day 30, day 60, day 90. Specific work, not "get to know the team".
## People to meet
Name, role, why to meet them, and the one question to ask each.
## Open questions for your manager
What we know we haven't written down yet.
## Sources
A link to the thread, page or record behind every claim above.
## Clients you inherit
For each: relationship history, products held, last contact, and open commitments.
## Who each client trusts
The people at the client, and the people here they already know.
## What has been pitched and declined
The offer, the date, and the reason given.
## Commitments already made
Service promises, fee arrangements and anything agreed informally, with the record.
## Procedures that apply
The relevant procedure for each client type, and where it was last applied.
How to fill it in without a three-hour project
Start from the last hire's questions. Whatever they asked in their first month is what the next one needs answered up front.
Link every claim. A statement with a link to the thread, ticket or record behind it can be checked. One without is an opinion.
Write the why, not just the what. "We use annual contracts" is a fact. "We moved to annual contracts after the 2024 churn thread" is context.
Have the manager read it before the new hire does. It takes a few minutes, and it is the part that keeps the document honest.
Or have Firstweek write it from your tools
Everything in this template is already written down somewhere: in Slack threads, Confluence pages, Jira tickets, Google Drive and your CRM. Firstweek reads those through read-only connections and writes the document for one new hire, with a citation behind every claim. The hiring manager approves it before day one. See a complete sample to compare it with what you would write yourself.
Questions
Short enough that the new hire reads it before day one: a few pages per role. Every section should answer a question they would otherwise ask a teammate.
The hiring manager knows the content; the hard part is finding it. Start from the Slack threads, tickets and CRM notes where decisions were made, and link each claim to its source so the new hire can check it.
Yes. Firstweek reads Slack, Confluence, Jira, Google Drive, GitHub and your CRM through read-only connections, writes the artifact for one new hire, cites every claim, and the hiring manager approves it before day one. A pilot runs on your next real hire: 30 days, then we talk.
Wondering what a new hire costs while they hunt for context? Run the numbers →
Run Firstweek on your next real hire. 30 days. Then we talk about whether it's worth keeping.