The Engineering Manager's First 90 Days: A Working Plan

Build a practical first-90-days plan for engineering management with clear responsibilities, evidence-led feedback, one bounded improvement and a realistic team plan.

Use 90 days as a planning horizon, not a verdict

You have accepted an engineering-management role. Your first job is to learn what the team needs, make your responsibilities clear and help people deliver work without concealing risks. That requires action as well as listening. An unresolved security issue or harmful behavior cannot wait for the end of a listening tour.

The plan below assumes an existing team with ongoing delivery. Adapt it for a new team, a turnaround, an interim appointment or a major incident. The dates are suggested check-in points, not evidence that you should have diagnosed every person or settled a six-month roadmap.

If you are still deciding whether management is the right role, start with the engineer-to-manager transition guide. This article covers onboarding after that decision.

Before the calendar fills: agree the role

Meet your manager and the technical and product leads. Write down which outcomes the team owns, which commitments already exist and which decisions you can make. Ask who handles hiring, compensation, formal feedback, security exceptions and incident escalation. Identify a People or HR partner for situations that require their involvement.

Transfer your previous delivery obligations explicitly. If you remain the sole owner of a critical implementation, a new title has not created capacity for management. Name the receiving owner, remaining work and support you will provide.

GitLab's engineering-manager onboarding guidance is a useful example of treating manager onboarding as distinct work. Its organization-specific process is a reference, not a schedule every company should copy.

Use this working plan with your manager:

| Period | Useful output | Review question | | --- | --- | --- | | Days 1–30 | Role agreement, team context and a short risk list | What do we know, and what rests on one person's account? | | Days 31–60 | One bounded improvement with an owner and evidence | Did it help without moving the problem elsewhere? | | Days 61–90 | Agreed team priorities, support needs and operating rhythm | Can the team act without waiting for me on every decision? |

Keep the plan small enough to discuss regularly. If an urgent issue displaces planned work, record what moved and why. Do not silently add both workloads.

Days 1–30: learn how work actually happens

Hold one-to-ones with team members, then meet the people who depend on the team. Ask for recent examples: a delivery that went well, a decision that stalled, a production problem, or work that became difficult for reasons outside the team's control.

Useful prompts include: What are you trying to achieve? Where do expectations feel unclear? What should I avoid disrupting? What support would make the next commitment more realistic? Avoid asking people to rank their colleagues. You are gathering context, not building a popularity-based performance assessment.

GitLab's one-to-one guidance offers a primary example of using these conversations for feedback and development as well as work concerns. Agree the purpose, follow-up and privacy boundaries with your own team. Do not promise absolute confidentiality when safety or company policy may require escalation.

Trace one recent piece of work from request to production. Compare the written process with what happened: review delays, test ownership, release approval, customer acceptance and operational follow-through. Read relevant incidents and unresolved actions. Few postmortems could mean fewer incidents, weak reporting or unfinished learning; the document count alone does not tell you which.

Keep two separate records. A shared delivery-risk log can include dependencies, decisions and owners. Sensitive individual notes belong only in approved systems with appropriate access and retention rules. Do not copy private feedback into a public team dashboard.

Days 31–60: test one useful change

Choose a problem that the team recognizes and that you have authority to address. A good first change has a narrow scope, a named owner and a way to tell whether it made work easier. Buying a tool or cancelling a meeting is not automatically an improvement.

Consider this hypothetical team. Releases stall because the same reviewer handles every database change. The reviewer is also responding to incidents. Adding a deadline for reviews could increase pressure without fixing the dependency.

| Item | Example agreement | | --- | --- | | Problem | Database changes wait for one person; the cause needs confirmation. | | Trial | Pair a second reviewer on a bounded class of low-risk changes. | | Evidence | Record queue time and why changes waited; inspect review quality and rework. | | Boundary | High-risk migrations retain the existing specialist review and release controls. | | Review | Decide whether to extend, adapt or stop after the agreed trial period. |

This is a proposed experiment, not an Ampity client result. The second reviewer needs training and time. If pairing displaces urgent delivery, expose that tradeoff before starting. A shorter queue with more escaped defects is not a successful outcome.

Explain what you heard, what you chose and what you did not choose. Close the loop even when a request cannot be fulfilled. Trust is built through observable behavior, not a percentage assigned to a metaphorical battery.

Give feedback when there is evidence, not when a date arrives

Do not decide that someone is an underperformer because day 60 has arrived. Establish the role expectation, the person's understanding of it, the observed behavior, available support and relevant constraints. Seek their account before drawing conclusions. A pattern of missed commitments may involve unclear scope, dependencies, workload, skills or behavior, and those require different responses.

A hypothetical feedback opening could be: “In Tuesday's release review, you spoke over Morgan before the rollback concern was explained. We moved on without deciding who would test recovery. What was happening from your perspective?”

That identifies a situation, behavior and impact without claiming to know intent. The next step might be an agreed meeting practice and a follow-up observation, not a formal personnel action. For persistent performance concerns, use the organization's documented process with the appropriate manager and People partner. For harassment, safety or serious misconduct concerns, escalate promptly through the designated channel rather than waiting for more examples.

The purpose of early feedback is clarity and support. Avoid surprise judgments at the end of probation or an onboarding period.

Days 61–90: turn observations into a team plan

Create a short plan with the technical and product owners. Separate committed delivery from discovery work and desired improvements. For each priority, record the customer or operational need, acceptance evidence, dependencies, owner and decision needed if capacity changes.

Do not promise a roadmap merely because the calendar says it is time. When information is missing, commit to resolving that uncertainty. For example, agree a migration rehearsal before fixing a cutover date.

Review these questions with the team and your manager:

• Are responsibilities and escalation paths understood?
• Have urgent risks been handled within the right authority?
• Do people receive specific feedback and know where to get help?
• Did the first improvement reduce the intended friction without harming quality?
• Can the team explain its next commitments and the conditions behind them?
• Is critical knowledge shared well enough for leave, incidents and handover?

Use delivery evidence, reliability outcomes and candid conversations together. A cheerful meeting or a low incident count cannot establish team health on its own. Invite disagreement privately as well as publicly, and account for the power difference when interpreting feedback.

Leave the team with a clearer operating model

At the 90-day review, summarize what changed, what remains uncertain and what support you need. Include commitments you stopped or narrowed, not just new initiatives. Ask your manager and team which of your actions helped and which added work.

When a bounded delivery scope needs additional ownership, Ampity's engineering-pod model is an execution option to evaluate with explicit responsibilities and acceptance criteria. It is not a substitute for the team's manager, a promise of leadership coaching or a solution to unresolved personnel issues.