Introduction
The transition from individual contributor to engineering manager is one of the hardest career shifts in tech. You stop measuring success by your own output and start measuring it by your team’s output. This guide covers the concrete skills, systems, and mindsets that make that shift work.
The Leadership Mindset Shift
From Doing to Enabling
As an IC, your value comes from shipping code, debugging production issues, and designing systems. As a manager, your job is to unblock, coach, and create conditions for others to do that work. Your direct coding time drops to near zero. If you still measure your day by lines of code written, you will feel unproductive. Retrain your brain to measure success by shipped features your team delivered, bugs your team fixed, and engineers your team grew.
Short-term vs Long-term Thinking
A manager’s work has a delayed payoff. A coaching conversation today might improve an engineer’s performance six months from now. A hiring process you improve today yields better candidates a year later. You must develop patience for investments that compound slowly. This means accepting that some days you will feel like you accomplished nothing visible, even though you planted seeds that will grow.
From Specialist to Generalist
IC careers reward depth. You become the go-to person for database performance or React internals. Management requires breadth. You need working knowledge of your team’s entire domain, plus adjacent systems, plus business context. You do not need to be the expert in everything. You need to know enough to ask the right questions, connect the right people, and spot problems before they become crises.
Management Responsibilities
1-on-1 Meetings
Weekly 1-on-1s are your most important recurring commitment. They are not status updates. They are for building trust, surfacing blockers, and coaching. Use a shared document that both you and the report contribute to.
# 1-on-1 Agenda Template
## Report's Topics (the report fills this first)
- What went well this week?
- What is blocking me?
- What am I uncertain about?
- Topic I want to discuss
## Manager's Topics
- Observations and feedback
- Updates from org-level meetings
- Career development conversation (rotating topic)
- Anything from last week that needs follow-up
## Action Items
- [ ] Owner: description
Run through the report’s side first. Let them set the agenda. If you fill the entire 30 minutes talking, you are doing it wrong.
Performance Reviews
Performance reviews should never surprise anyone. If feedback only appears in a formal review, you have failed at giving ongoing feedback. Use the review cycle to document patterns, discuss trajectory, and set goals for the next period.
Structure a review around three axes:
- Results: What did this person ship? What impact did it have?
- Behaviors: How did they work with others? Did they live the team’s values?
- Growth: How did they improve compared to the previous period? Where should they focus next?
Goal Setting with OKRs
Objectives and Key Results translate team priorities into measurable outcomes. Write objectives that are inspirational and qualitative. Write key results that are numerical and verifiable.
# Team OKR Template
## Objective: Deliver a best-in-class checkout experience
### Key Result 1: Reduce checkout abandonment from 32% to under 20%
### Key Result 2: Ship Apple Pay and Google Pay integration by end of Q2
### Key Result 3: Achieve 99.9% uptime on the checkout service measured weekly
### Key Result 4: Run 5 usability tests with identified fixes documented
## Objective: Improve engineering velocity and developer satisfaction
### Key Result 1: Reduce CI pipeline from 18 minutes to under 8 minutes
### Key Result 2: Achieve eNPS score of 40+ on the quarterly eng survey
### Key Result 3: Onboard 2 new engineers to contributing PRs within their first 2 weeks
Hiring
You will spend 20-30% of your time on hiring as a manager. That investment pays compounding returns because every great hire makes the team stronger. Develop a structured interview process with clear rubrics. Calibrate with other managers regularly. Move fast on strong candidates.
Team Culture
You set the culture by what you tolerate and what you celebrate. If you reward heroes who work weekends, you get burnout. If you reward clean code and sustainable pace, you get a healthy team. Your behavior as a manager is the single strongest signal of team culture. Model the behaviors you want to see.
Delegation
What to Delegate
Delegate everything that does not require your specific context or authority. This includes implementation decisions, research spikes, meeting representation, documentation, and internal tooling. Keep only decisions about team strategy, hiring, firing, compensation, and escalations that exceed your team’s authority.
# Delegation Decision Framework
| Task Type | Delegate? | To Whom | Check-in Cadence |
|---|---|---|---|
| Feature implementation | Yes | Senior engineer | Weekly demo |
| Production incident response | Yes | On-call engineer | Post-mortem only |
| Architecture decision on new system | Yes | Staff engineer | Draft review |
| Cross-team negotiation on API contract | Yes | Tech lead | After initial discussion |
| Performance review write-up | No | — | — |
| Budget planning | No | — | — |
| Hiring committee participation | Rotate | Rotating senior ICs | Quarterly |
How to Delegate Effectively
Delegation without context sets people up to fail. When you delegate, provide:
- The goal: What does success look like?
- The constraints: What are the non-negotiable boundaries (budget, timeline, compliance)?
- The authority level: Can they decide alone, or do they need to check in at specific milestones?
- The support: Where can they go for help if they get stuck?
After delegating, do not micromanage. Agree on check-in cadence and let them execute. If they make mistakes, treat those as learning opportunities, not failures.
Time Management for Managers
Your calendar will fragment. Meetings replace deep work. If you do not protect your time deliberately, you will end up with back-to-back 30-minute slots and zero time to think.
Block Time Strategically
Block calendar time for three types of work:
- Focus blocks: 90-120 minutes with no meetings. Use for strategy, writing, thinking.
- Buffer blocks: 30-60 minutes between meetings for catch-up and context switching recovery.
- Ceremonial blocks: Recurring prep time before 1-on-1s, staff meetings, and reviews.
#!/usr/bin/env python3
"""Time audit helper: calculate how you spent your week."""
import csv
from collections import defaultdict
from datetime import datetime, timedelta
def audit_calendar(csv_path: str) -> dict:
categories = defaultdict(timedelta)
with open(csv_path) as f:
for row in csv.DictReader(f):
duration = parse_duration(row["duration"])
cat = categorize(row["title"])
categories[cat] += duration
return categories
def categorize(title: str) -> str:
title_lower = title.lower()
if "1:1" in title_lower or "one-on-one" in title_lower:
return "1-on-1s"
if "interview" in title_lower or "debrief" in title_lower:
return "Hiring"
if "review" in title_lower or "retro" in title_lower:
return "Ceremonies"
return "Other"
def parse_duration(d: str) -> timedelta:
parts = d.split(":")
return timedelta(hours=int(parts[0]), minutes=int(parts[1]))
if __name__ == "__main__":
audit = audit_calendar("calendar_export.csv")
for cat, total in sorted(audit.items(), key=lambda x: x[1], reverse=True):
print(f"{cat}: {total}")
Managing Context Switching
Each context switch costs 10-20 minutes of productive time. Batch similar meetings together. Put all 1-on-1s on the same day. Put all external stakeholder meetings on another day. Use “office hours” for ad-hoc questions instead of letting chat interrupt you constantly.
Protecting Your Team from Noise
Shields your team from organizational chaos. Do not forward every email from above. Synthesize and prioritize before passing information down. When leadership changes direction, translate that into concrete action for your team. Absorb ambiguity so your team can focus on execution.
Technical Decision Making as a Manager
You no longer make every technical decision. Your role is to ensure the right decisions get made by the right people with the right context.
Decision Frameworks
Use a standard framework for significant decisions:
# Technical Decision Record Template
## Decision: [Title]
## Date: YYYY-MM-DD
## Owner: [Name]
### Context
What problem are we solving? What constraints exist?
### Options Considered
| Option | Pros | Cons | Effort |
|---|---|---|---|
| Option A | ... | ... | 2 weeks |
| Option B | ... | ... | 2 months |
| Option C | ... | ... | 2 sprints |
### Recommendation
Option A — best trade-off between speed and long-term maintenance.
### Consequences
- We will need to migrate legacy data in Q3
- We deprecate the existing API in 6 months
Write these for every significant decision. They create documentation, force clarity, and make it easy for new team members to understand why things are the way they are.
When to Override
Delegate most technical decisions, but override when:
- The decision creates security or compliance risk
- The decision contradicts org-level strategy
- The team is split and cannot reach consensus
- The timeline is critical and the chosen approach is too slow
When you override, explain your reasoning clearly. Your team will accept the decision if they understand the constraints you are operating under.
Managing Underperformers
Every manager eventually faces an underperformer. Address it early. Most managers wait 2-3 months too long.
The Diagnosis
First understand why the person is underperforming:
- Skill gap: They lack technical knowledge. Solution: training, mentorship, paired work.
- Motivation gap: They have the skills but disengaged. Solution: find what motivates them, change their work.
- Fit gap: Their strengths do not match the role. Solution: consider moving them to a different team or role.
- Manager gap: The problem might be you. Are you giving clear expectations and regular feedback?
The Intervention
Use a structured performance improvement conversation:
# SBI Feedback Model
## Situation
"When you presented the Q3 architecture plan to the team on Tuesday..."
## Behavior
"...you did not address the scalability concerns the staff engineers raised, and you moved on without resolving the open questions."
## Impact
"The team left the meeting confused about the direction, and two engineers raised concerns in their 1-on-1s. We lost a week of work because the team had to redo the plan."
## Expected Change
"In future architecture reviews, I need you to address every blocking concern before ending the meeting. If you do not have the answer, assign a follow-up owner before moving on."
The SBI model keeps feedback specific and actionable. It describes what happened and what needs to change without attacking the person.
Documentation
Document performance conversations. Write a brief summary of what was discussed, what actions were agreed, and the timeline. Share it with the employee. This protects both of you and creates a clear record if formal escalation becomes necessary.
Career Progression for Managers
The management track has its own ladder, distinct from the IC track.
# Career Track Comparison: IC vs Management
| Dimension | Individual Contributor | Engineering Manager |
|---|---|---|
| Primary output | Code, designs, documentation | Team health, delivery, growth |
| Success metric | Personal shipped output | Team shipped output |
| Time horizon | Days to weeks | Quarters to years |
| Key skill | Deep technical expertise | Communication, coaching, strategy |
| Decision scope | Your system or module | Your team's domain |
| Meetings per week | 5-10 | 20-30 |
| Coding time | 60-80% | 0-10% |
| Leverage | 1x (your own work) | Nx (entire team's work) |
| Stress source | Technical complexity | People complexity |
| Compensation driver | Technical rarity, impact | Team size, scope of org |
| Next role | Staff / Principal Engineer | Senior EM / Director |
Engineering Manager → Senior Engineering Manager
A Senior EM manages 2-4 teams or a team of managers. Your focus shifts from individual team dynamics to org-level processes and delivery. You start managing other managers instead of individual engineers. You own larger cross-team initiatives and work closely with product and business leadership.
Director of Engineering
A Director owns an org of 30-100 engineers across multiple teams. Your job is organizational design: structuring teams for autonomy, setting engineering-wide standards, and aligning engineering investment with company strategy. You spend most of your time on strategy, hiring at scale, and executive communication. Technical contribution is now entirely indirect.
VP of Engineering
A VP owns the entire engineering organization. This role is primarily about strategy, culture, hiring at company scale, and executive leadership. Technical decisions become about what to build and who builds it, not how to build it. The VP sets the technical vision and ensures the organization has the talent and processes to execute.
Common Mistakes New Managers Make
Mistake 1: Continuing to Code
New managers cling to coding because it feels productive and safe. This starves the team of your attention on the things only you can do: unblocking, coaching, strategy. Stop writing production code. Code reviews and architecture discussions are acceptable, but your primary contribution is no longer code.
Mistake 2: Avoiding Difficult Conversations
No one likes delivering critical feedback. But avoiding it does not make the problem go away. It makes it worse. The underperformer does not get the signal they need to improve, the team resents you for carrying dead weight, and you lose credibility. Deliver feedback early, directly, and kindly.
Mistake 3: Trying to Be Everyone’s Friend
You can be friendly without being a friend. As a manager, you will make decisions that disappoint people: denying promotions, reassigning projects, giving critical feedback. If you prioritize being liked over being effective, you will fail at both. Respect is more durable than popularity.
Mistake 4: Micromanaging
Micromanagement signals that you do not trust your team. Either you hired the wrong people or you have not given them the context they need. Fix the root cause instead of hovering. Give clear goals and then step back.
Mistake 5: Ignoring Your Own Growth
Managers pour energy into their teams and neglect their own development. You need mentors, coaches, and peer groups too. Join an engineering manager forum, find a more experienced manager to mentor you, read management books, and get regular feedback from your team and your own manager.
# Manager Self-Checklist
Ask yourself monthly:
- [ ] Have I had a skip-level 1-on-1 with each team member in the last 6 weeks?
- [ ] Do I know what will surprise my manager this week?
- [ ] When did I last give a team member critical feedback?
- [ ] What is the biggest blocker my team faces right now?
- [ ] What did I do this week that only I could do?
- [ ] When did I last learn something new about management?
- [ ] Am I protecting my team from organizational noise?
- [ ] What decision am I delaying that I should make today?
Mistake 6: Over-hiring for Culture Fit
Culture fit can become a proxy for hiring people who look and think like you. Hire for culture contribution instead: what does this person bring that the team currently lacks? Diversity of thought, background, and experience makes teams stronger.
Conclusion
The transition from IC to manager is not a promotion. It is a career change. You are learning a new profession — one built on enabling other people’s success instead of your own technical output. The first year will feel uncomfortable. That is normal. Invest in your own growth, get a mentor, read widely, and keep asking your team how you can serve them better. Organizations that build strong engineering management pipelines outperform those that promote the best coder and hope for the best.
Resources
- The Manager’s Path by Camille Fournier
- An Elegant Puzzle by Will Larson
- Staff Engineer by Will Larson
- Google’s Guide on Effective Manager Practices (Re:Work)
- The Engineering Manager Community
- Kate Heddleston’s Posts on Engineering Management
- Rands in Repose: The Nerd’s Guide to Leadership
Comments