A useful fact about onboarding is that some of the best-run companies publish exactly how they do it. GitLab’s entire handbook is public. Stripe’s CEO has stated its engineering throughput on stage. Shopify’s first-week expectations have been written up in detail. When you line the accounts up, the structure is more consistent than the volume of 30-60-90-day templates online would suggest, and the consistent part is not the calendar. It is the order of operations: context first, a small real thing second, the actual job third, a deliberate review fourth.
The number that frames why this matters is grim. As a 2026 developer-onboarding analysis summarizing published processes from Shopify, GitLab, and Stripe notes, only 12% of employees rate their onboarding as great, a Gallup finding, while the typical time to a first meaningful pull request runs one to three months. The gap between those two numbers is what a structured first month is for.
Week one is context, not training
The most counterintuitive lesson comes straight from GitLab, and it is stated plainly in the public GitLab Handbook: “We don’t expect you to hit the ground running from day one.” GitLab recommends taking “at least two full weeks for onboarding and only in week three starting with team specific onboarding and training.” New hires are told they can participate in their team’s work in the first two weeks but should not “feel like you have to contribute heavily.”
That is a remote, all-async company being explicit that the first stretch is for absorbing context, not producing output. The mechanics support it. Onboarding at GitLab runs through a single tracked issue with a 30-day due date, opened “at least 4 days prior to the hire date,” with a main section common to everyone and department-specific tasks below. Every new hire gets an onboarding buddy whose first job is to schedule a call, matched across time zones so someone is “ready and waiting” when the new person logs on. Access is provisioned on a schedule, with an Access Request generated on Day 2.
The point is that context is treated as work with a structure, not as a pile of documents and a cheerful “ask if you need anything.” The failure mode is familiar enough that the founder of the HR tool FirstHR opened a March 2026 guide by confessing to it: handing every new hire a laptop, saying “ask if you need anything,” and watching them get frustrated by month two and leave by month four. Not bad hires. No roadmap.
Week two is shipping something small
The second move in the pattern is the one most teams skip: ship something real, soon, but small. Not because the change matters, but because shipping is the test that proves the context took.
Shopify is the named example. The same developer-onboarding analysis reports that Shopify “gets new developers shipping to production in their first week,” against an industry baseline where first meaningful PRs take one to three months. The mechanism that makes a first-week ship safe is not heroics. It is pre-boarding: hardware shipped and pre-configured, accounts provisioned, and a development environment that runs with a one-command setup before Day 1. Stripe ships pre-configured laptops so engineers “can log in and find their development environment ready.” The small first ship is only possible because the friction was removed in advance.
Stripe’s broader engineering culture explains why small is the operative word. Per PullNotifier’s writeup, Stripe merges an average of 1,145 pull requests a day, a figure CEO Patrick Collison shared at Stripe Sessions 2025, and the company organizes around small teams of five to eight engineers owning distinct product areas, working in a large Ruby monorepo with independent deployment via feature flags. The culture runs on small, frequent PRs rather than large ones. (PullNotifier is careful to note the figure comes from Stripe’s public statements and accounts from former engineers, and that the implementation details are blueprints, not Stripe’s exact internal config. We treat it the same way.) A new hire’s first merged PR fits naturally into a system already built for micro-changes, which is exactly why it works as an early test rather than a risky event.
Ship something real, soon, but small. Not because the change matters, but because shipping is the test that proves the context took.
Week three is the real work
By the third week the GitLab model has the new hire moving into team-specific work, and this is where the plan stops being onboarding and starts being the job. The shift is deliberate, not gradual drift. Weeks one and two earned it: context absorbed, one small thing shipped, the environment proven to work.
What carries a person through this transition, by the accounts of people who have joined startups, is motivation of a specific kind. First Round Review’s compilation, 30 tips from people who have joined startups, is blunt about the conditions. Shippo CEO Laura Behrens Wu describes the experience as “building the jet engine while you’re flying the plane. And likely there’s also a fire on the plane.” Plaid’s Head of People McKenna Quint adds the warning that matters for week three: people “motivated by structure and following traditional career growth paths” will not last, while those motivated by “the mission, customer delight and driving impact” will. The plan provides structure for the first two weeks precisely so the person can operate without it by the third, in an environment that does not offer much.
Week four is review, and it has to be scheduled
The fourth move is the one that decides whether the first three stuck: a deliberate review. Not a vague “how’s it going,” but a scheduled checkpoint against the expectations set on Day 1. The 30-60-90 framing that the templates converge on, summarized cleanly in the FirstHR guide as learn (days 1-30), contribute (days 31-60), and own (days 61-90), only works if someone checks at each boundary. Each phase, the guide argues, should carry three to five specific, measurable goals, the whole plan should fit on one to two pages, and it should be co-created with the person it is for rather than handed down.
The co-creation detail is the one small teams get wrong most. A plan written by the manager alone is a checklist. A plan written with the new hire is a shared expectation, which is what makes the 30-day review a conversation about a known target rather than a surprise verdict.
Scaling it down
Every named example here is a large company. The instinct on a five-person team is that this is overhead you cannot afford. The pattern argues the opposite, because the expensive parts are the ones a small team can borrow for free.
The structure is mostly documentation and sequencing, not headcount. A small team does not need a People Operations function to copy GitLab’s single-tracked-onboarding-issue idea; a shared doc with a 30-day due date does the same job. It does not need Stripe’s monorepo to make a first-week ship possible; it needs the environment to run with one command before Day 1, which is a half-day of preparation that pays back on every future hire. It does not need a formal buddy program to assign one existing person to be reachable in the first week. The four moves, context then a small ship then real work then a scheduled review, require ordering and intent, both of which are cheaper at five people than at five thousand.
What does not scale down is skipping the structure. The 12% Gallup number is not a big-company problem. It is what happens whenever a new person is handed a laptop and a wish of good luck, and small teams do that more often than large ones because they assume informality is the same as flexibility. The published playbooks suggest it is not. The order of the first month is the same whether you are GitLab or a team of four, and the team of four is the one that can actually follow it.
