A 30/60/90 plan is owned outcomes, not a task list

When someone asks for a new-hire ramp plan — "write a 30/60/90 for the person starting Monday," "what should their first 90 days look like," "put together an onboarding plan for our new hire" — the base model produces a plan organized by activity: day 30 is set up your laptop, get your accounts, complete HR and compliance training, read the docs, meet the team, shadow a teammate; day 60 is start contributing and take on small tasks; day 90 is be fully ramped. Every line is something the person does or learns, and success is left fuzzy — "get up to speed," "be comfortable," "understand how we work."

That reads organized but answers the wrong question. A ramp plan exists so the manager and the hire agree on what this person will own and have delivered by each mark, and so anyone can tell at the 30-, 60-, and 90-day review whether they are on track. Setup tasks and training are prerequisites, not milestones. Rebuild the plan around three things the activity list leaves out.

1. Each period is an outcome the hire owns and delivers

State each of the 30/60/90 marks as what the person will own and what they will have shipped by then — a result you could point at — not the activities they performed to get there.

• Owned, not attended. "By day 30 you own triage for inbound bug reports and have closed your

first five," not "shadow the on-call rotation." Ownership means it is theirs to run, decisions included — not that they watched.

• Delivered, not learned. Replace "understand the codebase" / "get familiar with the product"

with a concrete first thing they shipped that proves the understanding: "merged your first change to production," "ran your first customer call solo," "published the analysis leadership asked for."

• Verifiable at the review. Each outcome should be something a manager could confirm at the

checkpoint without taking it on faith — a merged change, a live deal in the pipeline, a shipped document, a system they now run.

Setup and training still belong in the plan, but as the enabling work under a period, never as the milestone itself. The milestone is the outcome the setup unlocks.

The ramp arc: ownership widens, it does not just get busier

The three marks are not "learn, then help, then work." They are a widening scope of ownership toward the full charter the person was hired for — the thing they will own when fully ramped.

• By day 30 — first delivery in a bounded area. They own one scoped, low-blast-radius slice and

have shipped something real in it. Enough context to be productive on a defined piece, not the whole role. Owns: a narrow, well-fenced responsibility. Delivered: a first concrete result.

• By day 60 — running a real workstream independently. They own a genuine part of the role's work

and deliver it without step-by-step direction. Mistakes still get caught, but the person, not the manager, is driving. Owns: a live workstream. Delivered: results produced without hand-holding.

• By day 90 — performing the full role. They own the charter they were hired for and are

delivering at the level expected of the role, not a trainee version of it. This is the anchor: day 90 is defined as the role's actual outcomes, owned, which is what tells you the ramp worked. Owns: the core charter. Delivered: output at role level.

Tune the specific outcomes to the role — what a new account executive owns by day 90 (a working pipeline they built and their first closed business) is nothing like what a new staff engineer owns (a system or domain they are the go-to for). Anchor every plan on the day-90 charter first, then work backward to what day 30 and day 60 must deliver to get there.

2. A stakeholder map, not "meet the team"

"Meet the team" is not a plan. The hire needs a mapped set of the specific working relationships they must build to do the job, each with a reason. For every key person or role, give:

• Who — the name or role.
• Why they matter to this hire — what that person provides, unblocks, or decides that the new

person will depend on. ("Approves your pull requests and owns the deploy pipeline," not "senior engineer.")

• What the relationship is for — the working outcome, e.g. get unblocked on access, learn the

domain they own, the person you escalate customer issues to.

Cover the people the role actually depends on: the manager, the closest peers whose work interlocks with theirs, the cross-functional partners the role reaches into (a PM's design and engineering counterparts, an AE's sales engineer and CS partner), and — where the org uses one — an assigned onboarding buddy for day-to-day questions. The test: if the hire built exactly these relationships, could they get their day-90 charter done? If a dependency in the outcomes above has no matching relationship on the map, it is missing.

3. A check-in cadence with defined review points

Set an explicit rhythm for how the hire and manager stay aligned, not "check in from time to time." Two parts:

• Ongoing 1:1 rhythm — how often they meet and roughly what each covers. A workable default is

weekly 1:1s through the first month while context is thin, then settling to a steadier cadence. State the frequency; do not leave it implied.

• The 30 / 60 / 90 review checkpoints — three named reviews, one at each mark, where the outcomes

for that period are assessed against the plan: did the day-30 ownership and first delivery actually happen, is the person on track for day 60, and so on. Each checkpoint is a decision point — on track, needs support, or off track — not a status update. Say who is in each review (at minimum the manager) and that the standard is the owned outcome for that mark, not effort or attendance.

The cadence is what turns the plan from a document written on day one into something that is actually steered: the milestones are the targets, the check-ins are where reality gets compared to them and the plan gets adjusted.

What good looks like

A finished 30/60/90 plan has, for each of the three marks, a stated outcome the hire owns and something they will have delivered — verifiable at a review, tuned to the role, and building toward the day-90 charter — plus a stakeholder map of the relationships the role depends on with a reason for each, plus a check-in cadence with three named review points. If any period's milestone is an activity or a fuzzy "get comfortable," rewrite it as the owned outcome that activity is meant to produce. If there is no stakeholder map or no cadence, the plan is incomplete even if the milestones are good.