30-60-90 Day Plan for Software Engineers: Example, Goals and Metrics

8 min read ยท 2026-10-25

A 30 60 90 day plan for software engineer roles splits your first three months into learning, contributing and owning. In days 1 to 30 you set up your environment, merge small fixes and learn how code reaches production. In days 31 to 60 you ship a real feature end to end. In days 61 to 90 you own a part of the system, join on-call and propose one improvement backed by a number.

Generic templates stop at goals like learn the codebase. That is not something your manager can check. The plan below names the first-week tasks, the people to meet, the quick wins that make sense for an engineer and the signals your manager will look at. It also shows how to adjust it for junior, senior and staff roles, and how to present it at your first one-on-one or in an interview.

The roadmap at a glance

Goal: By day 90, you ship features on your own, own one service or module, take on-call shifts and have one improvement proposal reviewed by your team. Duration: 90 days (13 weeks)

  1. Setup and first commit (Week 1)

    Get a working development environment and merge your first small change.

    • Request access to the repositories, CI pipeline, cloud console, ticket tracker, logs and team chat, and note every access you had to ask for.
    • Run the app locally by following the README, and fix the README wherever it is wrong or out of date.
    • Pick a starter ticket that your manager or onboarding buddy has tagged as a good first issue.
    • Open your first pull request and follow it through code review, CI and the deploy pipeline.

    Milestone: First pull request merged and deployed, plus a corrected setup guide that the next hire can follow without help.

  2. Learn the system and the team (Weeks 2-4)

    Understand the architecture, the delivery process and who decides what.

    • Draw the architecture from memory (services, data stores, queues, external APIs), then review it with a senior engineer.
    • Read the last few incident postmortems and architecture decision records to learn what breaks and why things are built this way.
    • Shadow one on-call shift or incident review.
    • Hold one-on-ones with your product manager, tech lead, designer, QA and an engineer from a team you depend on.
    • Fix two or three small bugs in different parts of the codebase.

    Milestone: Architecture diagram checked by the tech lead, at least three merged pull requests in two different areas, and your list of open questions answered.

  3. Ship a feature end to end (Weeks 5-8)

    Take a scoped feature from ticket to production with normal review support.

    • Take a medium-sized ticket with a clear user outcome, agreed with your product manager.
    • Write a short technical plan (approach, data changes, risks, rollout) and get feedback before you code.
    • Add tests, logging and a metric or alert so you can tell the feature works in production.
    • Ship behind a feature flag if your team uses them, then roll out in steps.
    • Demo the feature at sprint review.

    Milestone: Feature live in production and demoed, with tests and a dashboard or alert that shows it is healthy.

  4. Take ownership (Weeks 9-11)

    Own one component and start raising the quality of the team's work.

    • Become the main reviewer for one service or module, and update its README and runbook.
    • Join the on-call rotation as primary, with an experienced engineer as backup for the first shift.
    • Review other people's pull requests every day and aim for a fast first response.
    • Pick one developer pain point, such as flaky tests or a slow build, and measure it.

    Milestone: First on-call shift completed and you are listed as owner of one component in the team docs.

  5. Propose and plan the next quarter (Weeks 12-13)

    Turn what you learned into one improvement and agreed goals for the next quarter.

    • Write a one-page proposal for your improvement: the problem, the current number, the fix and the expected result.
    • Present it at a team meeting or architecture review and collect objections.
    • Hold a 90-day review with your manager: what shipped, feedback received, what to change.
    • Agree on one growth area tied to your company's engineering career ladder.

    Milestone: Proposal reviewed and either approved or scheduled, and written goals for the next quarter agreed with your manager.

Your first-week checklist

Week one is about access and context, not output. You will feel slow, and that is expected. The goal is to remove every blocker that would stop you from shipping in week two, and to show that you can follow the team's process from ticket to deploy.

Keep a running log of every question you ask and every step that was missing from the docs. That log becomes your first quick win, and it tells your manager exactly where onboarding is weak.

  • Laptop, accounts, VPN, SSO and two-factor set up.
  • Access to source control, CI, staging, logs, error tracking and the ticket board.
  • App running locally, with test suite passing.
  • Team rituals in your calendar: standup, planning, retro, sprint review, on-call handover.
  • First one-on-one with your manager to agree on what success looks like at day 30, 60 and 90.
  • One starter ticket picked and in progress.

People to meet in the first 30 days

An engineer who only reads code misses half the system. Decisions about scope, quality and priorities live with people. Book 30-minute chats in your first month and ask the same three questions each time: what does good look like for you, what slows you down, and what should I not touch yet.

Write down the answers. Patterns across five or six conversations tell you more about the real priorities than any onboarding deck.

  • Your manager: expectations, how performance is reviewed, how they like updates.
  • Tech lead or staff engineer: architecture, coding standards, the parts of the codebase that are fragile.
  • Product manager: the roadmap for the next two quarters and which customer problems matter most.
  • Designer and QA: how handoff and testing work, and where bugs usually come from.
  • An engineer from a neighboring team: shared APIs, dependencies and who to ask when something breaks.
  • Someone from support or customer success: the complaints they hear most about the product.

Quick wins that fit a software engineer

A good quick win is small, visible and useful to the team, and it does not require you to understand the whole system. Avoid rewrites or big refactors in the first 60 days. You do not yet know why the code looks the way it does.

Aim for two or three of these before day 45. Each one shows that you can ship safely and that you care about the team, not just your own tickets.

  • Fix the setup docs so the next hire gets running in less time than you did.
  • Remove a flaky test or fix a warning that every build prints.
  • Add a missing alert or log line found while shadowing on-call.
  • Close two or three old bugs that nobody has picked up.
  • Write the runbook entry for a task that only one person knows how to do.

Metrics to track at day 30, 60 and 90

Your manager will judge you on outcomes and on how you work, not on lines of code. Pick a few signals you can check yourself and bring them to each check-in. Count them from your source control and ticket tools rather than from memory.

Do not chase volume. Ten tiny pull requests are worth less than one feature that customers use. The numbers are there to start a conversation, not to replace it.

  • Time to first merged pull request: target your first week.
  • Merged pull requests and areas touched: shows you are learning beyond one corner of the code.
  • Features shipped to production: at least one by day 60, with no rollback.
  • Review turnaround: how fast you give a first response on teammates' pull requests.
  • On-call: shifts covered and incidents handled with a short write-up.
  • Feedback: one thing to keep and one thing to change, asked for at day 30, 60 and 90.

How to adapt it for junior, senior and staff roles

The phases stay the same, but the scope and the timing change with your level. A junior engineer is judged on learning speed and code quality. A senior engineer is judged on delivery and on making the people around them faster. A staff engineer is judged on direction across several teams.

Ask your manager which level descriptions your company uses, and map your day 90 milestone to the next box on that ladder.

  • Junior: more pairing, smaller tickets, ship a feature with help by day 60, join on-call later if the team prefers.
  • Mid-level: follow the plan as written, with one feature by day 60 and one owned component by day 90.
  • Senior: lead a feature with another engineer by day 60, mentor a teammate, and own a technical design by day 90.
  • Staff: spend days 1 to 30 interviewing several teams, publish a written view of the main technical risks by day 60, and get one cross-team initiative approved by day 90.

How to present it to your manager or in an interview

In an interview, you do not know the codebase yet, so keep the plan at the level of goals and habits. Show that you will learn before you change things, that you will ship something small early, and that you will ask how success is measured. Mention the team's stack or product by name so it does not look like a copy-paste plan.

In the job, put the plan on one slide or one page for your first one-on-one. Use three columns (days 1 to 30, 31 to 60, 61 to 90) with three rows: goals, deliverables and how we will know. Leave out tool lists and generic values. Update the page at each check-in with what is done, what slipped and why.

Common mistakes to avoid

  • Rewriting a module in your first month breaks things you do not yet understand, so wait until you know why the code is built that way and propose changes in writing.
  • Staying quiet when stuck wastes days, so set a rule like asking for help after an hour of no progress.
  • Measuring yourself by pull request count pushes you toward trivial work, so tie your goals to features shipped and problems fixed.
  • Skipping the product manager and support leaves you blind to what customers need, so meet them in the first two weeks.
  • Joining on-call without shadowing first makes incidents stressful and slow, so shadow at least one shift and read the runbooks before your first one.
  • Keeping the plan in your head means nobody can confirm progress, so share it in writing and review it at day 30, 60 and 90.

Frequently asked questions

What should a software engineer do in the first 30 days?

Set up your environment, merge a first small change in week one and learn how code reaches production. Meet your manager, tech lead, product manager and a few peers. Fix small bugs in different areas to learn the codebase.

How do I write a 30-60-90 day plan for a software engineer interview?

Keep it to one page with three columns: learn, contribute, own. Name the company's product and stack, and focus on habits like shipping a small fix early and asking how success is measured. Avoid promising specific technical changes before you have seen the code.

When should a new engineer join on-call?

Many teams add new engineers to the rotation after one to three months, once they have shadowed a shift and read the runbooks. Ask your manager what your team expects. Start as primary with an experienced backup.

What does a manager expect from a new engineer after 90 days?

Usually that you ship features with normal review support, understand the main parts of the system and take part in code review and on-call. Senior hires are also expected to improve something for the team. Confirm the expectations in writing during your first week.

Generate this roadmap with AI