Your first 90 days as an engineering manager
What the 30-60-90 plan doesn't cover.
You just became an engineering manager. Maybe you were promoted from the IC track. Maybe you joined a new company as an EM with a few years of management under your belt. Either way, someone probably told you: make a 30-60-90 day plan.
They’re not wrong. Understanding your team’s tech stack, reviewing recent delivery metrics, reading the last few retros, getting familiar with the OKRs — these are all real and they all matter. There are good resources that cover this well. First Round Review’s 90-day guide and LeadDev’s new manager plan are both worth reading if you want a solid checklist.
But here is what those guides don’t tell you: the IC-to-EM transition and the experienced-EM-at-a-new-company transition look identical from the outside and are completely different on the inside. They have different failure modes. They require different things from you. And conflating them is how good managers have bad first 90 days.
Two transitions. Two failure modes.
If you are making the IC-to-EM jump, your biggest risk is staying too comfortable technically. If you are an experienced EM joining a new company, your biggest risk is moving too fast.
Both of these come from the same place: fear. The new manager fears that if they are not a technical expert in everything their team works on, they are not qualified. The experienced manager fears that if they don’t show visible impact quickly, they don’t belong. Both responses are understandable. Neither helps you.
The IC-to-EM trap: you are not the expert anymore
When I made the IC-to-EM transition, I came from an Android and mobile background. My team included backend engineers whose work I had almost no experience with.
My approach, for a while, was avoidance. I stayed close to mobile and web decisions, the areas I was comfortable in, and let backend discussions pass me by. In 1:1s with backend engineers, I felt imposter syndrome. My mental model at the time was that being a good EM meant being a technical expert in everything on your team. Since I clearly wasn’t, I kept quiet, skimmed the surface, and hoped nobody noticed.
Here is what I actually needed to do: embrace the discomfort instead of managing around it.
The fix was counterintuitive. I started deliberately over-indexing on backend. Less time on mobile and web, where I was already comfortable, more time on backend. I picked up actual backend tickets and worked on them. Not as a tech lead, as a junior engineer learning the codebase. It felt humbling. It also worked.
Shipping those tickets gave me something I couldn’t get from reading docs: an understanding of the real challenges those engineers faced day to day. The 1:1s changed after that. I could ask better questions. I stopped needing to be looped into every backend decision because I trusted the engineers more, and they trusted me more.
The point is not that you need to become an expert in your weakest domain. The point is that your job is to create the conditions for experts to do their best work. You cannot do that for engineers whose work you have deliberately avoided learning. Lean into the uncomfortable part. Avoiding what you don’t know doesn’t make you feel more qualified. It just makes the gap feel bigger.
The experienced EM trap: your playbook is not universal
If you are already an EM joining a new company, the failure mode is different. You know how to manage. You have frameworks, processes, ways of running retros and 1:1s that have worked before. That experience is real and it matters. The risk is not your playbook — it is applying it before you understand the context it is landing in.
What “good EM” means varies more than most people expect. The behaviors that got you promoted at a startup may land differently at big tech. An M1 at one company has different expectations than an M1 at another. The team dynamic, the engineering culture, the relationship between EM and product — all of it differs. The question is not whether your instincts are good. It is which ones fit here, and you will not know that until you have spent time listening.
When I joined a new company as an EM, my manager mentor built me a 12-week onboarding plan. Week by week: who to meet, what to read, which meetings to observe before running. The structure was deliberate. Month 1 was about people. Month 2 was about building broader connections. Month 3 was about taking ownership and experimenting.
That order mattered. It prevented me from doing what most experienced EMs do: making visible changes before understanding what you are changing and why.
Before you change anything, understand how results happened, not just whether they happened. A team that shipped on time through three consecutive crunch cycles is a different situation than one that shipped sustainably. That distinction shapes what you actually need to do in Month 2. The metrics alone will not tell you. The retrospectives, the old tickets, the informal conversations will.
Today, you can build this context faster than earlier. Feed old wiki pages, Jira tickets, PRs, and recorded meetings into an AI tool. Ask it to surface recurring themes, past decisions, open technical debt. You can build a useful memory map of the team’s history in hours.
What both transitions share
Regardless of which track you are on, there are a few things that apply equally.
Build relationships wider than your immediate team. Your direct reports and your product manager are obvious. Go further: your manager’s manager, peer EMs in and outside your org, cross-functional partners. The connections you make in the first 90 days become your network for years. Do not wait until you need something to start building them.
Use the 1:1:1 format for every direct report. A transitional 1:1:1 is a meeting with you, your direct report, and either their previous manager or a director who knows them well. It gives you context about a person that regular 1:1s cannot. Use it within your first month with everyone on your team.
Set up two separate clarity tools early.
With your manager, establish the four buckets of discretion: what decisions does she want to make herself? What does she want to decide together with you? What does she want you to decide and inform her about? What does she not need to know? This calibration prevents a lot of confusion about when to escalate.
With your cross-functional partners, set up a simple RACI for each significant relationship — product manager, TPM, scrum master. Clarifying who is Responsible, Accountable, Consulted, and Informed on key decisions early makes everyone’s life easier and signals that you are serious about operating cleanly.
Ask your manager to define success in concrete terms. In your first two weeks, have this conversation:
How do you define success for me in this role?
Where do you see me in one year?
What are the table stakes I need to deliver on at my level?
This is the most consistently skipped step in any EM’s first 90 days. Understanding what success looks like across the dimensions that matter at your level — technical credibility, people growth, project ownership, roadmap and vision — and which of those dimensions carries the most weight here, gives you a real plan for the year ahead. It also signals to your manager that you are proactive about your own growth, which sets the relationship up well from the start.
Know when to stop listening and start leading. Most advice about the first 90 days is about restraint: listen, observe, don’t change things too fast. That is correct. There is also a failure mode in the other direction. EMs who stay in listening mode indefinitely become passive. They are perceived as lacking opinions or confidence.
Once you have built real context, usually around the 4-6 week mark, start voicing what you are observing and what you would like to try. Not as mandates. As experiments. “Here is what I am seeing, here is what I want to try for 30 days, here is how we will know if it worked.” That framing invites the team into the change rather than imposing it. And it keeps you honest: if you cannot articulate the hypothesis, you probably do not have enough context yet.
A note on senior transitions
One thing worth naming, especially for EMs joining at a more senior level: 90 days may not be enough time to feel fully settled, and that is okay.
The more senior the role, the larger the scope, the more complex the stakeholder landscape, and the higher the expectations. Getting comfortable takes longer. Having an impact takes longer. That is not a sign that something is wrong.
Be patient with yourself. Keep having honest conversations with your leadership and your team about where you are and what you need. Do not measure yourself against an arbitrary timeline. The foundation takes as long as it takes, and rushing it rarely ends well.
The 12-week template
Structured onboarding is not something every company provides. Most do not.
I have put together a generic 12-week onboarding template that you can adapt to your own situation. It covers who to meet and when, what to read and in what order, and what to take ownership of across the three months.
Download the 12-week EM onboarding template
If you are a new EM or about to start a new role, use it as a starting point. Adjust it to your context. Share it with your manager in your first week and ask them to add to it.
The first 90 days sets the foundation for the years that follow. The goal is not to look competent. The goal is to get competent, build trust, and earn the right to lead.