> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # How to onboard new engineers so they can work autonomously > How a team supports new engineers until they can work autonomously in the organization: setting onboarding goals, manages preparation as a checklist, gets accounts, documents, and starter tasks ready before day one, and supports the first day, week, and month, including how AI agents change onboarding. ## 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. | Goal | Example completion criterion | | - | - | | Can use the accounts and environments needed for development | Can sign in to the staging and production tools with the required permissions | | Knows how the organization works | Can name whom to ask about each area and where its documents are | | Understands the main features and screens | Can explain what each main screen does and which APIs it calls | | Can ship small features and bug fixes | A team-agreed number of pull requests, including starter tasks, are merged | | Can work with CI/CD and releases | Has created, merged, and verified one release | | Can handle operational work | Has handled one inquiry and one alert | 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. 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. 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. 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. 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. 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. Ask the member to fix any document or procedure that does not match what they see. A newcomer notices outdated content that long-time members no longer read, so each onboarding keeps the documentation current. ### 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. ```markdown .github/ISSUE_TEMPLATE/onboarding.md theme={null} --- name: Onboarding (full-time) about: Onboarding checklist for a new full-time engineer title: "[Onboarding] " labels: onboarding --- Each task starts with its owner: `[Manager]` `[Mentor]` `[Member]`. Completion criteria are guides. The mentor and the member make the final judgment together, and may adjust them to the member's experience and area. ## Onboarding goals Expected duration: - [ ] [Member] Can use the accounts and environments needed for development - Criterion: can sign in to the staging and production tools - [ ] [Member] Knows whom to ask about each area and where its documents are - [ ] [Member] Can explain what each main screen does and which APIs it calls - [ ] [Member] Can ship small features and bug fixes - Criterion: pull requests merged, including starter tasks - [ ] [Member] Can work with CI/CD and releases - Criterion: has created, merged, and verified one release - [ ] [Member] Can handle operational work (if the member's area includes it) - Criterion: has handled one inquiry and one alert - [ ] [Mentor][Member] Look back on this onboarding and update this template ## Preparation before the first day ### Manager - [ ] [Manager] Request accounts: code hosting, chat, cloud, password manager, AI tools - [ ] [Manager] Create the member's personal work-log channel ### Mentor - [ ] [Mentor] Review the documentation for outdated content - [ ] [Mentor] Select 2-3 issues labeled `good first issue` - [ ] [Mentor] Add the member to recurring meetings and chat channels ## First day - [ ] [Mentor] Explain the development process and the rules that block a merge - [ ] [Member] Set up the environment by following the quickstart - [ ] [Member] Confirm notifications for pull requests, reviews, and mentions - [ ] [Member] Schedule one-on-ones with the mentor - [ ] [Member] Start a starter task and open a pull request ## First week - [ ] [Member] Customize this checklist with the mentor - [ ] [Member] Skim the documentation to learn what exists - [ ] [Member] Set a chat display name and icon, and configure review reminders - [ ] [Member] Arrange short one-on-ones with members across functions ## First month - [ ] [Member] Confirm access to monitoring, error tracking, and cloud tools - [ ] [Member] Walk through the main user flows in the staging environment - [ ] [Member] Join reviews and carry out one release - [ ] [Mentor][Member] Learn the rules for production data changes by pairing - [ ] [Member] Handle one inquiry and one alert (if the member's area includes them) - [ ] [Member] Fix any document that does not match what you see ``` ## 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](/ai/skill), 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 Break starter tasks into units small enough to merge one at a time — the first thing a mentor works through with a new member. The right granularity is what lets a new member receive feedback every day. How to return review quickly and clearly so a starter task never waits for feedback. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.