{"id":430,"date":"2026-08-28T14:04:42","date_gmt":"2026-08-28T14:04:42","guid":{"rendered":"https:\/\/talently.tech\/en\/blog\/day-60-placement-review\/"},"modified":"2026-08-28T14:06:03","modified_gmt":"2026-08-28T14:06:03","slug":"day-60-placement-review","status":"publish","type":"post","link":"https:\/\/talently.tech\/en\/blog\/day-60-placement-review\/","title":{"rendered":"Placement review at day 60: what good looks like"},"content":{"rendered":"Reading Time: <\/span> 6<\/span> minutes<\/span><\/span>\n

Most managers evaluate a new engineer on feel for two months, then act surprised at the quarterly review. A placement is either working or not by day 60, and you can tell which in about an hour. Here is the checklist, the failure modes that are your fault rather than theirs, and what to do when the answer comes back bad.<\/p>\n\n\n\n

\n

TL;DR<\/h2>\n
  • Day 60 is the decision point.<\/strong> Ramp excuses have expired, and you can still correct or replace without burning the quarter.<\/li>
  • Use a milestone ladder, not a feeling.<\/strong> Environment running day 1, merged PR by day 7, reviewing other people’s code by day 30, an incident touched by day 60.<\/li>
  • Judgment signals beat output signals.<\/strong> The first estimate that held and the first pushback on a bad ticket say more than 22 closed tickets.<\/li>
  • Half of bad day-60 reviews are the manager’s fault.<\/strong> No named owner, an ambiguous ticket queue and stalled access requests look exactly like a weak hire.<\/li>
  • When day 60 looks bad, write a two-week correction plan.<\/strong> One owner, three scoped tickets, a definition of done. If nothing moves, replace by day 75.<\/li>
  • Time zone overlap makes these checks observable live.<\/strong> With a LATAM engineer on your calendar, you watch judgment happen instead of inferring it from a Jira export.<\/li><\/ul>\n<\/div>\n\n\n

    Why day 60 and not day 30 or day 90<\/h2>\n\n\n

    At day 30 every problem still has an innocent explanation, and weak hires and strong hires look nearly identical because both are asking questions and shipping small things. Judging then mostly produces false negatives on good seniors, who spend their first three weeks reading code instead of closing tickets.<\/p>\n\n\n\n

    At day 90 you have already spent the quarter. Whatever the placement was supposed to unblock is a quarter late, and the conversation with your VP is about the miss rather than the fix.<\/p>\n\n\n\n

    Day 60 gives you two sprint cycles, one release and usually one incident, enough history for patterns to repeat, and it still leaves two or three weeks to run a correction plan or swap the person before the quarter closes. Put the review on the calendar in week one and tell the engineer what it measures.<\/p>\n\n\n

    The milestone ladder<\/h2>\n\n\n

    Each rung is a binary, timestamped event. You are not scoring effort. You are checking whether the event happened.<\/p>\n\n\n\n

    Milestone<\/th>What you should see<\/th>If it is missing<\/th><\/tr><\/thead>
    Day 1<\/strong><\/td>Environment running, tests passing locally, repo and Slack access<\/td>Stale docs or an IT bottleneck, almost never the engineer<\/td><\/tr>
    Day 7<\/strong><\/td>First merged PR in main. A config change counts.<\/td>No starter ticket, or nobody reviewed it<\/td><\/tr>
    Day 14<\/strong><\/td>Something a user can see, plus a question that exposed a gap in your docs<\/td>The earliest real warning. Lost engineers go quiet.<\/td><\/tr>
    Day 30<\/strong><\/td>First PR reviewed by<\/strong> them, not for<\/strong> them, with a comment that changed the code<\/td>Still treated as a guest. Add them to the review rotation.<\/td><\/tr>
    Day 45<\/strong><\/td>On-call shadow done, or an incident touched as a second pair of eyes<\/td>You are keeping them off your real system<\/td><\/tr>
    Day 60<\/strong><\/td>An estimate they gave that held, and one bad ticket they pushed back on<\/td>The rung that matters most<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    The day-60 rungs differ in kind. Anyone can merge a config change. An estimate that survives contact with the codebase means they can predict the system, and pushing back on a bad ticket means they know the product well enough to see it is bad and feel safe enough to say so. An engineer who has never said “this does not make sense, here is what I think you actually want” is either getting perfect tickets or has decided disagreeing is risky.<\/p>\n\n\n

    Output signals vs. judgment signals<\/h2>\n\n\n

    Output signals<\/strong> are countable: tickets closed, PRs merged, points burned. Judgment signals<\/strong> are behavioral: what they pick up when the queue is ambiguous, what they refuse, what they escalate.<\/p>\n\n\n\n

    Teams over-weight throughput in the first two months for a boring reason: it arrives pre-aggregated in a dashboard, while judgment requires reading PR comments and sitting in standup. A mid-level engineer who cherry-picks small tickets posts great month-one numbers and stalls at month five. A strong senior posts mediocre numbers because week three went into fixing the thing everyone else routes around, then carries the team from month three.<\/p>\n\n\n\n

    Weight judgment at roughly 70% of the day-60 call. Five checks: did they improve someone else’s code in review, did an estimate hold, did they say no to something, did they escalate a blocker within 24 hours, and can they explain a part of your system that was not in the onboarding doc.<\/p>\n\n\n

    Healthy at day 60 vs. quietly not working<\/h2>\n\n\n

    The failing case is rarely dramatic. Nobody misses a deadline loudly.<\/p>\n\n\n\n

    Signal<\/th>Healthy at day 60<\/th>Quietly not working at day 60<\/th><\/tr><\/thead>
    Code review<\/strong><\/td>Comments that change other people’s code<\/td>Approves in minutes, or never reviews<\/td><\/tr>
    Estimates<\/strong><\/td>Gives a range, hits it, flags slips early<\/td>Says “should be fine,” then delivers late without warning<\/td><\/tr>
    Ambiguity<\/strong><\/td>Takes a vague ticket, returns a scoped proposal<\/td>Waits for someone else to rewrite the ticket<\/td><\/tr>
    Incidents<\/strong><\/td>Has opinions on the call, writes part of the postmortem<\/td>Present, silent, adds nothing to the doc<\/td><\/tr>
    Ownership<\/strong><\/td>Teammates route questions about a component to them<\/td>No component belongs to them after two months<\/td><\/tr>
    Pushback<\/strong><\/td>Has said no, with a reason, at least once<\/td>Has never disagreed with anything<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Two or three rows in the right column is a correction plan. Five is a replacement conversation.<\/p>\n\n\n

    The failure modes that are yours, not theirs<\/h2>\n\n\n

    Four manager-side failures produce symptoms identical to a weak hire:<\/p>\n\n\n\n

    1. No owner assigned.<\/strong> Nobody is accountable for the ramp, so everyone assumes someone else is answering the questions.<\/li>
    2. A ticket queue of ambiguous work.<\/strong> They got the tickets nobody else wanted because nobody could figure out what they meant.<\/li>
    3. Access requests unresolved for weeks.<\/strong> They cannot run staging, so they guess, and their PRs get rejected.<\/li>
    4. No written context.<\/strong> Your architecture lives in the heads of two engineers who are always in meetings.<\/li><\/ol>\n\n\n\n

      Three diagnostics separate these from a real performance problem. Ask the engineer to name who they go to when blocked, because hesitation means you never assigned an owner. Pull their last ten Slack questions: a median response over four hours makes it your team’s problem. Then check your last two hires, because if they showed the same pattern, this engineer is the third data point, not the cause.<\/p>\n\n\n

      What to do when day 60 looks bad<\/h2>\n\n\n

      Have the conversation that same week and name the missing milestone: “You have not reviewed anyone else’s PR in eight weeks, and the last two estimates slipped without a heads-up.” Then ask what is making this hard and stop talking. Half the time the answer is fixable in a day, like a permission that never arrived or a teammate who has been ignoring them.<\/p>\n\n\n\n

      Then write a two-week correction plan<\/strong>: one named owner, three scoped tickets with an explicit definition of done, one recurring 30-minute pairing session, and the exact behaviors you will check when it ends. Send it in writing, because an undocumented plan leaves you worse off with both the engineer and your staffing partner if you later replace.<\/p>\n\n\n\n

      At day 75, decide. Replace if the same milestone is still missing after the blockers were removed, if judgment signals stayed flat, or if this person absorbs more supervision than the rest of the team combined. Correction plans work when the problem was environmental, and one is enough. Do not run a second.<\/p>\n\n\n

      Using time zone overlap as a measurement tool<\/h2>\n\n\n

      Most of these checks require watching someone think, which is where a nearshore LATAM placement gives you something you should actually use. With four to six hours of daily overlap, you can put the engineer in a live design review, an incident call and a pairing session in one week, and watch the estimate get made and the pushback happen in real time.<\/p>\n\n\n\n

      Teams throw this away constantly. They hire in Bogota or Lima for the overlap, then run the relationship through Jira tickets and a written standup, exactly as they would with a 12-hour difference. At day 60 they have only throughput, so they get it wrong in both directions: keeping someone who closes tickets and cannot think, or cutting someone whose best work never had an audience. Hold both reviews as live video conversations inside the overlap window, and put the engineer on at least one incident call and one design review where they are expected to speak.<\/p>\n\n\n

      Frequently Asked Questions<\/h2>\n\n

      Is day 60 too early to judge a senior engineer on a complex legacy system?<\/h3>\n\n\n

      The ladder accounts for complexity. A senior on a 15-year-old monolith may have shipped less, but the judgment checks still apply: reviewing others’ code, giving estimates that hold, naming the dangerous parts of the system. If they cannot describe your architecture’s problems after two months, that is the finding.<\/p>\n\n\n

      What if the engineer is doing well but the team has not accepted them?<\/h3>\n\n\n

      That shows up as good individual output, no ownership of any component, and no questions routed to them. Assign a component publicly and add them to the reviewer rotation. If it persists at day 90, moving the engineer to another squad usually beats moving them out.<\/p>\n\n\n

      Should the engineer see the day-60 criteria in advance?<\/h3>\n\n\n

      Yes, on day one. Publishing the ladder removes the most common excuse, which is that nobody said what good looked like. Engineers who know the day-30 rung is reviewing other people’s code start doing it in week three.<\/p>\n\n\n

      What if we missed the window and we are already at day 100?<\/h3>\n\n\n

      Run the same review now and check the ladder retroactively, since those events either happened or they did not and the timestamps sit in your Git history and Slack. Then compress the correction plan to two weeks and hold the date.<\/p>\n\n\n

      Should our staffing partner be involved in the correction plan?<\/h3>\n\n\n

      Tell them at the start of the plan, not at the end. A good partner often has context you lack, and if replacement becomes necessary they have already started. Waiting until day 75 to make that call is how a two-week gap turns into six.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Reading Time: <\/span> 6<\/span> minutes<\/span><\/span>A placement is either working or not by day 60. Here is the milestone ladder, the judgment signals that matter more than ticket counts, the manager-side failure modes that look exactly like a weak hire, and what to do when the review comes back bad.<\/p>\n","protected":false},"author":3,"featured_media":111,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[6],"tags":[],"class_list":["post-430","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hiring-challenges"],"_links":{"self":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts\/430","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/comments?post=430"}],"version-history":[{"count":2,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts\/430\/revisions"}],"predecessor-version":[{"id":434,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/posts\/430\/revisions\/434"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/media\/111"}],"wp:attachment":[{"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/media?parent=430"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/categories?post=430"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/talently.tech\/en\/blog\/wp-json\/wp\/v2\/tags?post=430"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}