# A checklist for onboarding a new engineer > A checklist for onboarding a new software engineer: before day one, the first day, the first week and the first month, with a small first task. The first weeks decide how quickly a new engineer becomes useful and whether they feel they belong. Prepare before day one, and give them a small real task early. Web page: https://kansohq.app/guides/onboarding-a-new-engineer Updated: 5 October 2026 ## What onboarding is for Onboarding has three jobs: give the person what they need to work (accounts, access, a working environment), give them the context to make good decisions (the product, the codebase, the team’s habits) and help them feel part of the team. The first is easy to forget until day one, and the third is easy to forget altogether. ## Before day one - Accounts, access and equipment are ready and tested. - A buddy is chosen and has time set aside. - The first week’s calendar has the right meetings and no empty days. - A short note has gone to the team to say who is joining and when. - The first task is chosen, small and real. ## The first day - Welcome in person or on a call, and a walk through the day. - A working development environment by lunch. If it takes longer, fix the setup guide. - Meet the team, and say what each person does. - Read the product overview, and see the product being used. ## The first week - Ship something small: a fix or a tiny change, end to end, through review. - Read the key specs and [decision records](https://kansohq.app/guides/what-is-an-adr.md). - Pair with the buddy on a real task. - A check-in at the end of the week: what was unclear, what would have helped? ## The first month - Own a real piece of work, with a clear owner on the card. - Join [planning and the retrospective](https://kansohq.app/guides/how-to-run-a-retrospective.md). - A one-to-one at 30 days: how is it going, what do you need, what should we change? - Ask the new person to improve the onboarding doc. They see its gaps better than anyone. ## Keep the onboarding doc alive An onboarding document that is not updated is a trap. Make the newest person responsible for fixing every wrong step they hit, and review it each quarter. Link the doc from the team’s main page so it is easy to find. ## A 30-60-90 day plan | Period | The aim | What it looks like | | --- | --- | --- | | First 30 days | Learn | Set up, ship a small change, meet the team, read the key specs and decisions | | Days 30 to 60 | Contribute | Own a real piece of work, join planning and reviews, give feedback on the process | | Days 60 to 90 | Own | Lead a feature or a fix end to end, help the next new person, set goals for the next quarter | ## What goes in the onboarding doc - How to set up the environment, tested by the last new person. - A map of the product and the codebase, with links. - The team’s habits: how work is planned, reviewed and released. - Who to ask about what. - Where the specs, the decisions and the plans live. - The first-week plan and the first task. ## Mistakes to avoid - Leaving the first day empty, so the new person sits with a laptop and no plan. - Starting with the largest task in the codebase. Start small and finish it. - Assuming that silence means everything is clear. Ask, and ask again at the end of the first week. - A buddy who has no time set aside. A buddy needs hours, not good intentions. - Onboarding that ends after the first week, when the real questions are only starting. ## Onboarding in Kanso Write the checklist as a [doc](https://kansohq.app/product/docs.md) with to-dos, copy it for each new person and assign the first task on the [board](https://kansohq.app/product/boards.md). Add them to the right [chat](https://kansohq.app/product/chat.md) channels, give them a role that fits, and share read-only links to the key pages for anyone who is not yet a member. ## Questions ### What should an engineer onboarding checklist include? Accounts and equipment before day one, a working environment on the first day, a small real task in the first week, introductions and context, and check-ins at the end of the first week and the first month. ### How long should onboarding take? The first week sets up working, and the first month builds ownership. Most engineers are productive within one to three months, depending on the product and the codebase. ### What makes a good first task for a new engineer? Small, real and finishable in a few days, with a clear owner to ask. It should go through the whole process, from the board to review to release. ### Who should be a new engineer’s buddy? Someone on the same team, with time set aside, who is happy to answer simple questions and has been there long enough to know the answers. ## Keep reading - [How remote software teams stay in sync](https://kansohq.app/guides/remote-software-teams.md): How remote and distributed software teams stay in sync: write things down, make status visible, use chat well and keep meetings for decisions. - [What is an architecture decision record (ADR)?](https://kansohq.app/guides/what-is-an-adr.md): An architecture decision record (ADR) is a short note on a decision, why it was made and what follows. Learn the format, when to write one and examples. - [How to run a retrospective that changes something](https://kansohq.app/guides/how-to-run-a-retrospective.md): A retrospective is only worth it if something changes afterwards. Learn a simple format, how to run it in an hour and how to follow through. - [Meeting notes template: decisions and actions | Kanso](https://kansohq.app/templates/meeting-notes.md): A meeting notes template that puts decisions first, then actions with owners and dates, then discussion and parked topics. Copy it, or start it in Kanso. - [Decision record template (ADR) to copy | Kanso](https://kansohq.app/templates/decision-record.md): An architecture decision record (ADR) template with the decision, status, context, consequences and revisit condition. Copy it, or start it in Kanso. ## Parts of Kanso used - [Kanso Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release. - [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done. - [Kanso Chat](https://kansohq.app/product/chat.md): Channels and direct messages that link straight to the task, page or release being discussed. [Kanso home, with plans and prices](https://kansohq.app/index.md)