Three years ago, I got promoted to engineering manager. I’d been a strong senior engineer, I’d mentored junior developers, I’d led a complex migration project. I thought management would be a natural extension of what I was already doing. I was wrong about almost everything.
The first week, I tried to review every pull request my team submitted. By the second week, I’d missed two important meetings because I was debugging a production issue that wasn’t mine to debug anymore. By week three, one of my reports told me in a 1:1 that the team felt micromanaged. I hadn’t even realized I was doing it.
The IC-to-manager transition is the most written-about topic in engineering leadership, and yet every new manager I talk to makes the same mistakes. Not because the advice isn’t out there, but because knowing what to do and doing it are separated by an enormous gap that only closes with deliberate practice. This is what I wish someone had told me before day one—and the framework I now give to every new manager I mentor.
The Identity Crisis Nobody Warns You About
As an IC, your identity is built on technical competence. You know how to solve hard problems. You can hold complex systems in your head. You ship features. Your value is tangible and immediate—you can point to code in production and say “I built that.”
As a manager, none of those things are your job anymore. Your job is to make other people effective at doing those things. The output you’re optimizing for is team throughput, not personal throughput. And team throughput is maddeningly hard to measure, embarrassingly slow to improve, and impossible to point to in a demo.
This identity shift is genuinely disorienting. For the first few months, I felt like I wasn’t accomplishing anything. My calendar was full of meetings. I wasn’t writing code. My TODO list was full of ambiguous items like “think about team structure” and “follow up on hiring pipeline.” At the end of each day, I couldn’t articulate what I’d produced.
Here’s what I eventually understood: management work is mostly invisible, and that’s fine. The 30-minute conversation where you helped a report think through an architecture decision doesn’t show up in any dashboard. The email you sent to unblock a cross-team dependency saved two days of work, but nobody will attribute those two days to you. The difficult conversation you had with an underperformer will take months to show results. You have to be okay with this.
The First 30 Days: Listen, Learn, Don’t Change Anything
Your first month is for observation. I cannot stress this enough. The number one mistake new managers make is walking in with a plan to “fix things.” Even if things are genuinely broken, you don’t have enough context yet to fix them correctly, and attempting to do so will burn trust with your team before you’ve built any.
Week 1-2: The Listening Tour
Schedule a 1:1 with every person on your team. Not the recurring 1:1s you’ll set up later—a specific introductory conversation. I use these questions:
- What’s working well on this team that I should be careful not to break?
- What’s the biggest thing slowing you down right now?
- How do you prefer to receive feedback?
- What does a great week look like for you?
- Is there anything you’ve wanted to change but haven’t had the support to do?
Take notes. Look for patterns. If three people independently mention that deployments are painful, that’s probably your first real problem to solve. If one person has a complaint nobody else shares, that’s important context too—but it’s not a systemic issue.
Also talk to your peers—the other managers you’ll be working with. Talk to your own manager. Talk to the PM and designer on your team. Everyone has a different perspective on what’s working and what isn’t. Your job in month one is to assemble a complete picture from these partial views.
Week 2-4: Map the System
I don’t mean the technical system (though you should understand that too). I mean the human system. Figure out:
- Who are the informal leaders? Every team has someone who isn’t a tech lead but whom everyone goes to for advice. Identify them. They’re your most important allies.
- Where are the trust relationships? Who works well together? Who has friction? You’ll need this map when you assign work and when conflicts arise.
- What are the unwritten rules? Maybe the team always does code review within 4 hours. Maybe there’s an unspoken agreement that nobody deploys on Fridays. These norms are load-bearing—violating them by accident will undermine your credibility.
- What’s the team’s relationship with other teams? Dependencies, shared services, historical tensions. You’re going to be managing these relationships, and you can’t manage what you don’t understand.
The First 60 Days: Build the Foundation
By day 30, you should have a decent mental model of the team, the work, and the organizational context. Now you can start building the management infrastructure that will carry you through the next year.
Set Up Your 1:1s Properly
1:1s are the single most important tool in your management toolkit. Get them right and everything else gets easier. Get them wrong and you’ll spend months wondering why your team seems disengaged.
Frequency: weekly, 30 minutes minimum. I’ve heard managers argue for biweekly 1:1s. In my experience, biweekly is too infrequent for the first six months in a new management role. You need the reps to build the relationship. Once trust is established, some reports may prefer biweekly, and that’s fine—but start weekly.
The most important 1:1 rule: this is their meeting, not yours. Status updates go in standup or Slack. The 1:1 is for coaching, career development, feedback, and whatever is on their mind. If you’re spending 1:1 time asking “what are you working on?” you’re wasting the meeting.
I use a shared document for each report. They own the agenda. I add items too, but theirs come first. A typical 1:1 doc looks like this:
- Their items (5-15 min): Whatever they want to discuss. Blockers, questions, ideas, frustrations, career thoughts.
- My items (5-10 min): Feedback on recent work, organizational updates that affect them, questions I have.
- Career/growth (5-10 min, not every week): Longer-term development goals, upcoming opportunities, skills they want to build.
The temptation will be strong to skip 1:1s when things are busy. Don’t. Canceling 1:1s sends a clear message: “You’re not a priority right now.” Even if that’s not what you mean, that’s what they hear. If you genuinely can’t make the time, reschedule rather than cancel.
Establish Team Health Metrics
You need some way to know if the team is getting better or worse over time. Gut feeling isn’t reliable, especially when you’re new. Here are the metrics I track:
Delivery metrics (leading indicators):
- Cycle time: How long from first commit to production? Track the median and the 90th percentile. The p90 tells you about your worst cases, which often reveal process bottlenecks.
- PR review turnaround: How long do PRs sit waiting for review? If this is consistently over 24 hours, your team is context-switching too much or doesn’t have enough shared knowledge to review each other’s work.
- Deploy frequency: How often does the team ship? A team that deploys daily has a fundamentally different risk profile than one that deploys weekly. Neither is inherently better, but changes in frequency signal changes in confidence or process health.
People metrics (lagging but critical):
- 1:1 sentiment: I keep a simple log after each 1:1—was the person energized, neutral, or frustrated? Trends matter more than individual data points. Three frustrated 1:1s in a row is a signal.
- Voluntary attrition risk: Who’s at risk of leaving? This is a judgment call informed by your 1:1s, but you should have an explicit answer for each person, updated monthly.
- Team survey results: If your company does engagement surveys, pay attention to your team’s specific results. If not, consider running a quarterly anonymous team health check using something like Spotify’s Squad Health Check model.
Don’t use these metrics to evaluate individuals. Use them to evaluate your systems and processes. If cycle time is high, the question isn’t “who’s slow?”—it’s “what’s in the way?”
Learn Stakeholder Management
This is the part of management that nobody teaches in engineering school, and it’s arguably the skill that determines whether you succeed or fail. Your stakeholders include your own manager, the PM on your team, peer managers, and senior leadership.
A few principles I’ve learned the hard way:
Manage up aggressively. Your manager can’t help you if they don’t know what’s going on. Send a weekly summary—two paragraphs max—covering what shipped, what’s at risk, and what you need from them. I’ve never had a manager complain about being over-informed. I’ve had several complain about being surprised.
Build peer relationships before you need them. The time to build a relationship with the platform team’s manager is not when you need them to prioritize your request. Have coffee. Learn what their team is working on. Offer help. When you eventually need a favor, the conversation will be entirely different.
Translate between technical and business language. This is your superpower as a former IC. Your PM says “we need to improve page load time.” Your team says “the API response includes 40 unnecessary database joins.” Your job is to connect these: “If we spend two weeks refactoring the user profile query, we’ll reduce page load time by 60%, which directly impacts the conversion metric the PM cares about.” Neither your PM nor your team can make this connection as naturally as you can.
The First 90 Days: Start Driving Change
By day 60, you have relationships, context, and infrastructure. Now you can start making deliberate changes. But be selective. A common pattern I see in new managers is trying to fix everything at once. Pick one or two high-impact problems and focus on those.
Identify Your First Win
Your first win should be something that:
- The team has already identified as a problem (from your listening tour)
- Can be resolved within 2-4 weeks
- Has visible impact on the team’s daily experience
- Doesn’t require political capital you haven’t built yet
Common first wins: fixing a flaky CI pipeline, removing an unnecessary approval process, getting budget for a tool the team has been wanting, resolving a long-standing cross-team dependency. These aren’t glamorous, but they demonstrate that you listen and you act—which is exactly the reputation you want to build early on.
Have the Difficult Conversations
By day 60-90, you probably know who on your team is underperforming. Maybe it was obvious from day one. Maybe it became clear as you watched the team work. Either way, you need to address it.
New managers tend to defer performance conversations because they’re uncomfortable. I get it. Telling someone their work isn’t meeting expectations feels terrible. But delaying the conversation is worse—for you, for them, and for the rest of the team.
The team already knows who’s underperforming. They’re watching to see what you do about it. If you do nothing, you’re sending a message that the standard is wherever the lowest performer sets it. High performers notice this, and they start updating their resumes.
When you do have the conversation, be specific and direct. Not “your code quality needs improvement” but “in the last three PRs, I noticed repeated issues with error handling—specifically, in PR #1234, the database timeout case wasn’t handled, and in PR #1289, the retry logic didn’t include backoff. I’d like us to work on a plan to address this.” Specific observations, specific examples, clear expectation of what needs to change.
When to Write Code (and When to Stop)
This is the question every IC-turned-manager obsesses over. The answer is nuanced and changes over time.
In your first 30 days: Write a little code. Not to be productive, but to understand the codebase, the development workflow, and the pain points your team deals with daily. Do the new developer onboarding. Set up the project locally. Fix a small bug. This gives you technical context that will make you a better manager.
From day 30-90: Reduce your coding significantly. You can still review PRs (and you should, at least occasionally, to stay technically connected). But you shouldn’t be on the critical path for any deliverable. If the team can’t ship because you haven’t finished your piece, you’re doing it wrong.
After day 90: Your coding should be purely optional. Prototype something during a hackathon. Fix a bug that’s been annoying you. Write a small internal tool. But these are side projects, not commitments. The moment a coding task conflicts with a management responsibility, the management responsibility wins. Always.
The red flags that you’re coding too much:
- You’re in the critical path for a sprint deliverable
- You’re reviewing PRs instead of someone on the team doing it
- You’re skipping or rushing 1:1s to get back to code
- Your reports are blocked waiting for decisions from you because you were heads-down coding
- You’re writing code because it feels productive, not because it’s the best use of your time
That last one is the killer. Management work is ambiguous. Code is concrete. When you’re feeling overwhelmed by the ambiguity of management, the pull to open your IDE is strong. It’s a coping mechanism disguised as productivity. Recognize it for what it is.
Common First-Year Mistakes
Beyond the ones I’ve already mentioned, here are the mistakes I see most frequently in new engineering managers:
Being everyone’s friend. You can be friendly. You can care about your reports as people. But you’re not their peer anymore. You have authority over their compensation, their career growth, and in the worst case, their employment. Pretending that dynamic doesn’t exist helps no one. Be warm, be approachable, be human—but maintain the professional boundary that lets you give honest feedback and make hard calls.
Shielding the team from everything. New managers often take “protect the team” too far. They absorb every organizational communication, filter out anything stressful, and present a sanitized view of reality. The problem is that your team isn’t stupid. They can sense when things are being hidden, and the speculation that fills the information vacuum is usually worse than the truth. Share context generously. Trust your team to handle ambiguity. Shield them from distractions, not from information.
Solving problems instead of coaching. When a report comes to you with a technical problem, your instinct as a former IC is to solve it. Resist. Instead, ask questions: “What have you tried?” “What are the tradeoffs between approach A and B?” “What would you need to know to make this decision yourself?” Your goal is to build their problem-solving ability, not to be the team’s oracle. If you solve every problem, you become a bottleneck and your team stops growing.
Ignoring the org chart. You might think organizational politics are beneath you. They’re not. Understanding how decisions get made, who influences whom, and where budgets come from is part of your job. You don’t have to be political—you just have to be informed. The manager who understands the organizational context gets resources for their team. The one who doesn’t wonders why their requests keep getting denied.
Neglecting your own growth. You spent years developing as an engineer. You took courses, read books, practiced new technologies. Now apply the same discipline to management. Read “The Manager’s Path” by Camille Fournier. Read “An Elegant Puzzle” by Will Larson. Join a manager peer group where you can discuss challenges with people who understand them. Management is a skill, and like any skill, it responds to deliberate practice.
Building Your Management System
By the end of 90 days, you should have a personal operating system that includes:
A weekly rhythm: Monday review of the week’s priorities. Tuesday-Thursday for meetings, 1:1s, and deep work. Friday for reflection, writing your weekly summary, and planning the next week. The specific schedule matters less than having one and sticking to it.
An information system: Where do you capture notes from 1:1s? How do you track action items? How do you remember that you promised to follow up with someone next week? I use a combination of a shared Google Doc per report for 1:1 notes, a personal Notion page for tracking team health and action items, and calendar reminders for follow-ups. The tool doesn’t matter. Having a system does.
A feedback practice: Give feedback within 48 hours of the event. Positive feedback in public (if the person is comfortable with that), constructive feedback in private, always. Start a feedback log where you note positive and constructive observations as they happen—you’ll thank yourself during performance review season.
A decision framework: Not every decision needs your input. Explicitly categorize decisions into three buckets: (1) the team decides autonomously and informs you, (2) the team proposes and you approve, (3) you decide with team input. Make these categories clear to your team. Err on the side of pushing decisions to bucket 1.
What Success Looks Like
At the end of your first 90 days, you won’t have transformed the team. That’s not the goal. The goal is to have built the foundation for long-term effectiveness. Here’s what good looks like:
- Every person on your team trusts you enough to tell you when something is wrong
- You have regular 1:1s running and they feel valuable (ask your reports if they do)
- You understand the team’s technical work well enough to have informed opinions, even if you’re not writing the code
- Your manager knows what’s going on without having to ask
- You’ve delivered at least one tangible improvement the team cares about
- You’ve started addressing performance issues rather than ignoring them
- You have a personal system that prevents things from falling through the cracks
If you can check most of these boxes at day 90, you’re ahead of schedule. The first year of management is a marathon of learning, and the first 90 days are just the start. You’ll make mistakes. You’ll have weeks where you feel completely out of your depth. That’s normal. The managers who succeed aren’t the ones who get everything right—they’re the ones who stay self-aware, keep learning, and don’t retreat to their IDE when things get hard.
The transition from IC to manager is, in many ways, starting a new career while sitting at the same desk. Give yourself permission to be a beginner. The skills you built as an engineer—systematic thinking, debugging complex problems, learning quickly—transfer more than you think. You just need to aim them at different problems now.