A 30 60 90 day plan template only works at a startup if you throw out the corporate version first. Here's the one that actually fits a five-person team with no HR department.
Most 30 60 90 day plan templates you'll find online were built for a Fortune 500 onboarding portal, with a slide deck, a mentor assigned by rotation, and a benefits orientation on day two. None of that applies when you're the fourth engineer at a startup and the founder is still answering support tickets. You don't have six weeks of shadowing to spare. You need the new hire contributing inside two weeks and fully load-bearing by day 90, or the hire was a mistake.
Stripe built its reputation partly on the opposite extreme: new engineers are expected to ship a real change to production code on their first day, sometimes within hours of getting their laptop. That's not a gimmick. It's a signal about what the first 90 days are actually for at a company that size, proving the person can operate inside real systems fast, not proving they can sit through a curriculum. A startup onboarding plan should borrow that instinct even if it can't copy the exact ritual. The goal isn't comfort. It's speed to real contribution.
The first 30 days are for context, not competence. A new hire cannot be expected to make good independent decisions in week one because they don't yet know why the company does things the way it does. Your job as the founder or hiring manager is to compress that context as fast as possible.
Concretely: get them access to everything on day one, not day five. That means the GitHub repo, the Notion or Linear workspace, Slack channels, the customer support inbox, and read access to recent board updates if you're comfortable with that level of transparency. Withholding access "until they're ready" just delays the moment they become useful. Some founders keep a new hire out of the shared Slack for the first week "to avoid noise," and all it does is teach the new hire that information here is rationed, which is exactly the wrong first lesson at a company that runs on speed.
Pair them with one person, not a rotating cast, for their first two weeks. At a five-person startup this is usually the founder or the most senior person on their team. The pairing isn't a training program. It's so the new hire has one person whose judgment they can borrow when they hit a decision they're not confident making alone.
By day 30, the bar is simple: they should have shipped something real, whether that's a merged pull request, a closed support ticket, or a signed customer call they ran solo. Not a mock project. Not a written summary of what they learned. Something that touched the actual product or the actual customer.
The 60 day mark is where most plans go vague
Most 30 60 90 day plan for new manager templates fall apart exactly here, because the 60 day column is usually filled with soft language like "build relationships" and "understand team dynamics." That's not a plan. That's a placeholder for one.
By day 60 a new hire should own a defined piece of the business, not just be assisting on one. If you hired an engineer, that means they own a feature end to end: they wrote the spec, shipped it, and are the person who gets paged if it breaks. If you hired a first sales rep, that means they're running their own pipeline with their own quota, not just sitting in on the founder's calls anymore. Ownership is the test, not tenure.
This is also the point where you should be checking in directly, not through a form. A fifteen minute conversation asking one question, "what's the dumbest thing about how we do X that you'd fix if you could," will surface more useful information than any structured feedback survey. New hires see inefficiencies that founders have stopped noticing, and by day 60 they've earned enough context to know which ones actually matter versus which ones they'd change just for comfort.
Remote and hybrid startups need one extra piece here that in-office teams get for free: a written record of decisions. Basecamp built its entire company culture around this idea long before remote work was normal, arguing in its own published writing that if a decision only exists in someone's memory, a new hire has no way to find it. If your team is distributed, the 30 60 90 day plan for a new manager or engineer has to include where decisions get written down, whether that's a changelog, a Notion doc, or old Slack threads pinned to a channel, because without it the new hire spends day 45 re-litigating a call your team made in week two.
None of this replaces judgment. A first 90 days new job plan is a floor, not a script. Some hires will clear the day 30 bar in a week. Others will need the full 30 days just to get comfortable enough to ship anything, and that's not automatically a red flag if the work they eventually produce is good.
By day 90, they should be training someone else
The real test of a 90 day plan isn't whether the new hire is competent by day 90. It's whether they could onboard the next person using what they learned. If they can write the checklist for the next hire in their role, they've internalized the job. If they still need you in the room for basic decisions, the plan failed somewhere in the first 60 days, and it's worth going back to find where.
This is also the moment to have the honest conversation, and it should happen on both sides. The new hire should be asked directly whether the job matches what they were sold in the interview. Founders routinely oversell the role during hiring because they're desperate to close the candidate, and by day 90 the gap between the pitch and the reality is fully visible. Better to surface it now than let it curdle into resentment at month six.
A simple template you can actually use
Skip the elaborate spreadsheet. A working 30 60 90 day plan template for a startup fits on one page and answers four questions for each phase: what will they own, who is their one point of contact, what does success look like in a sentence, and what's the single thing they need to ship or close by the end of that window. Fill in those four boxes three times, once per phase, and you have a plan a five-person team can actually run without a dedicated ops hire managing it.
Here's the honest part most guides skip: this only works if you're willing to have the hard conversation at day 90 if it's not working. A lot of founders extend the runway on a bad hire because writing the plan felt like enough process, and letting someone go after three months feels premature. It isn't. If the ownership test at day 60 wasn't met and the training test at day 90 wasn't met either, the plan already told you the answer. Trust it.
Also read: How to Structure Founder Vesting When You Bootstrap Then Raise Later • How Much Salary Should a Startup Founder Pay Themselves at Each Stage • How to Negotiate a SaaS Contract So You Never Get Locked In
