First 90 Days as an Engineering Manager: 30-60-90 Day Plan

When I joined one team, my manager told me they were not working as a team. They were struggling to deliver Features when they had committed to delivering them. That was the picture I was given before I understood how their work was organised.

Listening brought out more of the story. There were problems with refinement, the Scrum Master had volunteered because nobody else wanted the role, and requests from outside the team kept interrupting planned work throughout the week. Those conditions mattered when we looked at what the team could deliver.

Your first 90 days as an Engineering Manager give you time to understand how the team works, agree on a useful improvement, and establish who can make which decisions. A 30-60-90 day plan puts those intentions into a sequence you can review with your manager.

The first days can feel strangely unproductive. You spend hours listening, reading, and meeting people, yet finish the day without the visible output you were used to producing as an engineer. That work builds the context you need to make responsible decisions.

This is the plan I would want beside me when taking over a team. Use it to prepare your first conversations, choose an experiment, and review what changed. There is a copyable planning template below, followed by answers to problems that can disrupt the plan.

Your 30-60-90 Day Plan at a Glance

The dates are checkpoints. You can delegate a bounded responsibility in week one, and trust-building continues after day 30. If there is an active incident or a serious people issue, respond immediately with the appropriate support; the listening phase is not a reason to delay necessary action.

Before You Start: Agree on Expectations

Book a conversation with your manager during your first week. Ask:

• What would make you say my first 90 days went well?
• Which commitments and risks already need my attention?
• Which decisions can I make, and which require discussion with you?
• How should I divide my time between technical work and people management?
• What should I preserve about this team?

Write down the answers and arrange a review around days 30, 60, and 90. Completing a checklist is less useful if you and your manager are working towards different expectations.

If you were promoted internally, explicitly discuss how your relationship with former peers will change. Familiarity with the code does not mean you already understand everyone’s ambitions or concerns.

If you joined a new company, allow more time for the product, customers, architecture, and decision history. Ask why an existing process was introduced before proposing its replacement.

Days 1–30: Understand the Team and Its Commitments

Weeks 1–2: Introduce yourself and start 1:1s

Tell the team what matters to you, how you prefer to communicate, and what you intend to learn. A Personal Map for your introduction can give that conversation some structure.

Meet your direct reports, your manager, and the people the team depends on, such as Product, Design, QA, and other engineering teams. Start a regular 1:1 rhythm now rather than waiting until the second month.

For a first 30-minute 1:1, spend a few minutes introducing yourselves, leave most of the time for the other person’s experience, and finish by agreeing on follow-ups. Ask how they prefer feedback and what support they need from you.

Useful questions include:

• What is working here that you would hate to lose?
• Where does work regularly get stuck?
• What should I understand about the team’s history?
• What would you like more opportunity to do?
• What would make our 1:1s useful for you?

Keep notes of commitments and follow through. Avoid promising a solution during the first conversation when you have heard only one perspective.

Make room for the employee’s concerns before bringing your own list. A useful first meeting may end with one thing you owe them: checking a training budget, clarifying an expectation, or finding out who can resolve a dependency. Write down that commitment and return to it at the next meeting.

Observe how work actually moves

Read the current roadmap, recent retrospectives, incident reviews, and relevant technical decisions. Observe planning, reviews, and handoffs. Compare what the process says with what people actually need to do to ship a change.

By the end of week two: you should have a first set of relationships, a record of commitments you made, and questions worth investigating. Resist labelling people as disengaged or weak performers based on brief initial impressions.

Weeks 3–4: Map responsibilities and dependencies

Turn observations into a working picture of the team. Capture:

• Purpose: who the team serves and what outcomes it is responsible for.
• Ownership: who makes decisions and where responsibility is unclear.
• Dependencies: where another team, supplier, or approval can block progress.
• People: strengths, development interests, and workload concerns to explore privately.
• Delivery: repeated sources of delay, rework, and interruption.

Separate observations from interpretations. “Three changes waited for the same reviewer” is an observation. “The reviewer does not trust the team” is a hypothesis to discuss.

If responsibility is unclear, use a small RACI matrix for engineering teams for the specific decision or workflow. You do not need to map every activity in the organisation.

What I found behind the missed commitments

The team I mentioned at the start worked in SAFe, with a three-month PI planning cycle. My manager’s assessment focused on how the team worked together. As I listened, I learned about difficulties with refinement and the way work reached the team. Engineers were expected to deliver the planned Features while also handling requests arriving during the week.

The Scrum Master role was another part of the picture. The person doing it had volunteered because nobody else wanted to. He had received no training for the role; he had simply stepped forward. He was warm, cheerful, and often made the team laugh. I valued that atmosphere. But he struggled to follow up on commitments, and conversations could turn into jokes without bringing people back to what they had agreed to do.

We started by identifying the unplanned requests, writing them down, and measuring how much time they took. That gave us something concrete to discuss when planning the team’s work.

Some requests turned out to be less urgent than they first appeared. We could bring them into PI Planning as normal planned tasks. For the requests that did need attention during the PI, we reserved capacity.

We also changed who held the Scrum Master role. I sent the new person on a course, after which they earned a PSM certification. The training gave them knowledge and tools to use in the role. They were also more consistent about reminding people of their commitments and following up on what needed to be done.

When the team responded with jokes, I spoke with them too. I made it clear that we could keep joking and enjoying working together, but when the Scrum Master followed up on an agreed task, I expected them to take that commitment seriously.

Changing the person in the role was only part of it. My part included supporting their preparation and making the expectation clear to the team, while we addressed the incoming work that was competing with those commitments.

Our on-time delivery measure, or OTD, tracked whether a Feature was delivered in the sprint we had committed to. A Feature that missed that sprint scored zero for on-time delivery, even if it was completed later. This matters: finishing work and meeting the promised date were different things in that measure.

For example, if we committed to Feature A in sprint 2 and Feature B in sprint 3, but delivered both in sprint 4, both scored zero for OTD. The work was completed within the PI, but neither Feature met its promised sprint. A low OTD score alone would not tell me how much work the team had completed or why it was late.

Over two PIs, the same engineering team gradually reached 100% OTD for a PI. The result did not jump to 100% as soon as we made the changes. It took two planning cycles, about six months in our case. Making room for necessary incoming work was part of making our commitments realistic.

That timescale belongs in a guide to the first 90 days too. The first months give you time to understand the problem and start changing how the work is organised. The full result may take longer. I would not use the day-90 review to promise a turnaround that, in this case, took two PIs.

This experience shapes how I approach taking over a team. If I hear that a team cannot deliver, I want to understand what it committed to, what work arrived afterwards, and whether people have the support and roles they need. The initial assessment gives me something to investigate. It is too early to use it as an explanation.

Your day-30 review

Bring your manager a one-page summary:

1. What seems to work well and should be preserved.
2. The most important risks, with examples and open questions.
3. One improvement you propose to test with the team.
4. What support or decision you need.

Check your understanding with the team before treating the summary as settled fact. Building trust includes being willing to revise your first interpretation.

Days 31–60: Test One Improvement and Delegate Ownership

Choose one recurring problem that the team considers worth improving. Define a small experiment with an owner, a review date, and a way to compare before and after.

If incoming requests keep displacing planned work, start with the approach from my team: record what arrives and how much time it takes. Separate work that can be planned from work that needs capacity reserved during the cycle. Use what you learn to agree on how much planned work the team can take on.

Review both the interruptions and the commitments. Reserving capacity should help you make promises the team can keep; it does not make the incoming work disappear. Check whether requests still exceed the allowance and whether important work is waiting longer than it should.

Continue your 1:1s. Keep space for workload, feedback, and development rather than letting every meeting become a project update.

Give feedback when there is something specific to discuss. You do not need to wait for the day-60 review. If a delivery risk was raised too late, describe what happened, explain the impact, and ask what prevented an earlier warning. Agree on what should happen next time. The FUKO feedback method gives that conversation a structure.

Write down only the working agreements the team needs: how to raise a risk, where a decision is recorded, and when to involve someone else. Review whether those agreements help in practice.

Delegate a result with clear boundaries

Use the delegation framework to agree on why the work matters, the result, the owner, and the timing. Add what the owner can decide independently and when they should ask for help.

Agree on check-ins before the deadline so emerging risks can be addressed while there is still time to act. Expand ownership gradually as you learn what support each person needs.

I have also made the mistake of calling something ownership while keeping approval of every step. When a decision comes back to you, check the agreement before assuming the engineer lacks confidence. Did you give them authority to decide? I explore that distinction in Delegate Ownership, Not Tasks.

At day 60: review the evidence with the team and your manager. Continue, adjust, or stop the experiment. An unsuccessful experiment can still teach you something useful if its cost was bounded and its result is understood.

Days 61–90: Review Results and Agree on Next Priorities

Use the final month to review what changed and agree on the next priorities.

• Ask the team what has become clearer, what is still frustrating, and what you should do differently.
• Review ownership: which decisions still wait for you unnecessarily?
• Agree on a development opportunity with each direct report, based on their interests and the team’s needs.
• Discuss the next quarter with your manager and Product, including unresolved dependencies and capacity constraints.

For a delegated responsibility, make the decision boundary explicit. The Decision Tree for Engineering Leaders offers a way to discuss which decisions can be made independently and which require consultation.

At day 90: bring examples of progress, remaining risks, and a small set of next priorities. Include what you tried and stopped. Avoid presenting every change as a success just because you introduced it.

Bring the capacity cost of those next priorities too. Pairing, documentation, and development work need time in the team’s plan. If Product expects the same delivery commitments alongside the new work, use a prioritisation conversation to agree on what moves back or becomes smaller.

Worked Example: Taking Over a Six-Person Team

Consider this illustrative example: you inherit six engineers responsible for a service. Releases often wait for one senior engineer. Your first impulse might be to tell that engineer to delegate more reviews.

In the first month, follow a recent release through its handoffs and speak with the people involved. Suppose you discover that the senior engineer is the only person familiar with a fragile integration. Asking everyone to approve changes would spread responsibility without addressing the knowledge gap.

In the second month, agree on a bounded trial: a second engineer pairs on reviews for that integration and documents the checks that matter. Give both people time for the work. Compare review waiting time and rework with the period before the trial, and ask whether the pairing adds an unsustainable burden.

At the day-90 review, decide what the evidence supports. If the second engineer can handle routine changes safely, agree on which reviews they can own and when to involve the senior engineer. If the trial has not helped, investigate why before extending it to the rest of the service.

The useful change began with understanding a specific dependency. The calendar gave you checkpoints; it did not tell you the answer in advance.

Your 30-60-90 Day Plan Template

Copy the following into a document you can review with your manager. Keep individual employees’ personal concerns in the appropriate private conversation notes; this plan is for team outcomes, commitments, and decisions.

Start with the agreement

• Team and start date:
• What my manager expects by day 90:
• Existing commitments we need to protect:
• Decisions I can make independently:
• Technical work I will own and the time it needs:
• Review dates for days 30, 60, and 90:

Use one row for each checkpoint

For the illustrative release example above, a day-30 entry could read:

Observation: Routine releases wait for the senior engineer who knows the integration. We still need to check how much of the delay comes from that dependency.

Trial: A second engineer pairs on integration reviews for two weeks and records the checks they need to understand.

Owner and capacity: Agree which engineer owns the trial and reserve time for both participants. Identify the planned work that will move.

Evidence: Record review waiting time before and during the trial, note any rework, and ask both engineers about the additional load.

Review decision: Decide which routine reviews the second engineer can take on and where they still need support.

Leave an answer open when you do not know it yet. “Need to confirm with Product by Friday” is more useful than filling a cell with an assumption nobody has agreed to.

Common Problems in Your First 90 Days

What if my manager expects changes in the first two weeks?

Ask which outcome cannot wait and what makes it urgent. A missed customer commitment needs a different response from a general wish to see you make an impact. You can investigate a specific problem and act on it while continuing to learn about the wider team.

For example, you could say:

I can start with the release delays this week. I want to follow one release and speak with the people involved before changing the approval process. On Friday, I’ll bring a proposed trial and the time it needs. Is there a commitment at risk before then?

This gives your manager a date and a concrete next step. If there is an immediate risk, agree on the temporary action and who needs to be involved. Revisit the longer-term process once you understand the cause.

How much should I keep coding as a new Engineering Manager?

Agree on work that fits the time you can actually protect. If a sprint task needs several uninterrupted days and your calendar is full of onboarding conversations, the team should not have to discover that conflict near the release date.

A useful agreement might be:

For the first month, I can pair on this area and take a bounded fix. I cannot commit to owning the migration alongside the onboarding work. Let’s choose an owner who has time for it and agree where my technical input would help.

The right balance depends on your role and team. Make it explicit and review it at day 30. For the wider change in your working week, see From Software Engineer to Engineering Manager.

What changes if I now manage former peers?

Have the role conversation even if you have worked together for years. Explain your new responsibilities, including feedback and development, and ask what support they want from you. Be clear about decisions that now sit with you and those that remain with the team.

You might say:

We already know how to work together on technical problems. My responsibilities now include your development and feedback too. I’d like us to talk about what you need from me in that role and what might feel awkward about the change.

Do not assume an old friendship gives you permission to discuss someone’s private concerns with the group. Also watch whose opinions you seek: familiar colleagues should not become the only people who influence your understanding of the team.

What if the experiment has not worked by day 90?

Show what you tried, what happened, and what decision follows. In the review example, perhaps pairing made reviews slower and the second engineer still cannot handle the integration independently. That is a reason to examine the learning gap and the cost of continuing.

A review could sound like this:

The trial has not reduced waiting time. Pairing added work for both engineers, and routine changes still need the senior reviewer’s help. Before extending it, we need to understand which checks the second reviewer cannot yet make and whether we have allowed enough learning time.

Your manager also needs to know what remains at risk and what you recommend next. If an important commitment was missed, address it directly. A well-documented experiment does not remove responsibility for its consequences.

What Success Looks Like After 90 Days

You do not need to have repaired every process or written a grand strategy. Look for observable changes: responsibilities are clearer, commitments receive follow-up, risks are discussed earlier, and the team can explain why you are making the first changes together.

If you still have more questions than answers, that is normal. You should have better questions than you had on day one and a practical way to work through them.

Start by copying the planning template and filling in what you already know. Take the unanswered expectations to your manager. That first agreement gives you something to work from when the calendar fills up and everyone has a different idea of what you should do next.