Overview
Onboarding is the support a team gives a new member until they can work autonomously within the organization. It covers the period from before the first day until the member moves their own work forward without step-by-step instruction. This page covers onboarding from the team’s side, not the learner’s. It first defines what onboarding aims for and how to manage it, then describes the preparation before the first day, how to support the first day, week, and month, and how AI agents change the work.What onboarding aims for
The goal of onboarding is a member who can work autonomously within the organization. Such a member knows how the team develops and makes decisions, where information lives, and whom to ask, and uses that knowledge to move their own work forward. Onboarding is the support that helps the member reach this state; finishing the reading material does not complete it. Working autonomously does not mean working without help. An autonomous member asks for help at the right time, raises problems early, and fixes the outdated documents they find. What onboarding removes is the dependence on step-by-step instruction, not collaboration. The first merged change is an early milestone on the way. Shipping one small change takes the member through the environment setup, the repository layout, the review process, and the release flow once, which reading about them does not replace. Removing obstacles on that path before the member arrives lets the onboarding period go to understanding the product and the organization instead.Set goals with completion criteria
Define what working autonomously means for the member as goals the mentor and the member can check together. Attach a rough completion criterion to each goal so that progress is visible.
Treat the criteria as guides, not pass marks. Adjust them to the member’s
experience and area (frontend, backend, infrastructure), and let the mentor
and the member make the final judgment in conversation. Set the expected
duration the same way: shorter for experienced members, longer for members
new to professional development.
Manage onboarding as a checklist
Keep the onboarding tasks in one checklist, such as an issue created from a template, and give each task an owner: the manager, the mentor, or the new member. A shared checklist shows what is done and what is blocked, and prevents preparation from depending on one person’s memory. Prepare a template for each kind of member whose needs differ, such as full-time employees, contractors, and interns. Contractors may not need production access, and a short internship may aim for a merged change on the first day instead of within the first weeks. At the start, the mentor and the member customize the checklist to the member’s goals. At the end, they look back on the onboarding together and feed what they learned into the template, so the next onboarding starts from an improved version. A sample template appears later on this page.At Findy, some teams manage onboarding with issue templates for full-time
employees, contractors, and interns, tagging each task with the person
responsible.
Preparation before the first day
Preparation is split between the manager, who handles accounts and organizational setup, and the mentor, who prepares the work itself.1
Request accounts and permissions in advance
Account issuance often takes days and depends on other departments.
Request access to code hosting, chat, cloud environments, the password
manager, design tools, and AI tools as soon as the start date is fixed.
Decide permissions by role: a contractor may need staging access only.
2
Make the development environment reproducible
Write the setup as commands or scripts rather than as prose, and keep them
current. Provide one ordered quickstart that covers obtaining secrets and
setting up AI tools, and points to each repository’s README. A setup that
only works with help from a specific person turns the first days into
waiting.
3
Bring the documentation up to date
Document task breakdown, pull request granularity, commit conventions,
and review practices, and review existing documents for outdated content
before the member arrives. An AI agent can draft the updates, which the
team then reviews. Values and practices that exist only in people’s heads
cannot be learned by reading the code.
4
Prepare starter tasks
Select two or three tasks that are neither trivial nor large, and name the
files to change. A task that applies the same kind of fix in several
places works well: the first fix is learned with support, and the rest are
repetition. Keep a stock of such tasks with a label such as “good first
issue” so that selection does not start from zero each time.
5
Assign a mentor and set up communication
Decide who answers questions and reviews the member’s changes. Agree in
advance that the mentor’s own output will drop during this period, so the
mentor is not judged against an unchanged expectation. Add the member to
recurring meetings and the necessary chat channels, and create a personal
channel where the member can log their work.
Supporting the first day, week, and month
The first day
Aim for a first pull request on the first day, even a documentation fix. On the first day:- Explain the development process, focusing on the rules that block a merge, such as required approvals.
- Have the member set up the environment by following the quickstart.
- Confirm that the member receives notifications for pull requests, reviews, and mentions.
- Schedule frequent one-on-ones with the mentor, and reduce the frequency once the member settles in.
- Start a starter task.
The first week
- Customize the onboarding checklist together with the mentor.
- Skim the documentation to learn what exists, rather than reading all of it.
- Set a recognizable chat name and icon, and configure review reminders.
- Arrange short one-on-ones with members across functions, such as sales, support, and planning, so that the member knows whom to ask.
The first month
- Confirm access to the monitoring, error tracking, and cloud tools.
- Learn the development process, the backlog, and the team’s metrics.
- Walk through the main user flows in the staging environment.
- Join reviews once the mentor judges the member ready, and carry out a release.
- Learn the rules for production data changes by pairing with the mentor.
- Handle one inquiry and one alert, if the member’s area includes them.
Day-to-day support
Give information in stages. Explaining the whole system on the first day overloads the member with context that has nothing to attach to yet; each piece of context is easier to absorb once a task needs it. Make asking for help the expected behavior. When the member’s personal channel, where they log what they are working on, the error they hit, and what they have tried, is open to the whole team, several people can offer help without being asked one by one. A useful rule of thumb is to ask after about 30 minutes of being stuck instead of continuing alone. Keep review fast. A starter task that waits days for review teaches nothing in the meantime. Small pull requests, automated checks, and automated releases all shorten the loop between a change and its feedback.At Findy, some teams hold regular retrospectives during onboarding and run
the resulting actions immediately, checking the effect at the next
retrospective.
Sample onboarding issue template
The following template puts the goals and tasks on this page into a checklist for full-time engineers on GitHub. Place it in.github/ISSUE_TEMPLATE/ and
adapt the tasks, tools, and completion criteria to your team.
.github/ISSUE_TEMPLATE/onboarding.md
Onboarding with AI
What AI changes
With an AI agent, a new member can explore an unfamiliar codebase, ask about its structure, and draft a task breakdown largely on their own. The time between joining and starting implementation becomes much shorter, and the mentor spends less time explaining code line by line. AI cannot supply what is not written down, such as the history behind an architecture or domain knowledge. Leaving that knowledge to the mentor’s explanations means repeating it for every new member, and the member’s AI agent cannot use it at all. Writing it down serves both.Prepare the context AI reads
Write down what has so far been passed on by word of mouth. Record architecture decisions together with the reasons behind them, and keep domain terms and business rules in a glossary. Store these documents where both people and AI agents read them, such as in the repository. Part of the mentor’s role is then to turn what they explain into documents, so that the next member does not need the same explanation. Document the team’s rules and package recurring workflows as skills, so a new member’s agent follows team practice from the first day. Include the AI tools in the quickstart so that setting them up is part of the environment setup. Keep cleaning up outdated code as well: an agent that reads old patterns in the codebase can reproduce them.Related pages
Task Breakdown
Break starter tasks into units small enough to merge one at a time — the
first thing a mentor works through with a new member.
Pull Requests
The right granularity is what lets a new member receive feedback every
day.
Code Review
How to return review quickly and clearly so a starter task never waits
for feedback.