by OnboardPlan (LX AI)
Last updated: 2026-10-03
A 30/60/90 plan managers actually use
OnboardPlan builds a 30/60/90 day onboarding plan by role — what the new hire should learn, do, and own, with check-ins and a first-week checklist.
Decision-support only — confirm before you publish or act.
Why a role‑based 30/60/90 plan matters
When I started OnboardPlan I noticed that generic checklists left managers guessing what a new hire should actually achieve. A role‑specific plan turns vague expectations into concrete milestones that can be tracked week by week.
Learning objectives
- Identify the core knowledge areas required for the role (systems, processes, domain concepts).
- Prioritize topics that enable early contribution versus deep expertise.
- Align learning with the team’s current sprint goals so the hire can apply knowledge immediately.
Doing objectives
- Define small, deliverable tasks that produce visible output in the first two weeks.
- Pair each task with a mentor or buddy who can give rapid feedback.
- Measure completion by concrete artifacts (code pull request, design mockup, support ticket resolution).
Ownership objectives
- Clarify which outcomes the new hire will own after 30, 60, and 90 days.
- Set up a lightweight review cadence (weekly check‑in, monthly demo) to confirm ownership transfer.
- Document hand‑off criteria so the manager knows when the hire can operate independently.
By separating learning, doing, and owning we give managers a clear signal to watch and a structure to coach.
How OnboardPlan generates the plan
The tool starts with a role taxonomy that maps job titles to skill blocks. Each block contains three columns: learn, do, own. I built the taxonomy from public job descriptions, internal competency matrices, and a few open‑source frameworks.
When a manager selects a role, OnboardPlan pulls the corresponding blocks and layers a time‑based progression:
- Week 1 focuses on orientation and setup.
- Weeks 2‑4 add foundational learning and first deliverables.
- Weeks 5‑8 expand scope and increase ownership.
- Weeks 9‑12 consolidate expertise and prepare for independent leadership.
To keep the suggestions relevant I cross‑check the generated content against two external sources:
The final output is a simple markdown‑style list that the manager can copy into a task tracker or print as a one‑page sheet.
Table: Role → Skill block example
| Role |
Learn (weeks 1‑4) |
Do (weeks 5‑8) |
Own (weeks 9‑12) |
| Backend Engineer |
API design, auth protocols, database basics |
Build a CRUD service, write unit tests, deploy to staging |
Own a microservice, set SLOs, mentor a junior |
| Product Designer |
Design system components, user research methods |
Create high‑fidelity mockups, run usability test, iterate |
Own a feature area, maintain component library, guide dev handoff |
| Customer Support Lead |
Product knowledge base, ticketing tool, escalation matrix |
Handle live tickets, draft knowledge articles, run weekly team sync |
Own support metrics, improve response time, coach new agents |
First‑week checklist (day‑by‑day)
The first week is about removing friction and building confidence. I list each day with a concrete action and a verification step.
Day 1 – Setup
- Receive hardware, install required software, configure VPN.
- Verify: can log into internal wiki and access email.
- Read the team charter and note one question for the manager.
Day 2 – Orientation
- Attend the 30‑minute welcome call with the manager and buddy.
- Verify: can name three team members and their primary responsibilities.
- Complete the security awareness module and capture the completion badge.
Day 3 – Learning fundamentals
- Complete the assigned “intro to our stack” video series (total 45 min).
- Verify: can explain the data flow from frontend to backend in own words.
- Write a one‑paragraph summary and share it in the #new‑hire channel.
Day 4 – First small task
- Pick a labeled “good first issue” from the backlog (e.g., typo fix, documentation update).
- Verify: can create a branch, make the change, open a pull request, and receive at least one comment.
- Respond to the comment and push the fix.
Day 5 – Reflection and planning
- Meet with the buddy for a 15‑minute retro: what worked, what was confusing.
- Verify: can list two things to improve for next week.
- Update the personal onboarding checklist with any new items discovered.
At the end of day 5 the manager should have a clear signal that the hire can navigate the environment, follow basic processes, and contribute a tiny but real change.
30‑day milestones: learn, do, own
By the end of the first month the hire should have moved from orientation to early contribution.
Learn
- Complete the role‑specific learning path (typically 8‑10 hours of video or reading).
- Demonstrate understanding by answering a short quiz created by the team lead.
- Explain one architectural decision that affects their daily work.
Do
- Deliver at least two small, production‑ready features or fixes.
- Participate in two code reviews as a reviewer, leaving actionable feedback.
- Attend the sprint planning and retrospective meetings and speak up at least once.
Own
- Take responsibility for the quality of their own deliverables (write unit tests, verify in staging).
- Own the update of a single piece of documentation (e.g., API guide, runbook).
- Schedule a 30‑minute demo with the manager to show what they have built and receive feedback.
60‑day milestones: learn, do, own
At two months the hire begins to stretch beyond the comfort zone and take on broader context.
Learn
- Complete an intermediate module that covers cross‑team dependencies (e.g., how the platform interacts with data pipelines).
- Shadow a peer from a related discipline for half a day and note one insight.
- Lead a 10‑minute knowledge‑share session on a topic they mastered.
Do
- Own a medium‑sized feature that spans at least two components (frontend + backend, or API + UI).
- Reduce the cycle time of their pull requests by 20 % compared to the first month (measured by time from open to merge).
- Contribute to a process improvement (e.g., update the definition of ready, suggest a checklist tweak).
Own
- Be the primary point of contact for a non‑critical but recurring support question from another team.
- Maintain the feature flag for their work, toggling it on/off based on release schedule.
- Prepare a short presentation for the next all‑hands showing impact (metrics, user feedback).
90‑day milestones: learn, do, own
By the end of the quarter the hire should be operating as a full team member with clear ownership.
Learn
- Finish any advanced learning tracks relevant to career ladder (e.g., security fundamentals, performance tuning).
- Earn an internal certification or badge if the role offers one.
- Mentor a new hire on one specific task, reinforcing their own knowledge.
Do
- Lead a feature from idea to release, coordinating with product, design, and QA.
- Improve a system metric (latency, error rate, conversion) by a measurable amount tied to their work.
- Participate in an incident post‑mortem and own an action item.
Own
- Own the quarterly goal for their squad (e.g., increase adoption, reduce churn).
- Conduct a one‑on‑one with the manager to discuss career aspirations and next steps.
- Document lessons learned from the first 90 days and add them to the team’s onboarding wiki.
What this is NOT
I want to be clear about the limits of the tool so managers do not mistake it for something it is not.
- It does not guarantee that a new hire will be productive in exactly 30 days. Individual aptitude, team context, and external factors still play a role.
- It does not replace a manager’s judgment. The output is a starting point; you must review and adapt it to your specific situation.
- It does not promise 100 % completion of every checklist item. Some items may be deferred or combined based on reality.
- It is not a substitute for a formal performance review or career‑development plan. It focuses on the onboarding window only.
- It does not claim to be a cutting‑edge AI system that never misses a risk. The checks against OWASP and NIST are helpful but not exhaustive.
Operator checklist for A 30/60/90 plan managers actually use
I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.
Before you change production
- Freeze the branch or config revision you will measure against.
- Record the current failure mode with one concrete input and one concrete output.
- Confirm which identity the job runs as, and whether that identity can reach data it should not.
- Open the primary references you will cite: https://owasp.org/www-project-top-10-for-large-language-model-applications, https://www.nist.gov/itl/ai-risk-management-framework.
While you run the check
- Prefer one reproducible path over ten anecdotal screenshots.
- Write the expected safe outcome before you trigger the tool or query.
- Capture the exact command, prompt, schema, or regex under test — not a paraphrase.
- If the system can act (send, write, delete, transfer), require a confirmation boundary in the same pass.
After you finish
- File residual risk with an owner and a date, even when the scan is clean.
- Do not convert a green check into sales language that claims completeness.
- Re-run the same checklist when the model, tool schema, or validation rules change.
| Signal | What to record | Stop-ship? |
|---|
| Unexpected write or send | Tool name, args, identity | Yes until gated |
| Missing confirmation on destructive action | Call path and bypass | Yes |
| Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach |
| Scanner clean, judgment open | Deferred items + owner | Only if core path safe |
onboardplan helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.
How I explain limits to buyers
When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.
If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.
References
FAQ
What is the main point of A 30/60/90 plan managers actually use?
OnboardPlan builds a 30/60/90 day onboarding plan by role — what the new hire should learn, do, and own, with check-ins and a first-week checklist.
How does A 30/60/90 plan managers actually use help?
Decision-support only — confirm before you publish or act.
Want to try the product? OnboardPlan
Generated 2026-09-17 · primary sources only · no fabricated traffic metrics