The First 90 Days as an Engineering Manager — What Nobody Tells You

The Promotion Trap

The best engineer on the team gets promoted to engineering manager. Within six months, the team has lost their best engineer and gained a mediocre manager. We see this pattern so often it's practically a cliché — but companies keep doing it.

The problem isn't the person. It's the assumption that technical excellence translates to management excellence. They're different jobs that require different skills.

Days 1-30: Listen and Learn

The biggest mistake new managers make is changing things immediately. You don't understand the system yet. Your first month is about building a mental model of the team.

The 1:1 Template for Week 1

Meet every team member individually. Ask these questions:

1. What's your biggest frustration right now?
2. What would you change about how the team works?
3. What do you wish leadership understood about your work?
4. What are you working on that you're most excited about?
5. What's blocking you that I could help remove?
6. How do you prefer to receive feedback?
7. What does career growth look like for you in the next year?

Don't promise to fix anything yet. Just listen and take notes. You're building a map of the team's real state — not the state that shows up in JIRA.

The System Audit

In parallel with 1:1s, audit the team's systems:

Process:
  □ How does work get planned and prioritized?
  □ What's the deployment process? How often do you deploy?
  □ What's the incident response process?
  □ How are decisions made? Who has authority over what?

Health Metrics:
  □ Deployment frequency (DORA metric)
  □ Lead time for changes (DORA metric)
  □ Mean time to recovery (DORA metric)
  □ Change failure rate (DORA metric)
  □ Team turnover in the last 12 months
  □ Number of open incidents/bugs

Culture:
  □ Are retrospectives happening? Are they producing action items?
  □ Is there psychological safety? Do people speak up in meetings?
  □ How is technical debt handled? Is there dedicated time for it?
  □ Are on-call rotations fair? Is anyone burned out?

Days 30-60: Identify and Act on Quick Wins

By day 30, you'll have a clear picture of the team's pain points. Pick 2-3 quick wins — things you can fix in the next 30 days that demonstrate you listened:

Common Quick Wins:
  → Fix the flaky CI pipeline that wastes 3 hours/week
  → Establish a regular 1:1 cadence (if previous manager didn't)
  → Create a team working agreement for meetings and async communication
  → Clear the backlog of stale PRs that nobody is reviewing
  → Set up proper on-call rotation with fair compensation
  → Get budget approved for a tool the team has been asking for

The goal isn't to transform the team in 30 days. It's to build credibility by showing you can listen and take action. Trust is earned through small, consistent follow-through.

The "Stop Coding" Decision

This is the hardest part for new managers. You need to stop being the person who writes the most code. Your job is now:

Time Allocation (target by day 60):
  1:1s and team meetings:     30%
  Cross-functional work:      20%
  Planning and prioritization: 20%
  Coaching and mentoring:     15%
  Technical context:          10%
  Admin:                       5%
  
Notice: Coding isn't on this list.

You can still review code, pair with engineers, and make technical decisions. But if you're the one writing features, you're not doing your actual job — and you're blocking someone else's growth by taking the interesting work.

Days 60-90: Build Systems, Not Heroes

By day 60, you've earned trust through quick wins and consistent 1:1s. Now build the systems that make the team self-sustaining:

The Career Growth Framework

If your team doesn't have clear career levels and expectations, create them:

Level Framework (Example):
  Junior Engineer:
    → Completes well-defined tasks independently
    → Writes clean, tested code
    → Asks for help when stuck (within 1 hour)

  Mid-Level Engineer:
    → Breaks down ambiguous problems into tasks
    → Owns features end-to-end (design → deploy → monitor)
    → Mentors junior engineers through code review

  Senior Engineer:
    → Leads technical design for complex projects
    → Identifies and addresses systemic problems
    → Influences team technical direction

  Staff Engineer:
    → Sets technical strategy across teams
    → Solves ambiguous, cross-cutting problems
    → Mentors senior engineers

The Decision-Making Framework

Define who makes what decisions so you're not a bottleneck:

Decision Types:
  Team decisions (sprint planning, technical approach):
    → Team decides, manager supports
  
  Architecture decisions (new patterns, major refactors):
    → Senior engineers propose, team reviews, manager approves

  People decisions (hiring, performance, promotions):
    → Manager decides with team input

  Strategic decisions (team direction, roadmap priorities):
    → Manager decides with leadership and product input

The Metrics That Matter

After 90 days, you should be tracking:

The first 90 days as an engineering manager set the trajectory for the next two years. Listen first, fix small things, then build systems. The teams that run themselves are the ones with managers who invested in structure and trust early — not the ones with managers who kept writing code and hoped leadership would happen on its own.