● 10 min read · 2052 words

Your First 90 Days as an Engineering Manager

Why this chapter exists

There is a specific kind of damage a new engineering manager can do in the first three months that is hard to undo later. Not catastrophic decisions — those are easier to roll back because everyone sees them coming. The damage I mean is quieter: reorganizing before you understand the team, picking sides in a disagreement whose history you don’t know, starting three initiatives in your first month because it “feels like action,” committing to dates you can’t hit because you’re trying to prove you’re in control.

The first 90 days is the one period where you have explicit permission to listen, to not know, and to not commit. Use it. You won’t get another window like this until you change jobs again.

This chapter is built around one assumption: your job in the first 90 days is not to execute. It is to earn the right to execute later.

Credibility is never given — it is always gained. Your title gets you the meeting. Everything after that depends on what you actually do in front of the team in the next 90 days. Plan accordingly.

The most common new-EM mistake is jumping to execution before establishing trust. Running fast in the first 30 days is not a positive signal — it usually means you’re avoiding the slower, less visible work of figuring out what’s actually going on.

Inherited team vs. built team

The playbook changes depending on how you arrived.

If you inherited a team (you got promoted, or you were hired to run a team that already exists), your biggest risk is disrupting something that works before you understand why it works. The instinct to “put your stamp on things” is the single fastest way to lose trust with a team that was doing fine without you. You’ll know you’ve earned the right to change things when your team starts proposing the same changes to you first.

If you built the team (you started with nothing and hired it), your biggest risk is different: you’re too close to everyone, you overvalue loyalty and shared history, and you defer hard conversations because the team is small and intimate. The fix is the same hard conversations you’ve been avoiding; the warning is that you probably need to have them sooner than feels comfortable.

If you’re the company’s first EM (e.g., hired into a founding team of engineers), you’re managing sideways and upward more than downward. The founders hired you because they ran out of bandwidth, not because they agreed with each other about what management should look like. Align with them explicitly in your first two weeks on what “good” looks like — otherwise you’ll be graded against three different rubrics and fail against all of them.

The 30/60/90 shape

A rough frame, not a contract. Adjust to the reality you find on day one.

Days 1–30: Listen, map, and do not rearrange

Your only real deliverables this month are:

• A map of the team — who does what, who relies on whom, where the expertise lives.
• A map of the work — what’s in flight, what’s stuck, what’s technical debt, what’s politically charged.
• A strength-and-gap read on every direct report.
• A stated 1:1 cadence and format so people know what to expect from you.
• One credibility moment — something concrete you unblocked, explained, or cleaned up.

That’s it. Do not reorganize. Do not rewrite the OKRs. Do not announce a new process. Do not commit to a roadmap.

What “listening” actually looks like in week one:

1. 30–45 minute intro 1:1s with every direct report, in the first 5 days. Script is the same for everyone: How did you end up here? What are you working on? What’s going well? What’s broken? If you were me, what would you change in the first month? What should I not change? Write their answers down in the same format for everyone — patterns emerge fast when the data is consistent.

2. 15–30 minute meetings with adjacent managers and cross-functional peers. Product, design, the other EMs, and your manager. Ask them what they think your team does well, where your team lets them down, and what they hope changes with you in the seat. Some of this feedback will be wrong; all of it is signal.

3. Skip-levels with at least a sample of the org above and below. If you’re managing managers, talk to their reports. If you have a manager, talk to their peers. You want a 360-degree picture, not just the view from your own org chart.

4. Ride along with the work. Sit in on standups, code reviews, design reviews, incident calls. Don’t participate — observe. Count who talks, who doesn’t, who gets interrupted, who interrupts. Watch the dynamics, not the content.

5. Read. Every design doc from the last two quarters. Every postmortem. The last 3–6 months of retrospectives. The performance reviews from the last cycle (if you inherited the team). You’re looking for themes, not items.

Output of the month: a written one-pager. What you heard, what the team is good at, what the team is bad at, what you think the top three problems are, and what you’re not doing yet and why. Share it with your manager. Do not share it with the team yet.

“Listening for 30 days” sounds passive. It is not. It is the hardest, most deliberate thing you’ll do all year. If you can’t resist acting in the first month, you are not listening — you are performing listening while still making decisions.

Days 31–60: Build trust, make one visible bet, earn the right to ask more

In month two you begin to act — carefully, in a small number of places, on things your team already wanted fixed.

• Pick one problem your team has been complaining about, and solve it. Not a strategic one. A tactical one. The flaky test everyone hates. The ambiguous ownership for incident response. The meeting that everyone agrees is useless. Fix it publicly. This is your first credibility deposit; most of what comes later depends on it.

• Formalize your operating cadence. Weekly 1:1s, set agenda, documented notes, action items tracked. Weekly team ritual (standup or async update — pick one). Monthly skip-level or team health pulse. Quarterly retro on your own performance as their manager.

• Write your first strength map. See People Management Fundamentals. Do it privately. It will be wrong — validate it over the next month in 1:1s and skip-levels before trusting it.

• Have your first real conversations about growth. Not performance reviews — those are a different thing. Ask each engineer where they want to be in 12 and 24 months, and what they think they need to get there. Write it down. This will matter more than you expect when promotion season comes.

• Name the problems you’re going to work on. Share a short note with your team: “Here’s what I’ve heard, here are the three things I think are worth fixing, here’s what I’m going to start on, here’s what I’m not going to start on yet and why.” Specificity here is a gift. Vague mission statements (“we’re going to raise the bar”) read as corporate noise.

Days 61–90: Commit, set the operating rhythm, install the first system

Now you start to lead on substance.

• Commit to a specific team operating model. Sprint cadence, definition of done, on-call rotation, release process. If inherited ones are working, say so explicitly — “we’re keeping this because it works.” If they’re not, propose the change and timeline.

• Deliver at least one non-trivial outcome. Something your predecessor couldn’t or wouldn’t ship. Not a transformation — a completed loop. “We closed the on-call runbook gap.” “We shipped X feature that had been stalled.” “We hired the engineer that team needed.”

• Make the first hard people call you owe. If there’s someone who was already underperforming when you arrived, you’ve had 60 days to see the evidence firsthand. Month three is when you either commit to investing in them or start the path that doesn’t. Letting this slide is the single most common mistake I see new managers make. The team already knows.

• Write your 90-day memo. What you learned. What changed. What didn’t change and why. Where you think the team will be in 6 and 12 months. What you still don’t know. Share it with your manager and — selectively — with your team.

The mistakes that are hard to walk back

These are the ones I wish someone had spelled out for me the first time.

1. Reorganizing in the first month. You don’t know enough. You are probably solving a problem that’s actually a people problem by making it look like a structure problem.

2. Picking sides in conflicts with history you don’t know. Two engineers disagree about X. You weren’t there when X started. Pick a side based on the 10 minutes of context you have, and you will either be wrong, or right for the wrong reasons, and either way you’ll have taught the team that politics works on you.

3. Announcing priorities before you understand constraints. If you tell the org “we’re going to focus on reliability this quarter” in week two, and week four you find out the CEO committed to three features for a big customer, you are now the EM who reversed themselves in a month. Not a good look.

4. Matching your predecessor’s style because it’s easier. You are not them. Copying their habits — especially the ones that caused the problems you were brought in to fix — is the path of least resistance and maximum slow damage.

5. Promising dates. Your team will ask when something ships. Your manager will ask when something ships. In month one, the correct answer is “I don’t know yet — here’s when I’ll have an answer.” This is the last time in your career where that answer is acceptable without pushback. Use it.

6. Going silent. The opposite failure mode. You listen for 30 days, then for 60, then for 90, and nothing ships. Listening is a means, not an end. If the team doesn’t see concrete motion by day 45, they will decide you’re indecisive, and that belief is very hard to recover from.

Setting up the habits you’ll keep for years

A few habits to lock in while the newness gives you permission to set expectations:

• Weekly 1:1s, owned by the report. They set the agenda, you bring topics only when nothing else fills the time. Never cancel — move, don’t drop.
• Office hours or an open Slack channel. One predictable time or surface where anyone on the team (including skip-levels) can reach you without scheduling.
• A decision log. A running doc of the non-trivial decisions you’ve made and why. Future-you will be grateful. See Project Execution for a template.
• A personal retro, monthly. Thirty minutes. What worked, what didn’t, what you will do differently next month. Write it down. Read it before the next one.
• A “what I don’t know” list. Start it on day one. When someone asks you something you can’t answer, add it. Close items when you can. This is your roadmap for earning expertise.

If you do only one thing from this chapter: write a weekly note to yourself — private, unshared — capturing what you observed, what surprised you, what you’re unsure about. Reread it every four weeks. The patterns you’ll see in your own notes are the closest thing to a truth serum this job offers.

When the 90 days are up

You’ve done this right if, at day 91, three things are true:

• Your team could tell a coherent story about what you care about and what you’re trying to do — and it matches what you’d say if asked.
• You have at least one concrete outcome that your manager can point to as evidence you’re working out.
• You know which of your reports are thriving, which are stuck, and which are probably going to leave — and you have a specific plan for each of those cases.

If any of those three is missing, the gap is usually not “I need more time.” It’s usually “I was too busy being seen to do the slower work.” Write down which one, and start there in month four.