First 90 Days as Engineering Manager in a 20-Person SMB

The “first 90 days” advice you’ll find on the internet was written for someone joining a 2,000-engineer organization with a People Ops department, a leveling framework, and 6 months of runway before anyone expects measurable results.

If you’re a new engineering manager at a 12-, 18-, or 30-person company, you don’t have any of those things. Your team needs decisions next week. The CEO is asking when velocity will improve. Two of the senior engineers have been on the team longer than you. And the previous manager either left in frustration or never existed because the role just got created.

This guide is the 12-week framework we use with engineering managers in our coaching program. It assumes a 5–50 person engineering team and a manager who has, at most, 6 weeks of runway before someone visibly expects results.

The Three-Phase Structure#

We split the 90 days into three deliberate phases. Each phase has hard exit criteria. Do not skip phases. The most common pattern of failure for new EMs is starting interventions in week 2 — before they understand the system they’re trying to change.

Phase 1 — Listen (Weeks 1–3)#

What to do#

• 30-minute 1:1 with every team member in the first 10 working days. No agenda template — just open questions: What works? What doesn’t? What would you change if you could? What do you need from me?
• Document everything in a private decision log. Not minutes — observations, patterns, recurring complaints, contradictions between what people say and what code shows.
• Read the last 6 months of incident retros. They reveal the team’s actual pain points, often more than 1:1s do.
• Read the last 30 days of merged PRs. You’re learning the codebase’s social structure: who reviews whose code, where review wait times spike, what kind of changes get blocked.

What NOT to do#

• No decisions. Even small ones. “We should change X” is a Phase 3 statement. In Phase 1 you say “interesting, tell me more.”
• No promises. People will lobby for their preferred change. Acknowledge, don’t commit.
• No reorganization announcements. Even if it’s obvious that the team is structured wrong.

Exit criteria for Phase 1#

• 100% of team members had their first 1:1.
• You can explain, in writing, the team’s three biggest pain points and three sources of pride.
• You can name the de facto technical leader (often not the person on the org chart).

If you can’t meet these in 3 weeks, extend Phase 1 by a week. Do not start Phase 2 with incomplete listening.

Phase 2 — Diagnose (Weeks 4–7)#

What to do#

• Instrument DORA metrics if not already in place. You need objective data before you start changing things. The 4-week DORA implementation roadmap fits perfectly into Phase 2.
• Map workload and ownership. Who owns what? Where is ownership unclear? Where are two people accidentally owning the same thing? This is often a major source of conflict that nobody articulates.
• Identify the unspoken bottlenecks. Every team has them — the senior engineer who reviews 70% of PRs, the database migrations that nobody else can write, the deploy process that only works when one person is on call.
• Write a 2-page diagnosis for your own manager (CEO, VP Eng, founder). Not yet for the team. Not yet for action. Just an honest assessment of where the system is and where it’s leaking.

What NOT to do#

• No team-wide announcements about findings. Your diagnosis is provisional until your manager weighs in. Sharing prematurely commits you to an analysis you haven’t pressure-tested.
• No reorgs. Reorgs in the first 90 days have a documented bad track record — the new manager doesn’t yet have the context to design them well.

Exit criteria for Phase 2#

• DORA metrics flowing into a dashboard you can read.
• Written diagnosis (2–4 pages) shared with your manager.
• Your manager has acknowledged the diagnosis and approved the broad direction of intervention.

Phase 3 — Intervene (Weeks 8–12)#

What to do#

• Pick exactly 3 interventions from your diagnosis. Three is enough to show seriousness, few enough to actually ship in 5 weeks.
• Communicate the why before the what. When you announce the intervention, the team should already understand the problem. If they don’t, your Phase 1 listening was incomplete.
• Ship the interventions. Not “design committees” or “discovery phases” — actual changes that produce visible artifacts (a merged PR, a published policy, a new role announced).
• Measure the effect. This is why DORA from Phase 2 matters — you need a baseline to measure intervention impact against.
• Reserve 50%+ of your time for the team’s existing work. New EMs often try to “fix the system” full-time and starve the team of management capacity. Don’t.

What NOT to do#

• Don’t announce more than 3 interventions. You will be tempted. Resist.
• Don’t change interventions mid-quarter. If one isn’t working at week 11, finish it through week 12 and re-evaluate in your end-of-quarter retrospective.

Exit criteria for Phase 3#

• 3 interventions shipped, with team-visible artifacts.
• Initial metric movement on the targeted DORA dimension (or, if not, a written hypothesis why and what you’ll try next).
• Team retro with you about the 90 days — what worked, what didn’t, what you’ll do differently in the next quarter.

Common Pitfalls#

In our coaching program, we see the same five mistakes from new EMs:

1. Starting Phase 2 in week 2. “I have a CS background, I can already see the problems.” You can’t. You’re seeing surface symptoms. Listen.
2. Doing 1:1s as status updates. If your 1:1s are “what are you working on” instead of “what’s blocking you, what do you need,” you’re using the most leveraged tool in management as a glorified Jira sync.
3. Avoiding the de facto technical leader. Often this is a senior engineer who didn’t want the manager job. Treat them as a peer-stakeholder, not a subordinate. Ignore them at your peril.
4. Reorging in the first quarter. The data on this is unambiguous: first-quarter reorgs by new EMs fail more than they succeed.
5. Underestimating the founder/CEO interface. If you don’t actively manage the relationship with whoever you report to, they will fill the vacuum with their own narrative. Send weekly written updates from week 1.

Templates We Use#

The templates below are part of the public-domain set we use with our coached EMs:

• First 1:1 doc — open-ended question template designed for discovery, not status
• Decision log — Notion database template for capturing observations during Phase 1
• Phase 2 diagnosis template — 2-page format for the writeup to your manager
• Phase 3 intervention tracker — simple matrix for the 3 chosen interventions, baseline, target, observed outcome

Get the templates → (free with any EM coaching engagement; happy to share standalone if you ask.)

What Happens After Day 90#

The framework ends. By month 4 you have enough context to make calls without scaffolding. Your job from month 4 onward is to sustain the interventions you started, run a quarterly retrospective with your team, and start coaching your seniors. We cover the senior 1:1 framework next: The 1:1 Coaching Framework for Senior Engineers.

If you’re a founder reading this and wondering whether to hire an EM or do this yourself: see From Founder to CTO: Scaling Tech Leadership Past 30 People.