30-60-90 Plan

A new hire's first three months went without a standard for a long time. Week one brings twenty document links and a set of accounts, and after that the only guidance is to ask if anything is needed. Nothing was neglected; there just wasn't anywhere that said what to accomplish by when. Someone who has never worked at a company this size has no way to calibrate what a reasonable first month even looks like.

Then week three produces this question: am I doing all right so far? The manager has no reference to answer from either, so the answer comes out as yes. Two months later, in the first review, both sides discover for the first time that they held different expectations. The manager assumed a feature would be owned by month two. The new hire understood the period as still learning.

The opposite failure is common too. Hand over real work from day one and someone with no context resorts to guessing, and what gets built that way gets rebuilt two weeks later.

A 30-60-90 plan cuts the three months into three stretches and writes the destination for each one in advance. Learning goes in the front, ownership in the back, and that ordering is the substance of it. The document does two things: it tells the new hire roughly where they are, and it tells the manager what to check and when.

Three stretches, and for each one a destination, the work that gets there, and a checkpoint. One page is enough, with three to five items per stretch.

1. Day 30 is the learning stretch. Documents to read, people to meet, and an exercise in actually using the product. Keep the destination small — for a new engineer, fixing one small bug and getting it into production. Naming the people to meet matters more than it sounds, because a new hire won't independently decide that a stranger on another team is worth thirty minutes.
2. Day 60 is the ownership stretch. One unit to run alone: a feature carried from start to release. This is the first stretch where somebody else is waiting on the result.
3. Day 90 is the judgment stretch. Reviewing other people's code, or proposing what to do next, belongs here. It's the point of crossing from processing what was assigned to helping decide what gets assigned.

The destinations differ by function. For a sales hire it might be running the product demo unaided at 30, taking a customer meeting solo at 60, and closing the first deal at 90. For a designer, documenting the rules already in the existing screens at 30, owning one screen at 60, and reviewing someone else's mockups at 90.

The checkpoints go in the document as well. Thirty minutes with the manager at day 30, 60, and 90, with the document open and the items read out. Leave the dates out and this conversation usually shrinks to one, on day 90.

Some things stay out. Performance ratings and company results don't belong here. Revenue or churn inside three months is not a number a new hire moves alone, and writing it in creates a position of being judged on something outside their control.

The manager writes it. The draft gets made during preboarding, once the start date is set, then read through with the person in week one and adjusted. Having the new hire write it themselves means setting targets without knowing how the company runs, and what gets written is usually undoable in the first month. That document works against them three months later.

The person who reads it most is the new hire. It isn't opened daily, but it's what gets opened when something is blocked, so keeping it somewhere easy to find makes a real difference. The senior colleague assigned through the buddy system reads it too — knowing which stretch someone is in tells them what to explain first.

On the manager's side it gets used in two places: the stretch checkpoints, and the decision at the end of probation. Without this document, the second one reverts to impressions. If nothing recorded what was expected across three months, nothing can be written about whether it happened, and three months is long enough that nobody remembers week one accurately by the end of it.

Revision is normal. Roughly half the items change at the day-30 checkpoint — the feature meant for handover slipped, or the person moved faster than expected and a day-60 item gets pulled forward. A document nobody revises gets opened once in week one and never again. After three months it closes, and growth from there is carried by an individual development plan.

"I've drafted your 30-60-90. Let's read it together in week one and fix it."

Confirming the order: the manager writes first, then it gets aligned with the person.

"The day-60 item looks early. I'll move owning a feature out to around day 70."

Adjusting a destination at a checkpoint.

"This isn't a scorecard, it's a reference. For items you missed we only look at why."

Making clear that nothing here is being graded.

Pagedeck started writing these after two engineers left inside three months. What Mia found in the exit interview notes wasn't pay or difficulty. Both people said they never knew whether they were tracking to expectations.

Theo built the engineering draft. The core of it was three lines: one small bug in production by day 30, one feature owned by day 60, reviewing someone else's code by day 90. Reading it in week one with the next hire moved one day-60 item later, and the day-30 checkpoint added two names to the list of people to meet.

The most common reading is that this is the probation scorecard. The three-month span overlaps and the checkpoints look similar, so that's how it lands. But the document states destinations in advance rather than assigning points. Read as a scorecard, a new hire asks fewer questions and works only the listed items. Left uncorrected, three months pass with unasked questions, and the things that actually needed checking go unchecked. A reference someone can read and argue with does the opposite: questions arrive early, while there is still time to act on the answers.

The other reading treats it as write-once. The word plan invites that. But a plan written before someone started is supposed to diverge from the actual schedule — the feature meant for handover slips, or the person moves faster, usually inside the first month. Left uncorrected, the document drifts from reality and becomes a file nobody opens on day 90.