Leadership for New Managers
You just got promoted. Now what? The skills that made you a great individual contributor won't make you a great manager. Here's what actually works.
Maya's first week as a manager was a disaster
Maya was the best software engineer on her team. She shipped features fast, wrote clean code, and always hit deadlines. So when her manager left, leadership promoted Maya.
Monday: she rewrote a junior developer's pull request instead of reviewing it. Tuesday: she scheduled a team meeting to announce three process changes nobody asked for. Wednesday: a teammate — her friend for two years — asked for time off, and Maya panicked because she didn't know if she could approve it. Thursday: she stayed until 9pm doing her old IC work plus responding to Slack messages from her team. Friday: her best engineer asked to transfer to another team.
Five days. Five mistakes. And every single one of them is something new managers do because they don't understand one critical truth:
The job that got you promoted is not the job you were promoted into.
Being a great individual contributor means producing excellent work yourself. Being a great manager means producing excellent work through other people. That's not a small shift — it's a completely different skill set.
The IC-to-manager transition: what actually changes
✗ Without AI
- ✗Your output is your work product
- ✗Success = what you deliver personally
- ✗You solve problems directly
- ✗You manage your own time
- ✗Feedback comes from your manager
- ✗Your skills are technical/functional
✓ With AI
- ✓Your output is your team's work product
- ✓Success = what your team delivers collectively
- ✓You create conditions for others to solve problems
- ✓You manage other people's time and priorities
- ✓Feedback goes in every direction
- ✓Your skills are people and systems
This is the transition most people get wrong. You were promoted because you were great at Job A. Now you're doing Job B, and nobody trained you for it. The instinct to jump in and do the work yourself — like Maya rewriting that pull request — feels productive. It's actually the worst thing you can do, because it teaches your team that their work will get overridden and there's no point trying.
The 5 biggest mistakes new managers make
<strong>1. Doing the work themselves.</strong> You see a task done poorly and fix it yourself. Your team learns helplessness. Delegation atrophies. You burn out.
<strong>2. Making changes too fast.</strong> New managers feel pressure to prove themselves. They restructure processes in week one. The team feels bulldozed. Trust evaporates before it forms.
<strong>3. Avoiding hard conversations.</strong> You don't want to be "that boss." So you let performance issues slide. Six months later, you have a culture problem.
<strong>4. Treating everyone the same.</strong> Some people need autonomy. Some need structure. Some need encouragement. Managing everyone identically means managing nobody well.
<strong>5. Neglecting upward management.</strong> Your relationship with your own boss matters enormously. If they don't know what your team is doing or what you need, you won't get resources, air cover, or support.
There Are No Dumb Questions
"I got promoted over people who have more experience than me. How do I manage people who might resent me?"
Acknowledge it directly. Say something like: "I know this might feel awkward. I'm not here because I think I'm better than you — I'm here because this is the role the company needs me in. I need your expertise and I'm going to lean on it." Humility and directness disarm resentment faster than pretending the dynamic doesn't exist.
"Should I completely stop doing technical/hands-on work?"
Not necessarily — especially in small teams. But your hands-on work should be the exception, not the default. A useful rule: if someone on your team could do this task (even if slower), delegate it. Reserve your hands-on time for true emergencies and areas where you're genuinely the only option.
1:1 meetings: the most important hour of your week
The single highest-leverage activity for any manager is the regular 1:1 meeting with each direct report. Done well, a 30-minute weekly 1:1 prevents problems, builds trust, and accelerates development. Done poorly — or skipped — problems fester in silence.
How to run an effective 1:1:
| Element | What it looks like | Common mistake |
|---|---|---|
| Frequency | Weekly, 30 min, same time | Cancelling when busy (signals "you're not a priority") |
| Ownership | Their meeting, their agenda | Manager talks the whole time |
| Opening | "What's on your mind?" | Jumping straight into status updates |
| Content | Challenges, growth, blockers, feelings | Treating it as a project check-in |
| Notes | Brief shared doc both can reference | No notes (things get forgotten) |
| Follow-up | Action items tracked and revisited | Promises made, never kept |
The 1:1 is not a status meeting. You have standups, Slack, and project tools for that. The 1:1 is where you learn what your team member is struggling with, what they want to grow into, and what's going wrong before it becomes a crisis.
Three questions that unlock real conversation:
- "What's the hardest part of your work right now?"
- "Is there anything I'm doing — or not doing — that's making your job harder?"
- "What do you want to be doing in a year that you're not doing now?"
Design Your 1:1 Template
25 XPGiving feedback: the SBI framework
Most new managers either avoid feedback entirely or deliver it so bluntly it damages the relationship. The SBI framework — Situation, Behavior, Impact — gives you a structure that's specific, non-judgmental, and actionable.
| Step | What you say | Example |
|---|---|---|
| Situation | When and where it happened | "In yesterday's client meeting..." |
| Behavior | What the person did (observable, factual) | "...you interrupted the client twice while they were explaining their requirements..." |
| Impact | The effect it had | "...and they seemed to shut down. We left the meeting without the information we needed." |
Then ask: "What's your perspective on this?" — because you might be missing context.
What makes SBI work is that it separates the person from the behavior. You're not saying "you're rude." You're saying "this specific thing happened and here's the result." That's something people can hear, process, and act on.
Delegation: what, when, and how
Delegation is not dumping tasks you don't want to do. It's a deliberate act of developing your team by giving them ownership of meaningful work.
The delegation decision matrix:
| Delegate | Don't delegate |
|---|---|
| Tasks someone on your team can learn from | Tasks requiring your specific authority (hiring, firing, compensation) |
| Work that develops a skill they need | Highly confidential matters (sensitive HR issues) |
| Recurring work you've been doing out of habit | Crisis situations where speed is critical and stakes are existential |
| Anything where "good enough" from them beats "perfect" from you, late | Work that requires relationships only you have (for now) |
How to delegate effectively:
- Define the outcome, not the process. "I need the quarterly report by Friday with these three sections" — not "Open the spreadsheet, click on cell B2..."
- Match the task to the person's growth edge. Too easy = boring. Too hard = paralyzing. Aim for slightly uncomfortable.
- Agree on check-in points. Don't disappear until the deadline. Don't hover over their shoulder. Set one or two midpoint check-ins.
- Accept a different approach. They won't do it the way you would. If the outcome is right, the method doesn't matter.
- Debrief afterward. "What went well? What would you do differently?" This closes the learning loop.
There Are No Dumb Questions
"What if they do the work and it's not good enough?"
That's expected, especially the first time. Your job is coaching, not rescue. Ask them what they'd change, point them to examples, and let them try again. Redoing their work yourself is a short-term fix that creates a long-term dependency.
"How do I delegate when I can do the task in half the time?"
Because the third time they do it, they'll be as fast as you. And then you'll have two people who can do it instead of one. Delegation is an investment — it costs time now and pays back permanently.
Delegation Scenario
25 XPBuilding trust: the foundation of everything
None of the above works without trust. Your team won't bring you problems, accept feedback, or take on stretch assignments if they don't trust you. Trust is built slowly through consistent behavior:
The trust equation (from The Trusted Advisor by Maister, Green, & Galford):
Trust = (Credibility + Reliability + Intimacy) / Self-Orientation
- Credibility: Do you know what you're talking about?
- Reliability: Do you do what you say you'll do?
- Intimacy: Do people feel safe sharing concerns with you?
- Self-Orientation (the denominator): Are you in it for yourself or for them? High self-orientation kills trust faster than anything else.
Practical trust-building actions:
- Follow through on every promise, no matter how small
- Admit when you don't know something
- Share context and reasoning behind decisions, not just the decision
- Give credit publicly, take blame privately
- Be consistent — no mood swings, no favoritism
Managing former peers
This is one of the hardest transitions in management: yesterday you were equals; today you're the boss. Three rules:
1. Address it openly. "Our relationship is changing and I want to be straightforward about it. I'm not going to pretend to be something I'm not, and I still value your input — but I also have responsibilities now that might mean I make decisions you disagree with."
2. Reset social boundaries gradually. You don't have to stop being friends. But you do have to stop venting about the company, gossiping about colleagues, and sharing information asymmetrically. The team will watch who you eat lunch with and read favoritism into everything. Be aware.
3. Hold everyone to the same standard. The moment you give a former friend preferential treatment — lighter workload, better projects, more flexibility — you lose the rest of the team. And the moment you're harder on a friend to overcompensate, you lose them.
The first 90 days: a framework
| Phase | Days | Focus | Key actions |
|---|---|---|---|
| Listen | 1-30 | Understand | 1:1s with every team member. Ask: "What's working? What's broken? What would you change?" Learn the systems, the history, the politics. Make zero process changes. |
| Diagnose | 31-60 | Identify patterns | What did you hear repeatedly? Where are the real bottlenecks? What does the team need that they're not getting? Start forming your hypothesis. |
| Act | 61-90 | Make targeted changes | Pick 1-2 high-impact improvements. Communicate clearly why you're making them and what you expect. Quick wins build credibility. |
The biggest mistake in the first 90 days is acting in the first 30. You don't understand the system yet. Changes made without understanding create more problems than they solve and signal to the team that you care more about looking decisive than being effective.
Your 90-Day Plan
50 XPRecommended reading
Five books that will make you a better manager, in order of priority:
| Book | Author | Why read it |
|---|---|---|
| High Output Management | Andy Grove | The foundational text. Written by Intel's CEO — teaches you to think about management as a system of outputs and leverage. Short, dense, practical. |
| The Manager's Path | Camille Fournier | Especially relevant for tech managers. Maps the entire journey from IC to CTO with advice for each stage. |
| Radical Candor | Kim Scott | How to give feedback that's simultaneously honest and empathetic. The "Care Personally + Challenge Directly" framework. |
| The Making of a Manager | Julie Zhuo | Written by Julie Zhuo, a product designer who joined Facebook in 2006 as one of its early design hires and later became VP of Product Design. Practical, modern, and refreshingly honest about how messy management is. |
| Turn the Ship Around! | L. David Marquet | A nuclear submarine captain who replaced command-and-control with intent-based leadership. Powerful for anyone who wants to build autonomous teams. |
Key takeaways
- The IC-to-manager transition is a career change, not a promotion. The skills that got you here won't carry you forward.
- Your output is now your team's output. Every hour spent doing their work is an hour not spent multiplying their effectiveness.
- 1:1s are sacred. Weekly, 30 minutes, their agenda. Never cancel them.
- Use SBI for feedback — Situation, Behavior, Impact. Specific, non-judgmental, actionable.
- Delegate for development, not just workload management. Match tasks to growth edges.
- Trust is the foundation. Built through consistency, transparency, and low self-orientation.
- First 90 days: listen, diagnose, then act. Making changes before you understand the system creates more problems than it solves.
Knowledge Check
1.A new engineering manager notices that a junior developer's code has a bug. She fixes it herself and ships the feature. What management mistake is she making?
2.Using the SBI feedback framework, which of the following is the best example of effective feedback?
3.According to the first 90 days framework, what should a new manager focus on during days 1-30?
4.In the trust equation (Trust = [Credibility + Reliability + Intimacy] / Self-Orientation), what happens when a manager has high self-orientation?