30-60-90 day plan for engineering managers
On this page
- Days 1-30: Understand the team and the system
- The baseline an engineering manager should build
- Days 31-60: Make the first changes and set up the product partnership
- Days 61-90: Own the team's direction
- What "on track" looks like
- A filled example
- The trap: becoming the team's strongest engineer
- Questions for the check-ins
- What the hiring manager owes the new engineering manager
- Adapting the plan
- Questions people ask
An engineering manager is judged on two things that pull against each other in the first 90 days: the team's health and the team's delivery. A new manager who focuses only on delivery burns people out; one who focuses only on people lets the roadmap slide while they hold one-on-ones. A 30-60-90 day plan for an engineering manager should make both visible, with milestones the hiring manager, usually a director or VP of engineering, can check without sitting in every meeting.
The people side of this plan overlaps with the 30-60-90 day plan for new managers, which covers one-on-ones and team diagnosis in general terms. This page adds what is specific to managing engineers: delivery flow, on-call, technical debt, hiring loops and the partnership with product.
Days 1-30: Understand the team and the system
Goals
- Hold a first one-on-one with every engineer in the first two weeks. Ask what they are working on, what slows them down, what they want to be doing in a year, and what the last manager did that they want kept.
- Read the last quarter's design documents, incident postmortems and retro notes.
- Ship one small change through the full pipeline: ticket, branch, review, CI, deploy. Note every point of friction.
- Shadow one on-call shift or review the last month of pages with the on-call engineers.
- Meet the product manager, designer and any engineering managers of teams yours depends on, or that depend on yours.
Evidence by day 30
- A team health and delivery baseline (see the table below), written up in a page or two.
- A one-to-one cadence set with every engineer and kept every week.
- A list of the three biggest problems, with the team's own words next to each.
The baseline an engineering manager should build
| Area | What to look at | Question it answers |
|---|---|---|
| Delivery flow | Deploy frequency, time from merge to production, share of deploys that cause an incident or rollback, time to restore service | Is the team slow because of the work, or because of the pipeline? |
| Work in progress | Open pull requests and their age, tickets in progress per engineer, time PRs wait for first review | Is work getting stuck between people? |
| On-call load | Pages per week, out-of-hours pages, repeat alerts, how many pages had a runbook | Is on-call sustainable, and who is carrying it? |
| Technical debt | Known fragile areas, skipped upgrades, flaky tests, what engineers avoid touching | What slows every change, and what could cause the next incident? |
| People | Tenure, open roles, planned leave, flight risks, career goals, last promotion dates | Who might leave, and who is ready for more? |
The first four rows borrow from the delivery measures popularized by the DORA research program, but the goal in month one is understanding, not targets. A team that deploys weekly because of a regulated release process is not failing; a team that deploys weekly because the test suite takes three hours may be.
Days 31-60: Make the first changes and set up the product partnership
Goals
- Fix one of the three biggest problems, chosen with the team. Common examples: a PR review rotation to cut review wait time, alert cleanup to cut repeat pages, or a stable sprint-planning format.
- Agree with the product manager how work is prioritized: who decides the roadmap order, how technical debt gets capacity, and how the team pushes back on scope.
- Give each engineer specific feedback on real work, positive and critical, tied to a PR, design doc or incident.
- Run the team's planning for the next cycle, with estimates the team owns.
- Join the hiring loop for any open roles, and review the interview questions and scorecard the team uses.
Evidence by day 60
- One measured improvement against the baseline, such as review wait time or out-of-hours pages.
- A written working agreement with the product manager, even a short one.
- A planning cycle completed with commitments the team largely hit, or missed with a clear reason.
Days 61-90: Own the team's direction
Goals
- Present the team's next-quarter plan: roadmap commitments, the share of capacity for technical debt and reliability, and the risks.
- Write a staffing plan: open roles, skills gaps, and who is ready for a larger scope.
- Hold a first career conversation with each engineer against the company's career ladder, with a written next step.
- Handle one hard people situation directly, such as underperformance, a conflict or a flight risk, with the hiring manager's coaching.
Evidence by day 90
- A quarterly plan the product manager and the hiring manager both signed off.
- A staffing plan with specific roles and reasons.
- Engineers who can name what they are working toward in their career, in their own words.
What "on track" looks like
| Checkpoint | On track | Worth raising |
|---|---|---|
| Day 30 | Baseline with real numbers; every engineer met; the manager can explain the architecture at a whiteboard level | One-on-ones skipped for "urgent" work; no view of on-call; changes already announced |
| Day 60 | One improvement measured; product and engineering agree how priorities are set; engineers have heard critical feedback | The manager has become the team's best individual contributor; feedback is only praise; debt has no capacity |
| Day 90 | Quarterly plan agreed; staffing plan written; one hard people issue handled directly | Plan dictated by product with no engineering input; people issues avoided or passed up the chain |
A filled example
Engineering manager: Sofia Lindqvist (invented), hired externally to manage a seven-person payments team.
Day 30: Met all seven engineers in the first eight days. Shipped a small fix to a webhook retry and found that CI took over 40 minutes, so most engineers batched changes into large PRs. On-call review showed two engineers took most out-of-hours pages because they were the only ones who knew the settlement service.
Day 60: With the team, split the slowest test suite and cut CI time roughly in half; PR size started to drop. Started pairing on settlement-service pages so knowledge spread beyond two people. Agreed with the PM that 20 percent of each cycle goes to reliability work the engineers choose.
Day 90: Presented a quarterly plan with a settlement-service runbook project and a card-network migration. Wrote a staffing plan asking for one senior engineer with payments experience. Had a direct performance conversation with one engineer whose reviews were blocking others, with a follow-up plan agreed.
The trap: becoming the team's strongest engineer
Most engineering managers were strong engineers, and under pressure they reach for the skill they trust. It feels productive to pick up the gnarly bug or write the design doc nobody else has time for, and in week three it probably is. By week eight it means the one-on-ones are shorter, the hiring loop is slower and the team is routing hard problems to the manager instead of growing into them. Ask about this directly at the day-60 check-in: what did you personally build this month, and who on the team could have built it instead?
Questions for the check-ins
- Which engineer do you understand least so far, and what would help?
- What does the team complain about that you have not fixed yet, and why not?
- Where do you and the product manager disagree, and how are you settling it?
- If the busiest on-call engineer left tomorrow, what would break?
What the hiring manager owes the new engineering manager
- The last performance reviews, promotion history and any open concerns for each engineer, shared before the first one-on-ones.
- An introduction to the product manager with a clear statement of how decisions are shared between them.
- Access to the delivery and incident data: the CI system, deploy logs, incident tracker and paging tool.
- Coaching before the first hard conversation, not just a debrief afterward.
Adapting the plan
- Manager of managers: replace one-on-ones with every engineer by skip-levels in the first 45 days, and make the day-90 staffing plan span all teams.
- Platform or infrastructure teams: weight the baseline toward reliability and internal-customer satisfaction; the "product partnership" becomes a partnership with the teams consuming the platform.
- Team formed around the new manager: skip the baseline of an existing team and use the first 30 days for hiring, charter and a first small delivery.
For the engineers on the team, the 30-60-90 day plan for software engineers gives the manager a ready structure for their own new hires. If you are still hiring the manager, how to interview for leadership roles covers how to test for the people judgment this plan depends on, and the general 30-60-90 day plan template covers the structure shared across roles.
Questions people ask
Should a new engineering manager write code in the first 90 days?
A small amount helps: fixing a bug or shipping a small change in the first month teaches the codebase, the review process and the deploy pipeline faster than any walkthrough. It should not become a feature the team depends on, because the manager's calendar will not protect it.
What metrics should an engineering manager look at in the first 30 days?
Delivery flow, such as how often the team deploys, how long changes take to reach production and how often deploys cause incidents; on-call load, such as pages per week and how many come out of hours; and the state of the backlog. The point in the first month is to understand them, not to set targets.
How is this different from a general new manager plan?
The people milestones are the same. An engineering manager also owns technical health: delivery speed, reliability, on-call sustainability and technical debt, and has to build a working partnership with a product manager over who decides what gets built and when.
What if the new engineering manager was promoted from the team?
Shorten the technical diagnosis, since they already know the system, and spend the saved time on the relationship reset. The hardest milestone for an internal promotion is usually the first piece of direct, critical feedback to a former peer.