The Manager Writes the 30-60-90, Starting From the Loop's Open Question

What actually goes in a 30-60-90 day plan?

Four things, and only three of them are columns: the open question from the hiring debrief at the top, then day 30, then day 60, then day 90. The open question goes in one sentence with the evidence that would answer it. Day 30 tests comprehension. Day 60 is unsupervised work in one lane narrow enough to check cheaply. Day 90 is a decision about whether that lane gets wider.

Day 30 is comprehension, not output. The test is whether the person can predict what this team will say about a decision. Run it directly: take a decision the team made before they arrived, describe the situation without the outcome, and ask what was chosen and why. What you are grading is whether their reasoning names the constraints your team actually weighed, which is the thing generic competence cannot supply.

Day 60 is one lane, unsupervised. Pick the lane on how cheaply you can check it, and let importance wait until day 90. A weekly report with a known shape, a category of ticket where you can tell in two minutes whether the resolution was right, one client account you already understand. The point is that the work leaves your hands and you find out afterwards whether it should have, which is also the ramp date worth recording: the week you stopped reading their work before it went out.

Day 90 is a decision about scope. Three outcomes only: the lane widens, the lane stays where it is with a named gap and a date, or the relationship ends. That third outcome is a formal process, and it belongs with HR and counsel before day 90 arrives. A review that produces a feeling has produced nothing, and everyone in the room knows it.

The plan fits on one page. If it needs two, the second page is a list of things you would like to be true.

Who should write it, and when?

The hiring manager, before the start date, in under an hour. Not the candidate, not HR, and not the new hire in their first week. A plan written by the person who will be checking the work encodes what checking will look like. Anyone else is guessing, and the manager inherits the guess and calls it agreed.

The candidate-written version is a different artifact with a different use. Asking a finalist to build a 30-60-90 plan can be a real exercise, because watching somebody decide what to prioritise with incomplete information tells you something. It stops being an exercise the moment it becomes the plan, because at that point the priorities were set by the person with the least context in the building, under the incentive to look ambitious.

Timing matters more than length. Written before the start date, the plan is a set of intentions the manager can still change. By week two it has become a description of what already happened, and the first checkpoint has quietly moved to whenever somebody remembers.

The evidence that structured, extended onboarding tracks with staying is thin, and worth quoting at its actual strength. At one US employer, three cohorts of Associate Software Engineers showed one-year retention of 92% among the 184 who took a nine-month extended onboarding programme against 82% among the 261 who did not, a statistically significant difference the authors themselves describe as a small effect ³. Participation was elected rather than assigned, so the people who chose nine months of structure may be the people who were staying anyway. One employer, one job title, and mean engagement scores in the extended group were slightly lower. Treat it as encouragement to write the plan and nothing more.

Start the plan from the question your loop failed to settle

Every hiring loop ends with one thing two interviewers disagreed about, and that sentence is the most useful line in the file. Write it at the top of the plan, name what evidence would settle it, and put a week on the calendar when that evidence gets gathered. A plan that starts from the role instead starts from a document the candidate has already read twice.

The disagreement is usually specific and usually gets rounded off in the debrief. One interviewer thought the candidate's system design answer was rehearsed. Someone else could not tell whether the analysis in the work sample was theirs. Two people read the same answer about a failed project as candour and as blame-shifting. Whoever chaired the debrief made a call, the loop closed, and the sentence disappeared.

It is worth keeping because the specific content of what interviewers write down predicts something a rating does not. Text-mining post-interview notes on 7,650 candidates who were hired at a large Chinese internet technology company, researchers found that the number of job-related capabilities an interviewer named in the notes tracked later performance and promotions and moved inversely with turnover, with a one standard deviation rise in the note-to-job-analysis matching score corresponding to roughly a 2 percent rise in performance ¹. That is a small effect at one firm, in technology roles, over 2016 to 2018, and it is range-restricted by construction: only people who were hired could be observed. What it supports is narrow and useful: the named capability in the notes is the part worth carrying forward.

Writing it down also protects it from the way debriefs end. A meta-analysis of selection and admissions studies found an average correlation with job performance of .44 when applicant data were combined mechanically by a formula against .28 when the same kinds of data were combined holistically by expert judgment, across 9 studies for that criterion ². The finding is about how evidence is combined at the end, not about which evidence to gather, and a mechanical rule there can be as plain as a written checklist with equal weights. A debrief that ends in a group feeling is the holistic method wearing a meeting invitation. Keep the meeting, which is where the disagreement surfaces, and give it a written rule to land on.

One warning about the shape of the open question. It is now more often a capability question than it used to be, because a fluent work sample and a fluent interview answer no longer separate a person who has the model from a person who has the phrasing. If that is your question, write it as a behaviour you can watch, and read how to set a defensible bar for good enough in a specific role before you write the day-60 check.

Rewrite the 60 and 90 columns at every checkpoint

The 60 and 90 columns will be wrong, because the role moves and because what you learn at day 30 changes what is worth testing at day 60. Rewrite them at each checkpoint rather than defending them. A plan defended past its evidence turns into a document two people argue about in a performance conversation neither of them wanted.

What survives every rewrite is the top line. The open question either got answered, in which case write down what answered it and close it, or it did not, in which case the day-60 check exists to answer it and everything else in the column is negotiable. That is the difference between a plan and a schedule.

The checkpoint itself is thirty minutes and produces three sentences: what was checked, what it showed, and what changes. Send them to the person the same day. A new hire who has read the plan and both checkpoint notes cannot be surprised at day 90, and being unsurprised at day 90 is most of what a fair process amounts to.

One compression is worth resisting. When the plan and the probationary review are the same meeting, the plan quietly turns into a compliance artifact, which is a good reason to keep the two on separate dates and to know what the second one is actually for: what a probation period does and does not do. And if the hire is running most of their work through an assistant and you cannot yet tell what they know, the day-30 comprehension test is the wrong instrument on its own. Structuring the first 90 days for an AI-heavy hire covers what to substitute.

See the benchmarks >