Developer Onboarding: The 30-60-90 Day Plan That Gets New Engineers Productive Without Accidents
Why a developer onboarding plan pays for itself
A mid-level engineer who joins a SaaS team and gets no structured onboarding typically takes four to six months to reach the output the hiring manager budgeted for at month two. Multiply the salary gap by the number of hires in a year and the cost of a weak developer onboarding plan is bigger than most tooling budgets. The second cost is quieter. Senior people who spend their first month fighting a broken local setup and guessing at unwritten conventions start updating their CV early. They rarely say so in the exit interview.
The plan below is calibrated for a SaaS engineering team of roughly five to forty people with a production system that customers depend on. It is split into the first week, the rest of the first month, the second month and the third month. Each phase has a goal, a set of concrete activities and one question the team lead should be able to answer at the end. It does require someone to own it, and that person should be an engineer, not a coordinator.
Days 1 to 7: the environment is a quality indicator
The first week has one technical goal: the new engineer runs the full application locally, executes the test suite and ships a trivial change to production. If your team cannot make that happen inside five working days, the onboarding problem is not an onboarding problem. It is a codebase problem, and it affects everyone, not only the newcomer.
The benchmark worth aiming for is a one-command bootstrap. Clone the repository, run one script or one docker compose up, and within thirty minutes you have a working stack with seeded data. Teams that have this tend to have healthy CI, sane dependency management and honest documentation, because the bootstrap script forces all three. Teams that do not have it usually have a wiki page titled "Local Setup" that was last accurate in 2023 and a Slack thread where every new hire asks the same eleven questions.
If your setup currently takes three days, do not paper over it with a longer onboarding checklist. Have the new engineer keep a log of every point where they got stuck, then fix those points before the next hire. The first week of a new person is the only time anyone on the team sees the setup with fresh eyes. Waste that and you pay for it again with the next hire.
Beyond the environment, the first week should cover access to the tools that matter (repository, CI, error tracking, the production dashboard in read-only mode, the ticket board), a walk through the architecture at whiteboard level, and a first commit. The first commit is deliberately small: fix a typo in a log message, add a missing test, correct an outdated comment. The point is to exercise the entire path from branch to pull request to review to deployment while the stakes are zero.
The question to answer at the end of week one: can this person run, test and deploy the application without asking for help?
Weeks 2 to 4: learning the real conventions
The documented conventions and the real conventions are rarely the same thing. The style guide says one thing about error handling; the code does three different things depending on which year the module was written. New engineers learn the real conventions in one of two ways, either by pairing on production code with someone who knows the history, or by guessing and being corrected in code review. The first is faster and much less demoralizing.
Schedule real pairing sessions in weeks two and three, not shadowing. The new engineer types while the experienced engineer talks through why the code is shaped the way it is. Pick tickets in the parts of the system the new hire will own. Two to three sessions of ninety minutes each are usually enough to transmit the tribal knowledge that no wiki captures: which module is fragile, which test is flaky and why nobody has fixed it, which abstraction was a mistake that the team has agreed to live with.
The first solo pull request follows the pairing. It should be a real ticket with a real user impact, sized for two or three days of work. The review of this PR sets the tone for the whole working relationship, so it deserves attention. A good first review explains reasoning rather than issuing verdicts. "We keep validation in the request DTO because the same rules are reused by the import command, see ImportCustomersCommand" teaches something. "Move validation" does not. If the reviewer finds themselves writing fifteen comments, that is a signal that the pairing sessions missed something, and the fix is a conversation, not fifteen comments.
The question to answer at the end of month one: has this person merged production code that they wrote alone, and did the review teach rather than gatekeep?
Month 2: own something end to end
By the second month the new engineer should own a small feature from ticket to monitoring. Not a task inside a feature. The whole thing: refining the requirement with the product owner, designing the data model change, writing the migration, implementing the backend and any UI, writing tests, deploying it, and watching the dashboards afterwards.
The size matters. A feature that takes two to three weeks is about right. Smaller and they never hit the interesting problems, such as a migration against a large table that must not lock it. Good candidates are things like a new export format, a settings page for a tenant-level option, or a webhook for an event the system already emits.
Deployment and monitoring are part of ownership. The new engineer should be the one who merges, watches the deploy, checks error rates and confirms the feature works in production.
Month two is also the right time for a first on-call rotation, paired with a buddy who is the actual responder. The new engineer joins the calls, reads the alerts, follows the runbooks and asks questions afterwards. They do not carry the pager alone yet. After two or three incidents observed this way, most engineers are ready to be primary with the buddy as backup. Skipping this step and putting someone on-call alone in month three, with no incident experience, is how onboarding accidents happen at 3 a.m.
The question to answer at the end of month two: can this person take a feature from requirement to production and know whether it is working?
Month 3: contribute to how the team thinks
Month three shifts from executing well to improving the system. The new engineer has now seen enough of the codebase to have opinions, and they still have enough outsider perspective to notice things the team has stopped seeing.
Bring them into architecture discussions with an explicit expectation: leave the discussion better than you found it. That might mean asking the question nobody asked, writing up the decision afterwards as an ADR, or pointing out that the proposed approach conflicts with something they hit in month two. Teams that keep new people silent in design meetings until they have "earned" a voice lose the most valuable window for fresh input.
The other month-three activity is measurement. Every team tracks something, whether that is deployment frequency, lead time for changes, error budget consumption, or a support ticket backlog. The new engineer should be able to point at those metrics and say what their work did to them. If the team does not track anything that an individual contribution shows up in, that is worth knowing too, and worth fixing. It is hard to feel productive when nothing you do registers anywhere.
The question to answer at the end of month three: would this person's absence be noticed in the team's output and in its decisions?
What the onboarding guide should contain
Most onboarding guides are a list of accounts to request and a link to the style guide. Here is what an engineer joining a SaaS team needs and rarely gets.
A system map that shows the major services, the databases, the queues and the external integrations, with one sentence each on what they do and one sentence on their known problems. A rough diagram that is honest about the ugly parts beats a polished one that pretends the payment service is not held together with retries.
A "where things live" section: where configuration comes from, where feature flags are defined, where the migrations are, how secrets are managed in each environment, and how to find the logs for a given request.
A list of conventions with the reasoning behind them. "We use constructor injection everywhere" is a rule. "We use constructor injection so that every dependency of a service is visible in one place and tests can substitute them without a container" is a convention someone can apply to a case the rule did not anticipate.
The known debt. Every team has parts of the codebase they are not proud of. Write them down. A new engineer who discovers on their own that the billing module is a mess will wonder what else nobody told them. One who was warned in the guide will treat it as a known hazard and move on.
And finally, a short history. When was the system started, what did it look like then, what were the two or three big decisions or rewrites that shaped it. Much of what confuses newcomers makes sense once you know the order in which things happened.
Code archaeology is a skill, and most teams assume it
Reading unfamiliar code well is something senior engineers do without thinking, and something that is almost never taught. Teams assume a new hire can drop into a two hundred thousand line codebase and orient themselves. Some can. Most take weeks longer than necessary because nobody showed them the techniques.
The techniques are learnable in an afternoon. Start from an entry point, such as an HTTP route or a queue consumer, and follow one request end to end before reading anything else. Use git log -p and git blame on a file to see how it got its shape, and read the commit messages and linked tickets, not only the diff. Find the tests for a module before reading the module; tests often document intent better than the implementation. When two ways of doing the same thing exist, check which one is newer and assume that is the direction the team wants to move in, then confirm. Keep a running list of questions and batch them rather than interrupting someone every twenty minutes.
Spend one pairing session in week two on exactly this. Pick a part of the system the new engineer has not seen and let them navigate while the experienced engineer only answers questions about technique, not about the code. It feels slow. It saves weeks.
When onboarding exposes the real problem
Every so often a team runs this plan and discovers that the new engineer cannot get through week one because the local environment has never really worked, or cannot own a feature in month two because there is no test suite to protect them. In those cases the plan has done its job by making the problem visible.
That is where we usually come in. Wolf-Tech works with SaaS teams on exactly these foundations: a code quality audit to find out where the friction really is, modernization of the legacy parts that make setup and deployment fragile, and tech stack decisions that keep the next hire from repeating the same pain. If you are about to grow your engineering team and want the first hire to go smoothly, write to hello@wolf-tech.io or have a look at wolf-tech.io. A short conversation about how your current onboarding goes is usually enough to see where the time is being lost.