Verified against ChatGPT · 2026-08-12
Build a first-two-weeks onboarding plan that gets a remote hire to their first real contribution, not just a meetings calendar
Produces a day-by-day onboarding schedule for a new hire's first two weeks, anchored to one concrete early contribution they'll make, instead of a generic checklist of orientation meetings that leaves the new hire unsure what they're actually supposed to be doing.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a day-by-day onboarding plan for the first two weeks of a new hire, for the role and context below. The goal is not just "complete orientation" — it's getting this person to one real, visible contribution before the two weeks are up, so they leave week two knowing they've already added value rather than just having sat through meetings.
ROLE AND START CONTEXT
Backend Engineer joining a fully remote, distributed-across-timezones platform team, starting the Monday after a long weekend.
TEAM STRUCTURE AND WHO THEY'LL WORK WITH
Manager is Alex; Jordan is the closest peer engineer who'll do most pairing; Sam owns the on-call rotation the new hire will eventually join.
SPECIFIC TOOLS/SYSTEMS ACCESS THEY NEED
GitHub org access, staging environment credentials, VPN, and read access to the incident-response runbook repo.
FIRST REAL CONTRIBUTION TARGET
Ship a small, low-risk bug fix to production with Jordan reviewing, even if it's just a one-line fix, so they've been through the real deploy process once.
What has gone wrong in past onboarding for this team
The last two hires didn't get staging access until day 5 because IT tickets sat unclaimed, which killed a week of momentum.
Build the plan across 10 working days. Days 1-2 should cover the unavoidable logistics (access, tooling, key introductions) but compress them — do not let orientation sprawl past day 2, since a new hire who is still doing pure logistics by day 4 loses momentum and starts to disengage. From day 3 onward, structure every day around building toward the stated first-contribution target: what they need to learn or shadow, who they need to talk to, and what small piece of real work they can start touching, even in a limited or supervised way, well before day 10. Name specific people from the team structure for specific days ("pair with Jordan on a live ticket") rather than generic placeholders like "meet with team members," since vague introductions are the exact thing that makes a new hire's first week feel unstructured. If a past onboarding failure is named, build a specific counter-measure into the relevant day rather than a generic "communicate clearly" fix.
END-OF-WEEK-TWO CHECK-IN
End the plan with a short structured check-in agenda for the manager to run at the end of day 10: what the new hire has learned, what they contributed, what's still confusing, and one thing the plan should adjust for the next new hire based on how this one actually went.
OUTPUT FORMAT
A table or day-by-day list (Day 1 through Day 10), each day with 2-4 concrete items, followed by the End-of-Week-Two Check-In agenda.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Onboarding research consistently identifies time-to-first-contribution as one of the strongest predictors of new-hire retention and engagement, because a new hire's sense of competence and belonging forms in the first two to three weeks and is driven far more by having done something real than by having attended orientation sessions — this is why the prompt structures the entire plan backward from a named first-contribution target rather than forward from a checklist of logistics. Capping pure logistics at two days addresses a specific, common failure pattern where IT provisioning delays and calendar-driven orientation sprawl silently eat the first week, so by the time real work starts the new hire has already disengaged or started to worry they were a bad hiring decision. Naming specific real people for specific days rather than "meet the team" placeholders matters because a generic introduction schedule produces exactly the kind of onboarding experience new hires describe as isolating even when every box was technically checked — a plan that says "pair with Jordan on a live ticket Wednesday" creates an actual accountable commitment that shows up on Jordan's calendar too, whereas a vague plan tends to quietly not happen. Feeding in a specific named past failure and requiring a counter-measure rather than generic advice forces the plan to fix the actual thing that broke last time (e.g., an access-provisioning bottleneck) instead of producing the same generic template that already failed to prevent it once. The structured end-of-week-two check-in closes the loop by turning the new hire's actual lived experience into an input for improving the next onboarding cycle, rather than treating the plan as a one-time artifact nobody revisits.
What you get back
Day 1: laptop/VPN setup, GitHub org access request submitted immediately (flagged urgent given past IT delays), intro call with Alex. Day 3: Jordan walks through the staging deploy process live. Day 7: pairs with Jordan on the identified low-risk bug fix, opens the PR. Day 9: Jordan reviews and approves; new hire ships to production with Jordan watching. Day 10 check-in: what surprised you this week, what's still unclear about the on-call rotation, one thing to change for the next hire.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
