Guides for engineering managers

Your first 90 days as an engineering manager

A week-by-week plan for new engineering managers, from the listening tour to setting direction, plus what to stop doing as an ex-IC.

Keel team · 15 October 2026 · 7 min read

Most first-time engineering managers get the job because they were good engineers. Then the feedback loop disappears. As an engineer you knew by Friday whether the week went well: the code shipped or it didn't. As a manager your work shows up weeks or months later, in how the team performs, and it is easy to spend the first quarter busy and unsure whether any of it mattered.

This guide is a plan for those first 90 days. It works whether you were promoted from inside the team or hired in from outside, with a few differences we'll point out.

Days 1 to 30: listen before you change anything

Your first job is to understand the team, the work and the people, well enough that your later decisions are right. New managers often feel pressure to act quickly. Resist it for a few weeks, but not forever: as one fractional CTO puts it, "nobody trusts a consultant who spends a month assessing and has nothing to show for it". The same applies to you. Listen with a deadline.

The listening tour

Book a first 1:1 with every direct report in your first week, then 30 minutes with the people around the team: your peer managers, the product manager, design, support, and whoever leads the teams you depend on. Ask everyone the same few questions so you can compare answers:

• What is this team great at? What does it get credit for?
• What slows the team down, or frustrates you most?
• If you were in my seat, what would you change first?
• What should I definitely not change?
• Who else should I talk to?

Write the answers down. By the end of the tour you will see themes, and a theme raised by five people is a much safer place to act than something one loud voice told you.

Read the system, not just the people

Alongside the conversations, read the evidence. Skim the last few months of merged pull requests, the open and stale tickets, recent incident write-ups, and how often the team deploys. Look at who reviews whose code and who gets asked questions in Slack. This tells you where the knowledge sits, where work gets stuck, and who is doing the glue work that nobody mentions.

If you were promoted from inside the team

Your relationships change overnight, even with people you've worked beside for years. Say so out loud in your first 1:1s: "I know this is a bit strange. I want to keep working well together, and I'll need you to tell me when I get this wrong." Don't pretend nothing has changed, and don't suddenly become formal either.

Set expectations with your own manager

Many new managers never have this conversation, and then discover at review time that their manager wanted something different. In your first two weeks, ask your manager directly:

Then write a short summary and send it back: "Here's what I heard. Correct me if I've got it wrong." Return to it at day 30 and day 60. It turns a vague new job into something you can be measured against fairly.

1:1s from week one

Weekly or fortnightly 1:1s with each report are the single most important habit to set early. The first one is mostly getting to know each other: how they like to work, how they like feedback, what they want from their career, and what has frustrated them about past managers. After that, let them own the agenda and use the time for what they need, not for status updates.

Keep a short running note per person from the start. One line after each 1:1, with the date, is enough. Six months from now, when you write your first performance reviews, you'll be very glad it exists. We go into structure, questions and note-taking in detail in our 1:1 template for engineering managers.

Days 31 to 60: first wins

By now you know the recurring complaints. Pick one or two that are small, visible and fixable within a few weeks. Good first wins are usually about friction, not strategy:

• A flaky test suite everyone has learned to rerun
• A recurring meeting nobody finds useful, cancelled or cut in half
• A painful on-call rotation, rebalanced or given a proper runbook
• A long-blocked decision with another team, finally made
• Unclear priorities, written down in one place the whole team can see

Credit the people who raised the problem. The point of a first win is less the fix itself and more showing the team that when they tell you something, things change.

Hold back on big changes like reorganising the team, rewriting the process, or replacing the architecture. Some of what looks broken has reasons you haven't found yet. Ask "why is it this way?" at least once before changing it.

Days 61 to 90: set direction

With trust built and a few things fixed, you can start shaping how the team works. Share what you learned from the listening tour with the team, including what you heard and what you plan to do about it. Agree goals for the next quarter. Make sure every report knows what is expected of them at their level and has at least one growth goal you are actively supporting.

This is also when to address any performance issue you've seen. Don't wait for the review cycle: name it in a 1:1, with a specific example, and agree what better looks like.

What to stop doing as an ex-IC

The hardest part of the transition is letting go of the things that made you successful as an engineer.

• Stop taking the critical-path tickets. You will be pulled into meetings at the worst moment, and the team will wait on you. Pick up small, non-urgent work if you want to stay close to the code.
• Stop being the default answer. When someone asks you a question you could answer in ten seconds, sometimes ask "what do you think?" instead. It builds people who don't need you.
• Stop rewriting other people's code in review. Explain the concern and let them fix it. Your code taste is now a suggestion, not a standard.
• Stop measuring your week by what you shipped. Measure it by what the team shipped, who you unblocked, and which problems you prevented.
• Stop saving all feedback for later. Small, prompt feedback in the moment is kinder and more useful than a surprise in a review.

A note on scope

Many new managers inherit more than a classic team. In LeadDev's Engineering Leadership Report 2026, 63% of engineering leaders said their scope grew and 45% said they work more hours than a year ago. If your team is large, the listening tour takes longer and the running notes matter more. Don't skip either to save time.

Keep going

Your first 90 days set the habits you'll rely on at your first review cycle. When that arrives, our guide on how to write an engineering performance review walks through it step by step, and brag docs for your whole team shows the lightweight note-keeping that makes it easy.