The Engineering Manager's First 90 Days

I became an engineering manager for the first time in 2014. I was the best engineer on the team. I was the worst manager on the floor.

Those first 90 days were brutal. I made every classic mistake: rewrote code in PRs instead of coaching, scheduled too many meetings, tried to stay technical while ignoring people problems, and avoided hard conversations until they became crises.

I've since coached 11 new engineering managers through their transitions. Every one of them was about to make the same mistakes I did. Here's the playbook I give them.

# The Contrarian Take: Your Technical Skills Are Now Your Weakness

The thing that got you promoted, your technical ability, is now your biggest liability. Not because it stopped mattering. Because it will tempt you into doing the wrong job.

Every hour you spend writing code is an hour you're not spending on the things only you can do: clearing blockers, improving processes, growing your team members, and making sure the team is building the right things.

I'm not saying you should never touch code. I'm saying your default should shift from "I'll build it" to "I'll make sure the team can build it." That shift takes about 90 days to internalize, and it's the hardest part of the transition.

# Days 1-30: Listen and Map

Your only job for the first month is to understand the current state. Don't change anything yet. You don't have enough context, and changes made without context create more problems than they solve.

# Week 1: Meet Everyone

Schedule 45-minute 1:1s with every person on your team. Not 30 minutes. That's too short. You're going to ask deep questions, and people need time to warm up.

My first-1:1 question list:

1. What's the best thing about working on this team?
2. What's the most frustrating thing?
3. What should I know that nobody will tell me unless I ask?
4. If you could change one thing about how the team works, what would it be?
5. What do you need from your manager that you're not getting?
6. What are you working toward in your career over the next 2-3 years?

Write down every answer. Look for patterns. If three out of six people mention the same frustration, that's your first problem to solve.

# Weeks 2-3: Map the System

You need to understand three systems:

The technical system. What's the architecture? Where's the tech debt? What breaks most often? What's the deployment process? Don't just read docs. Sit with engineers while they deploy. Watch what actually happens.

The people system. Who's thriving? Who's struggling? Who has influence beyond their title? Who's thinking about leaving? You won't know all of this by week 3, but you should have hypotheses.

The process system. How does work get planned? How are priorities set? Where do handoffs happen? What ceremonies exist and which ones do people actually find valuable?

# Week 4: Synthesize and Share

Write a one-page document: "What I've Learned in My First Month." Share it with your team and your manager. Include:

• Three things that are working well (start positive)
• Three things that could improve (based on patterns, not individual complaints)
• Three questions you still can't answer

This document does two things. It shows your team you listened. And it creates accountability for the changes you'll make next.

# Days 31-60: Fix the Foundations

Now you have context. Time to act. But pick your battles carefully. You can't fix everything at once, and trying to will overwhelm the team.

# Pick Two Things

From your synthesis, pick the two most impactful improvements. Here's how I prioritize:

1. Is anyone in danger of quitting? If yes, fix whatever's pushing them out. Retention is your highest-ROI activity.
2. Is there a process that everyone hates? Kill it or fix it. Quick wins build trust.
3. Is the team shipping reliably? If not, fix the deployment pipeline, the planning process, or whatever's causing delays.

Don't pick more than two. Your team is adjusting to a new manager. Too much change creates anxiety.

# Establish Your Operating Rhythm

By day 45, you should have your management rhythm locked in:

• Weekly 1:1s: 30 minutes each. I use a shared document where both parties add topics before the meeting. The direct report's topics come first.
• Weekly team sync: 45 minutes. Status updates go async. The sync is for decisions, blockers, and coordination.
• Biweekly skip-level: If you manage managers, talk to their reports regularly. Not to undermine your managers. To calibrate your understanding.
• Monthly retrospective: What went well? What didn't? What should we change? Format doesn't matter. Consistency does.

# Start Giving Feedback

This is where most new managers choke. They store up feedback for weeks and then dump it all in a performance review. That's terrible.

My rule: feedback within 48 hours or don't bother. If you saw something good, say so today. If you saw something that needs to improve, say so today. Keep it short and specific.

The SBI model works:

• Situation: "In yesterday's design review..."
• Behavior: "...you interrupted Maria three times while she was presenting her approach."
• Impact: "It made it harder for the team to hear her ideas, and she told me afterward she felt dismissed."

No judgment. No character assessment. Just situation, behavior, impact. Let the person connect the dots.

# Days 61-90: Build for the Future

You've listened. You've fixed the urgent stuff. Now it's time to think beyond firefighting.

# Create Development Plans

Every engineer on your team should know: where they are, where they're going, and what they need to do to get there. If your company has an engineering ladder, use it. If it doesn't, build a simple one.

For each person, define:

• Current level and key strengths
• Target level and timeline (usually 12-18 months)
• Two to three specific skills or behaviors to develop
• Concrete opportunities to practice those skills (projects, presentations, mentoring)

# Set Team Goals

Your team needs to know what success looks like for the next quarter. I use OKRs, but the format doesn't matter. What matters is:

• The team helped create the goals (not just received them)
• Goals are measurable
• There aren't too many (3-4 objectives max)
• Progress is visible and reviewed weekly

# Build Your Peer Network

The loneliest moment in engineering management is realizing you can't vent to your team anymore. You need peers.

Find 2-3 other engineering managers, inside or outside your company. Meet regularly. Share problems. Ask for advice. This network will save you more than any management book.

# The Stealable Framework: The 30-30-30 Playbook

Days 1-30: Listen. Meet everyone. Map the systems. Synthesize findings. Change nothing.

Days 31-60: Fix. Pick two high-impact improvements. Establish your operating rhythm. Start giving real-time feedback.

Days 61-90: Build. Create development plans. Set team goals. Build your peer network.

# The Mistakes I Still See

Mistake: Trying to stay an IC. You'll be tempted to pick up coding tasks when the team is behind. Don't. Every task you take is a missed opportunity for someone else to grow, and it signals that you don't trust your team.

Mistake: Avoiding conflict. Two engineers disagree on an architecture decision. You let them "work it out." Three weeks later, nothing's decided and both are frustrated. Your job is to facilitate the decision, not avoid it.

Mistake: Optimizing for being liked. You will make unpopular decisions. An engineer who's underperforming needs direct feedback. A project needs to be cut. A process needs to change. If you optimize for being liked, you'll avoid these decisions, and your team will suffer.

The best engineering managers I've worked with weren't the most technically brilliant. They were the ones who built environments where brilliant engineers could do their best work. That's the job. Start learning it in day one.