TL;DR:

  • New engineers should be making real contributions within the first two weeks — if they aren’t, the bottleneck is onboarding documentation, not the engineer
  • The single most valuable onboarding document is the one that explains how to get the development environment running from zero, kept current by the last person who ran it
  • A first PR within the first week establishes culture and workflow; the PR itself doesn’t need to matter

Developer onboarding is often treated as an HR process with some IT access requests bolted on. Good engineering onboarding is a product. The users are new engineers, the goal is time-to-first-contribution, and the system breaks down in predictable ways that are worth studying and fixing.

What a 30-60-90 Day Plan Should Actually Look Like

A 30-60-90 day plan gives a new engineer clarity on what success looks like at each stage. The specifics vary by team, but the structure holds.

Days 1–30: Setup and orientation. The goal is self-sufficiency: the new engineer can build and run the product locally, understands the codebase’s architecture at a high level, and has made at least two small contributions. They should be able to answer their own questions using internal documentation, team chat history, and codebase search.

Key deliverables: dev environment running without help by day 3, first PR merged by day 7, second PR by day 14, architecture walkthrough from a team member by day 10.

Days 31–60: Contribution and context. The new engineer takes ownership of small features or bug fixes end-to-end. They understand the team’s definition of done, the code review process, and the deployment pipeline. They’re asking questions that reveal systems-level curiosity, not just task-level confusion.

Key deliverables: one independently scoped and shipped feature, participation in sprint planning, and a contribution to documentation — specifically fixing something that was confusing during their first 30 days.

Days 61–90: Independence and judgement. The new engineer scopes their own work, makes architectural decisions within their domain, and contributes to code review of others’ work. They can onboard the next person who joins.

Key deliverable: own a meaningful feature from design through deployment.

Documentation Every Team Needs

The documentation debt in most engineering teams is large and familiar: README files that haven’t been updated since the project started, architecture diagrams reflecting a system from two years ago, runbooks that assume knowledge the reader doesn’t have.

Five documents that must exist and be current:

Getting started / dev environment setup. Step by step, from a fresh machine to running tests locally. Every ambiguous step is a future support request. Have the last new hire review and update it during their first week — this is the cheapest way to keep it accurate.

Architecture overview. One page explaining what the system does, what the major components are, and how they communicate. Diagrams are useful; a C4 model (system, container, component, code layers) is an excellent frame.

How to deploy. Even if deployment is automated, the new engineer should understand what happens when they merge. What triggers a deploy? What are the rollback procedures? What do monitoring dashboards look like during a healthy deploy?

Where things live. Where is the staging environment? How do you get database access? Where are the API keys stored? Who approves production access? This is usually tribal knowledge — writing it down saves hours.

Team norms. How does the team do code review? What’s the expected response time on PRs? Are there standing meetings? What does “done” mean for a ticket? These small things cause large amounts of anxiety in new engineers trying to calibrate expectations.

Setting Up the Development Environment

The fastest way to improve onboarding quality is to make your development environment setup reproducible. Dotfiles, Makefiles, and setup scripts turn “spend three hours configuring your laptop” into “run this script.”

# Ideal first day experience
git clone git@github.com:company/dotfiles.git
cd dotfiles && ./install.sh

git clone git@github.com:company/myapp.git
cd myapp && make setup
make test  # all green
make dev   # app running on localhost:3000

This is achievable. It requires someone to maintain the setup script and test it when dependencies change — that’s the ongoing cost. The payoff is new engineers in their dev environment in under an hour instead of an afternoon.

Runbooks for common tasks (resetting the database, running specific test suites, accessing staging data) should live in the repository, not in someone’s memory.

First-PR Culture

The first PR a new engineer submits reveals the team’s culture. If they submit something small and useful and it gets approved with helpful feedback within 24 hours, they learn that the team reviews quickly, is welcoming, and cares about their growth. If it sits for four days and comes back with terse comments, they learn something else.

Good first-PR tasks: fix a typo or outdated URL in documentation, add a missing test case, improve an error message. The code change is small enough that review is easy; the workflow — branch, PR, review, merge, deploy — is what matters.

Some teams maintain a good-first-issue label or a designated list of first-PR tasks for new engineers. This lowers the activation energy and ensures the first contribution is achievable. It’s a small investment that pays back immediately.

Common Onboarding Failures

Environment setup takes more than half a day. If setting up the dev environment requires significant troubleshooting, the setup documentation is wrong or stale. Fix the docs; don’t accept “it’s complicated” as the answer.

No clear owner for the new engineer’s first 30 days. Someone specific should be responsible for answering questions, reviewing early work, and checking in daily. An “everyone is your resource” policy means no one pays attention.

Meetings before context. Filling the first week with meetings before the engineer has any codebase context means the meetings don’t land. Let them read and explore for a day or two before putting them in architecture discussions.

The Bottom Line

Good developer onboarding reduces time-to-first-contribution, improves retention, and produces documentation that helps the whole team. Treat the onboarding process as a product: measure it, iterate on it, and have each new hire contribute one improvement to it during their first month.