First 90 Days as an Engineering Lead: 30-60-90 Plan

The shape of the plan

Phase	Main goal	You should leave it with
Days 1–30: learn	Understand people, systems, work and expectations	A written summary of what you found, checked with your manager
Days 31–60: contribute	Make one or two visible improvements and start owning decisions	A working operating rhythm and early credibility
Days 61–90: lead	Set direction and measurable goals with the team	A plan for the next quarter that the team helped write

Adjust the pace to the situation. A team in the middle of an incident or a hard deadline needs you to contribute on day one. A stable team gives you more room to listen first.

Before day one

Ask your manager what success looks like at six and twelve months, and what worries them most.
Clarify the role: do you have direct reports, own performance reviews, or set technical direction alone? The differences are covered in engineering lead vs engineering manager.
Ask for the team's current roadmap, recent incident reports and any architecture documents.

Days 1–30: learn

People

Hold a first one-on-one with every engineer. Ask what is going well, what frustrates them, and what they would change if they were in your seat. A structure for these is in one-on-ones for engineering leads.
Meet the product manager, designer, and the leads of the teams you depend on or serve.
Find out how the team prefers to communicate, and when people do focused work.

Systems

Set up your environment and ship a small change yourself. It reveals friction faster than any document.
Walk through the architecture with the engineers who know it best. Draw it, then check your drawing with them.
Read the last few incident reports and find out which action items were never completed.
Find where the team's AI tools are used, which ones are approved, and what data they are allowed to see.

Work and expectations

Map what is in progress, what is committed, and who is waiting on the team.
Learn how delivery is tracked today and what numbers leadership watches.
Note the known technical debt and how the team feels about it.

End of month one: write a one-page summary: strengths to protect, problems you see, questions you still have. Share it with your manager, and then with the team. Being checked and corrected early is cheaper than acting on a wrong picture.

Days 31–60: contribute

Pick one or two improvements. Choose problems the team already named, that you can finish within a few weeks, and that people will notice: a flaky test suite, a confusing on-call handoff, pull requests that wait days for review.
Establish your operating rhythm. Regular one-on-ones, a planning cadence, a way of reporting progress and risk upward.
Start owning technical decisions. Run a design review. Write down a decision and its reasoning, so the team can see how you think.
Review code with intent. Your reviews teach the team your standards. Set expectations for AI-assisted changes early; see reviewing AI-generated code.
Take a turn on call, or shadow the rotation, if the team runs one.

Days 61–90: lead

Set goals with the team. Agree on a small number of outcomes for the next quarter, and how you will know they happened. Use the goal format your company already uses.
Choose a few health measures. Delivery and quality measures at team level, not individual output. See measuring engineering work.
Make a plan for technical debt. Name the items that matter most and agree on how capacity is reserved for them. See prioritizing technical debt.
Talk about growth. Have a career conversation with each engineer, and agree on one development goal each.
Review your own 90 days with your manager: what went as planned, what did not, and what you will focus on next.

A template you can copy

My 30-60-90 plan

Role as agreed: scope, reports, decisions I own.
Success at 6 months looks like: two or three sentences from my manager.
Days 1–30, learn: people to meet; systems to understand; questions to answer.
Days 31–60, contribute: improvement 1; improvement 2; rhythm to set up.
Days 61–90, lead: team goals; health measures; debt plan; growth goals.
Check-ins: dates for review with my manager at days 30, 60 and 90.

Signs you are on track at day 90

Engineers bring problems to you early, before they become urgent.
Your manager and product partner know what the team is doing next and why.
The team agreed on its goals rather than receiving them.
At least one improvement you started is finished and people noticed.
You know where your own gaps are, and have a plan for them.

Mistakes new leads often make

Changing things in week one before understanding why they are the way they are.
Becoming the team's top coder and the bottleneck on every critical change.
Avoiding the hard conversation about a performance problem because you are new.
Only managing upward and losing touch with how the team actually works.
Copying the last company's process without checking it fits this team.

Common questions

What if I was promoted from inside the team?

You can skip some of the learning, but not the conversations. Your relationship with former peers has changed. Say so openly in your first one-on-ones, and ask what they need from you now.

How much should I code in the first 90 days?

Enough to understand the system and the developer experience, usually small and non-critical changes. Avoid taking ownership of work that others will be blocked on while you are in meetings.

Should I present my plan to the team?

Share the learning summary and invite corrections. Teams trust plans they have shaped. A plan presented as finished in week one reads as a verdict.

What if the plan falls apart?

It often will. An outage, a reorganization or a changed deadline can reset priorities. Keep the phases, move the dates, and tell your manager what changed.