Build a 30/60/90 onboarding plan for a new hire
Turn a role and team context into a 30/60/90 day onboarding plan with named checkpoints, so a new hire knows what success looks like at each stage.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Naming a required checkpoint per phase turns the plan from a list of hopes into something with a verifiable end state, which is what actually lets a manager tell whether onboarding is on track.
- →Requiring goals specific to the named team and systems, instead of generic onboarding boilerplate, is what makes a 30/60/90 plan usable in week one rather than something the new hire has to reinterpret themselves.
- →Flagging under-specified goals instead of writing a vague placeholder gives the hiring manager a punch list of decisions they still need to make, rather than a plan that looks complete but silently isn't.
Part by part
- learning vs. contributing vs. owning
- Names what each phase is actually for. Without it the three periods become the same plan with more tasks, which is how a 30/60/90 becomes a backlog.
- not generic
- Explicit rejection of the filler this format attracts. Getting to know the team is not a goal, because there is no state in which it is complete.
- one named checkpoint
- A meeting, review or deliverable that marks the phase done. Without a checkpoint, phases blur and nobody notices a new hire is behind until month three.
- name the gap so the hiring manager can fill it in
- The guard. A plan full of invented system names and invented people reads as complete and cannot be executed.
Common mistakes
Write a 30/60/90 day plan for a new engineer.With no team context, every goal is generic — meet the team, read the docs, ship a small change. It is indistinguishable from a template and gives the new hire no sense of what this job actually is.
Write an onboarding checklist.A checklist covers access and accounts, which is administration rather than onboarding. The plan this prompt produces is about what someone should be able to do, which is a different document.
Write an ambitious onboarding plan.Ambition here means expecting ownership in the first month, which sets up a new hire to fail at something nobody could do. The phase framing exists precisely to sequence expectations.
Questions
Why does each phase need a checkpoint?
Because otherwise the plan has no failure signal. A named review or deliverable makes it observable whether the first thirty days went as intended, at a point where the answer is still actionable.
What team context is worth pasting?
The systems they will work in, the people they will depend on, and what the team is currently trying to ship. Those three turn generic goals into specific ones and are exactly what a template cannot supply.
Should the new hire see the plan?
Yes, on day one. Its main value is telling someone what success looks like before they have to infer it, which is otherwise the most stressful part of a new role.
Is thirty days too soon to contribute?
It depends entirely on the codebase and the role, which is why the prompt asks for a focus rather than fixing one. The point of the phases is that the expectation is stated rather than assumed differently by each side.