The first thing I want to tell you is that the discomfort you are feeling is not a warning sign. It is the job working correctly.
When you step into an engineering leadership role for the first time, almost everything that made you good at your previous job stops being directly useful. The skills that got you promoted - the ability to reason through a hard problem, write clean code, ship features reliably - those are no longer your primary tools. Your primary tool is now other people. And working with people is a fundamentally different craft from working with code.
That transition is jarring for most engineers, and it catches a lot of first-time managers completely off guard. Not because they are not capable, but because nobody told them what to actually expect.
So let's talk about what to actually expect.
What Just Changed (And What Didn't)
Here is the uncomfortable truth about moving into engineering management: your output is no longer measurable in the same way. When you were an IC, you could point to pull requests, shipped features, performance improvements, and bug fixes. There was a feedback loop. You could tell, more or less, whether you were doing well.
As a manager, your output is the team's output. That is a much longer feedback loop, and it is far less legible. Did that one-on-one conversation you had three weeks ago lead to someone shipping better work today? Did the process change you introduced last month reduce friction on the team? You often will not know for weeks or months, and sometimes you will never know for certain.
This drives a lot of new engineering managers straight back to coding. Not because they need to - they just miss the feedback loop. They miss feeling productive in a way they can measure.
I am not going to tell you to never write code again. That is both unrealistic and unnecessary. But I will tell you that if you are writing code to avoid the uncomfortable parts of your new job, you are solving the wrong problem. The goal is to get comfortable with the longer feedback loop, not to escape it.
What did not change: you still need to understand the technical work deeply. Not at a "I could have written that PR myself" level necessarily, but at a "I can have a real conversation about this tradeoff and push back when something feels wrong" level. Technical credibility matters enormously in engineering leadership. You earn it by staying engaged with the work, asking good questions in code review, understanding the architecture, and remembering what it actually feels like to ship something under pressure.
The shift is not from technical to non-technical. It is from doing the technical work to enabling others to do it better than you could alone.
Letting Go of the Keyboard
This is the hardest part for most engineers, so let's spend some real time here.
You are probably good at coding. Maybe very good. You have built up years of intuition about how to structure a problem, where the edge cases are, what a clean solution looks like. And now you are sitting in meetings watching your team write code that you could see the issues in immediately, and you have to... not fix it yourself.
That feeling does not go away quickly. But here is a reframe that helped me when I was working through this with engineers making the management transition: your job is no longer to write the best code. Your job is to build a team that writes better code than you ever could alone.
That reframe changes the question from "why am I not fixing this?" to "how do I help this person grow into someone who catches this themselves?" Those are very different questions, and they lead to very different actions.
Concretely, letting go of the keyboard looks like this:
Reviewing instead of rewriting. When you see a PR that you would have written differently, write a thoughtful review comment explaining your reasoning instead of just fixing it yourself. This is slower in the short term and faster in the long term. The engineer learns something, and next time they will write it better without needing your input.
Asking questions instead of giving answers. When an engineer comes to you with a problem, resist the instinct to solve it. Ask questions instead. "What have you already tried? What do you think is causing it? What would you do if you had to take a guess?" This feels slower and sometimes frustrating (for both of you) but it builds problem-solving independence. Engineers who get answers handed to them stay dependent. Engineers who are coached through problems become more capable.
Delegating things that make you nervous. The tasks you are most reluctant to hand off are usually the tasks you most need to hand off. That is often because they are high-visibility or technically complex, and you do not fully trust someone else to handle them yet. That distrust is sometimes justified, but often it is just anxiety. Start with lower-stakes delegation and build up. Give people room to own something end-to-end, and resist the urge to hover.
Managing Your Time as a New Leader
Your calendar is about to become your main work surface. That is a real adjustment.
As an IC, your calendar was mostly something that interrupted your work. Meetings were overhead. Focus time was the actual job. As a manager, your calendar is the actual job. One-on-ones, team syncs, cross-team coordination, recruiting conversations, performance check-ins - these are not the things getting in the way of your work. They are your work.
That said, there are a few time management habits that separate effective new managers from ones who burn out quickly.
Protect one or two focus blocks per week. Even as a manager, you need uninterrupted time to think. Not to write code, but to read documents carefully, think through an organizational problem, draft a strategy, or just catch up on what is actually happening in the codebase. If you let your entire week become back-to-back meetings, you will always be reacting and never thinking ahead.
Time-box your one-on-ones and run them consistently. One-on-ones are your single most important management tool, and new managers often either skip them when things get busy or run them without a clear purpose. Do not do either. Hold them every week, keep them to thirty or forty-five minutes, and treat them as the engineer's time - not your status update meeting. Come with a light agenda, ask real questions, and actually listen. "How is everything going" is not a real question. "What is the most frustrating part of your work right now" is a real question.
Batch your administrative overhead. Expense reports, tool approvals, interview scheduling, performance review paperwork - this stuff has to get done but it does not require your best brain hours. Block thirty minutes at the end of a Tuesday for admin. Do not let it colonize your mornings.
Learn to say no to your own instincts. You will constantly want to jump in, add yourself to things, take on tasks you see falling through cracks. Some of that instinct is good leadership. A lot of it is just difficulty letting go of the doing. Before you take something on, ask: is this actually mine to handle, or am I adding myself here because it feels more comfortable than delegating?
The Expectation Gap
Here is something that does not get talked about enough in the IC-to-manager transition: the expectations of the people around you shift before you have had time to develop new competencies.
Your team expects you to have answers about career growth, organizational direction, and team priorities. Your manager expects you to surface problems early, have a handle on your team's capacity, and represent your team in cross-functional conversations. Your peers across other teams expect you to be reliable and aligned.
And you are three weeks in, still figuring out what one-on-ones are supposed to accomplish.
The gap between those expectations and your current capabilities is real, and trying to close it by pretending you have everything figured out is a trap. The better approach is direct acknowledgment. "I am still finding my footing on this" is a perfectly acceptable thing to say in your first ninety days. It signals self-awareness and honesty, which are actually two of the more important traits in a new manager.
What you should not do is fake competence in areas where you are genuinely unsure, because that creates expectations you will then have to maintain. Better to set honest expectations early and then exceed them than to promise things you cannot deliver.
The areas where most new engineering managers genuinely struggle in the first six months:
Performance conversations. Giving critical feedback to someone whose work is not meeting expectations is one of the hardest things managers have to do, and most ICs have almost no experience with it. The instinct is to soften, delay, or avoid. Push against that instinct. Clear, specific, compassionate feedback delivered early prevents the much harder conversation later.
Prioritization and saying no. As an IC, someone else decided what was on the roadmap. Now you are involved in those decisions, and you have to be willing to push back when the team is being asked to do too much. That requires a different kind of conversation than most engineers have had to have before.
Navigating organizational ambiguity. Companies are messier from the inside than they look from a distance. There are competing priorities, unclear ownership, processes that exist for reasons nobody remembers, and political dynamics that take time to understand. Your job is to make sense of enough of that context to give your team clarity, even when you do not have full clarity yourself.
Skills to Start Building Right Now
If you are a new engineering manager reading this, here are the things I would focus on in your first ninety days:
Get really good at listening. Not just hearing - actually listening. When an engineer tells you something in a one-on-one, are you thinking about your response while they are talking, or are you actually taking in what they are saying? Active listening is a learnable skill and it is foundational to everything else in this job.
Start a manager journal. Write down what you tried, what happened, and what you would do differently. Management has a long feedback loop, which means you need to be deliberate about capturing the signal. A weekly reflection of ten minutes is enough. Over six months it becomes an invaluable record of your own development.
Find a peer group or mentor. The transition into management is isolating in a specific way: the problems you are dealing with are not something you can fully discuss with your direct reports, and they are different from the technical problems your IC friends are working on. Finding other people at a similar stage - through communities, networks, or formal mentoring - gives you a sounding board that is genuinely hard to replace. Some of the most useful conversations I have had with engineers making the management transition were not about tactics at all. They were just about realizing that the disorientation they were feeling was normal.
Learn the business context. As an IC, you needed to understand the technical context of your work. As a manager, you need to understand the business context too. Why does your company prioritize certain things? How does your team's work connect to revenue, users, or strategic goals? The better you understand that, the better equipped you are to make good prioritization decisions and advocate for your team effectively.
Be patient with yourself. This is easier to say than to live, but it is true. Most engineers who become managers underestimate how long the real learning curve is. You will make mistakes in your first year. Some of them will be painful. That is not a sign that you made the wrong choice. It is a sign that you are actually doing the job.
The Part Nobody Tells You
There is something genuinely satisfying about watching someone you have been working with closely ship something significant, get promoted, or work through a hard problem they could not have solved six months ago. It is a different kind of satisfaction from shipping something yourself - less immediate, more durable.
You will not feel it right away. In the first few months, it mostly just feels hard. But it shows up eventually, and when it does, it tends to make the tradeoffs feel worth it.
The move from IC to manager is one of the more significant professional transitions you will make. It is not for everyone, and there is no shame in deciding the role is not the right fit. But if you go in with clear eyes about what is actually changing, build the right habits early, and resist the pull of the familiar, you have a real shot at being genuinely good at it.
Start there.
Next up in this series: Hiring Engineers - a practical playbook for interview structure, technical assessment, and building an onboarding process that actually works.
Top comments (0)