Your First 30/60/90 Days as a New EM

Three weeks ago you were a senior IC. Today your calendar has 14 hours of meetings on it, 26 hours of "open time," and a Slack DM from your skip-level that says "let me know if you want to grab coffee this week." You still have merge access. You still know exactly which file to open to fix the bug that just paged the on-call engineer. And that, right there, is the trap.

Most new EMs default to coding because it's safer than coaching. The Jira ticket has a definition of done. The 1:1 with the staff engineer who's quietly looking for another job does not. So the new EM ships a feature in week two, feels productive, and fails at the actual job for six months until their skip-level asks why team velocity hasn't moved and two people have resigned.

If you're still measuring your week in PRs merged, you've taken the title without taking the job.

Why 30/60/90 Matters

The window where your team forms an opinion of you is narrow. By day 45 they've decided whether you're a manager who's still pretending to be an IC, or an IC who's actually becoming a manager. They notice which meetings you cancel, whose 1:1s you reschedule, what you talk about when you do show up. They don't tell you what they decided. They just start adjusting their behavior around it.

The plan below is engineered to force the second outcome. Every 30-day block has three to five concrete deliverables, and every one of them is something you cannot do from your IDE.

Days 1–30: Listen, Audit, Show Up

This first month is information gathering. You will be tempted to fix things. Don't. You don't yet know what's actually broken versus what just looks broken from your old seat.

10 1:1s with reports in the first two weeks

If you have eight reports, that's roughly one 1:1 per day for two weeks plus a couple of 30-minute follow-ups. Same three questions every time:

1. What's the best thing about working here right now?
2. What's the worst?
3. If you were me, what would you change in the first 90 days?

Take notes by hand. Do not problem-solve in the room. The single biggest mistake new EMs make in early 1:1s is hearing a complaint and committing to fix it on the spot, then either fixing the wrong thing or breaking the promise three weeks later. "Tell me more" and "I want to think about that" are complete sentences.

By the end of week two you'll have 30 to 50 distinct observations. Patterns will emerge. Three reports will mention the same broken thing in different language. That's your map.

Audit team velocity and on-call rotation

Pull the last 8 sprints. You're looking for two things:

• Throughput trend. Is story points completed per sprint flat, climbing, or dropping? If it's dropping, when did it start? Tie it to events: a re-org, a scope change, someone going on leave.
• On-call distribution. Pull the page logs and count incidents per engineer for the last quarter. If three people are carrying 70% of the pages, you have a fairness problem and a burnout risk, and you didn't know about it last week because nobody complained loudly enough.

Document what you find. Do not fix it yet. The audit is a baseline you'll use in days 31–60 when you run your first retro.

Sit in 5 cross-functional meetings

Product planning. Design review. Sales enablement (yes, sales, because your team probably ships features that the AE team has to demo). Support escalation sync. The weekly your skip-level runs with their peer in another org.

You're not there to talk. You're there to learn what your team looks like from the outside. The product manager who praises your team in standup might roll her eyes about them in the cross-functional planning meeting. The support lead might mention three customer escalations you've never heard about. Your team's reputation lives in rooms you weren't previously invited to.

Take notes in those meetings about your team specifically. Bring observations back to your reports in 1:1s without naming who said what.

NO code commits

Hard rule. If a critical bug needs your hands, pair with an engineer and let them merge.

Every commit you ship in month one is a signal to your team that the old job is still available to you. They will route around you to ship faster. They will stop bringing you the messy human problems because they can see you'd rather be in code. You will feel productive and you will be fooling yourself.

The first time I told a senior engineer I'd pair with him on a gnarly migration but I wasn't going to push the commit, he looked annoyed for about ten minutes and then noticeably more comfortable for the rest of the quarter. He didn't want me typing in his repo. He wanted me thinking about everything else.

Days 31–60: Run One Thing, Fix One Thing, Say One Hard Thing

Month two is when you switch from input to output. Three deliverables, all of them small enough to actually ship in 30 days.

Run 1 retrospective

Your first as the facilitator, not a participant. Use the data from the velocity audit. The format doesn't matter much (start-stop-continue, mad-sad-glad, whatever your team uses). What matters is that you surface one uncomfortable pattern and let the room sit with it.

For example: "We're closing tickets but reopening 22% of them within two sprints. What's that about?" Then shut up. The first 90 seconds will be silent or full of deflection. Wait through it. Engineers will eventually say true things if you don't fill the silence with your own theory.

The first time I ran a retro as the manager, I talked for 18 of the 30 minutes. That was the lesson. Your job in a retro is to ask, summarize, and assign one or two follow-ups. Not to drive the conversation.

Fix 1 broken process

The smallest thing reports complained about in 1:1s that you can ship a fix for in two weeks. Not the giant org-design overhaul. The thing that's been annoying everyone for months that nobody's been senior enough or organized enough to just kill.

Real examples that have worked:

• Standup that runs 45 minutes: cut to 15, format changed to async-first with a 10-minute live sync only when blockers exist.
• PR review SLA of three days, frequently missed: published a one-page expectation doc, added a Slack reminder bot, named a backup reviewer per area.
• On-call handoff with no written runbook: required a 20-minute handoff meeting at the end of every rotation, with notes in a shared doc.

Pick one. Ship the fix. Tell the team you heard them. The point isn't the process improvement (although that's nice). The point is they wanted to see if you actually listen, and the answer is now yes.

Deliver 1 hard feedback conversation

The one you've been avoiding.

The senior engineer who's brilliant but bulldozes juniors in code review. The mid-level who keeps missing estimates by 3x. The tech lead who's checked out and the team is quietly working around them.

Script it before the meeting. Use the situation-behavior-impact-ask structure:

• Situation: "In yesterday's design review, when Priya proposed the queue-based approach…"
• Behavior: "…you cut her off twice and then said the design 'wouldn't work' without explaining why."
• Impact: "Two other engineers have told me they don't bring early ideas to the team channel anymore because they expect to be shut down. We're losing input we need."
• Ask: "I need you to let people finish their thought, and if you disagree, ask one question before you push back. Can you do that?"

Rehearse it out loud. Deliver it in a 1:1, never in a group. Allow silence afterwards. The conversation will feel terrible while you're having it and noticeably easier the second time. This is the conversation that proves to yourself you can do the job.

Days 61–90: Own Outcomes, Plan Forward

Month three is when you stop being "the new EM" and start being "the EM." Three deliverables, all of them visible to your skip-level.

Own a team OKR

Not "support the platform initiative." A specific, measurable outcome you'll be evaluated on at end of quarter.

Bad: "Improve developer experience." Good: "Reduce median PR review time from 38 hours to 12 hours by end of Q3, measured via the existing GitHub metrics dashboard."

Write it. Get your skip-level's signoff. Tell the team it's yours, not theirs. You'll defend the number, they'll do the work. This distinction matters because the team has watched too many managers shove an OKR onto their plate and then disappear when it slips.

Present a 90-day report to your skip-level

Three slides max. The structure that works:

• Slide 1, what I inherited. Velocity baseline, on-call distribution, top three risks I found, top three strengths. Two sentences each.
• Slide 2, what I shipped. The retro you ran, the process you fixed, the OKR you took ownership of. Concrete artifacts the skip can verify.
• Slide 3, what I'm asking for. The H2 hiring plan and the tech debt proposal (next item). Specific asks, specific costs, specific expected outcomes.

This is the artifact that earns you a second 90 days of trust. It's also what your skip-level will quote back to their boss when explaining why they promoted you. Make it easy for them.

Propose H2 hiring + tech debt plan

One open headcount with a JD you wrote (link the companion staff software engineer JD template) and a ranked list of the top 3 tech debt items with rough cost estimates.

Hiring plan should answer: what role, why this role and not a different one, what gets unblocked when they start, what the trade-off is if you don't get the headcount. One page.

Tech debt list should answer, for each item: what breaks today because of it, rough engineering cost to fix (in person-weeks), expected improvement (in measurable terms like 30% fewer pages, 2 weeks faster onboarding, whatever fits). Rank the three. Defend the ranking when challenged.

Submit it. Defend it. Even if you don't get the headcount or the tech debt budget, the act of writing and defending the plan is what moves you from "new EM" to "EM with a point of view."

The Real-World Failure Modes

Three predictable ways this plan goes off the rails.

The ex-IC pull to code

When your hands hurt to not type, that's withdrawal, not weakness. Block 90 minutes a week for "engineering time" (architecture review, reading PRs without merging, debugging a hard problem with a junior) and call it that. Do not call it coding. The label matters because it forces you to ask, every time, whether what you're about to do is mentoring or hiding.

The "I'm not really a manager" identity crisis

If you're still saying this in week six, your team has already noticed. They hear it as "I'm planning to go back to IC the moment this gets uncomfortable," which makes them less likely to bring you the uncomfortable things.

Replace it with: "I'm a manager who used to ship code. Now I ship people who ship code." Say it out loud the first time it feels weird. By week ten it won't.

The over-correction

The EM who reads three management books in week one and shows up Monday with a new framework, a new ritual, and a renamed standup. Reports hate this. They didn't ask for a new operating system. They asked for a manager who listens.

Listen first. Change second. The 30-day audit exists exactly so you don't do this.

Templates and Tools You'll Actually Use

Four artifacts worth building once and reusing forever:

• First 1:1 question script. The three questions above, plus three follow-ups: "What does a great week look like for you?" "Who on the team should I make sure to spend extra time with?" "What's something I should know that nobody's going to tell me?"
• 30-day observation log template. Three columns: what I heard, what I saw, what I'm not changing yet and why. The third column is the discipline.
• 90-day report template. Three slides, structure above, hard cap on word count per slide so you don't pad it.
• Hard feedback conversation script. Situation, behavior, impact, ask. Print it. Fill it out before every difficult 1:1 for the first six months.

Measuring Success at Day 90

You'll know the 90 days worked if all five of these are true on the last day:

1. Every report has had at least 6 1:1s with you and can name what you're working on for them.
2. Team velocity is measured and trending. Even if the trend is flat, you know exactly why.
3. One process is visibly better and the team gives you credit for it.
4. Your skip-level can describe your team's biggest risk in one sentence because you told them.
5. You haven't merged code in 90 days and the team is fine.

That last one is the real test. The 90 days are not about proving you can still code. They're about proving you can stop.

Learn More

• Running 1:1s Your Reports Look Forward To
• The Shift from Doing to Leading
• Managing Former Peers
• Staff Software Engineer JD Template