Skip to content

From Individual Contributor to Engineering Manager

Navigate the shift to engineering manager: delegation, one-on-ones, performance management and measuring success through other people's output.

5 min read
Split image showing a developer coding at a desk on the left transitioning into a manager facilitating a team meeting on the right

The transition from individual contributor to engineering manager is fundamentally a career change disguised as a promotion. The skills that made you an excellent IC—deep focus, solving hard technical problems, measuring progress in shipped code—become secondary. Your new job is multiplying the effectiveness of your team, and the feedback loops are measured in weeks and months instead of compile cycles.

Most new managers underestimate this shift because the title stays "engineering something." You're still in the engineering department, still in the same stand-ups, still reviewing the same pull requests. But what makes you successful has completely changed.

The Identity Shift

The hardest part isn't learning new skills—it's letting go of the identity attached to being the person who ships the code.

tstypescript
// ❌ The manager who is still an IC
// (This is metaphorical — the real anti-pattern)
class NewManager {
  // Still measures self-worth by personal output
  dailyRoutine() {
    reviewPRs(6); // You do ALL the reviews
    fixCriticalBug(); // Jump in to "save" the team
    writeArchDoc(); // Write it yourself because it's faster
    skipOneOnOnes(); // "Too busy shipping"
    attendStandUp(5); // minutes, barely listening
  }
  // Result: Team doesn't grow, you're a bottleneck,
  // you burn out doing two jobs
}
tstypescript
// ✅ The manager who multiplies
class EffectiveManager {
  dailyRoutine() {
    oneOnOne(teamMember); // 30 min, focused listening
    unblockTeam(); // Remove obstacles, not solve problems
    reviewArchDecision(); // Ask questions, don't dictate
    coachJunior(); // Pair, teach, then let go
    planCapacity(); // Think about next quarter
  }
  // Result: Team ships more than you ever could alone,
  // individuals grow, you build leverage
}

Your output is no longer pull requests. Your output is the team's output. That's a profound change in how you measure whether you had a good day.

Effective One-on-Ones

One-on-ones are your most important meeting. They're not status updates—status belongs in stand-ups and tickets. One-on-ones are for the human side: career growth, frustrations, feedback, and building trust.

markdownmarkdown
## One-on-One Framework
 
### Structure (30 minutes, weekly)
1. **Their agenda first** (15 min)
   - "What's on your mind this week?"
   - Listen. Don't solve. Ask clarifying questions.
   - Take notes on commitments you make.
 
2. **Your observations** (10 min)
   - Share specific feedback (positive and constructive)
   - "I noticed X in the PR review — here's why that matters"
   - Connect their work to larger team/company goals
 
3. **Growth and forward-looking** (5 min)
   - Progress on career goals
   - Upcoming opportunities to stretch
   - "Is there anything blocking you that I can help with?"
 
### Questions that unlock conversation:
- "What's the most frustrating part of your work right now?"
- "If you could change one thing about how we work, what would it be?"
- "What's something you want to learn in the next quarter?"
- "Is there a project or responsibility you'd like to take on?"
- "What feedback do you have for me?"

The last question is the most important and the hardest to get honest answers to. Building psychological safety so your reports actually tell you what's broken requires months of consistently acting on feedback without defensiveness.

The Delegation Framework

Delegation isn't dumping work. It's intentionally matching tasks to growth opportunities while providing the right level of support.

markdownmarkdown
## Delegation Levels
 
### Level 1: Do exactly this
- New team member, unfamiliar domain
- "Implement the API endpoint following this spec exactly"
- Check in frequently, review carefully
 
### Level 2: Research and recommend
- Growing team member, building judgment
- "We need to improve query performance — investigate
   options and recommend an approach"
- Discuss their recommendation, coach the decision
 
### Level 3: Decide and inform
- Trusted team member, strong in the domain
- "The caching layer needs redesigning — make the call
   and let me know what you decide"
- Available if they want to discuss, but don't gate
 
### Level 4: Own it completely
- Senior/staff level, proven judgment
- "You own the authentication system — I trust your
   decisions on architecture and implementation"
- Check in on outcomes, not decisions
 
## Matching delegation level to the person:
- Under-delegating → micromanagement, team atrophy
- Over-delegating → setup for failure, anxiety
- Right-delegating → growth, trust, leverage

The common mistake is delegating at the same level to everyone. A senior engineer needs Level 4 autonomy; giving them Level 1 instructions is insulting. A junior engineer given Level 4 ownership without support will drown.

Giving Constructive Feedback

Feedback delayed is feedback wasted. The most useful feedback is specific, timely, and focused on behavior rather than character.

markdownmarkdown
## The SBI Framework (Situation-Behavior-Impact)
 
### ❌ Vague feedback
"Your code quality needs improvement."
→ What code? What quality? Improvement how?
 
### ✅ Specific feedback using SBI
"In yesterday's PR for the payment service
(Situation), the error handling caught all exceptions
with a generic handler instead of handling each failure
mode specifically (Behavior). This means production
errors will be harder to diagnose because the stacktrace
context gets lost (Impact)."
 
### ❌ Character judgment
"You're not a team player."
→ Defensive response guaranteed
 
### ✅ Behavior-focused observation
"In the last two architecture discussions (Situation),
you presented your approach without acknowledging
the tradeoffs or asking for alternative viewpoints
(Behavior). This made other team members feel their
input wasn't valued, and we missed potential issues
that came up later (Impact)."
 
### Following up:
- Ask how they see the situation
- Listen to their perspective — you might be wrong
- Agree on specific next steps together
- Follow up in the next 1:1 to acknowledge improvement

Managing Performance

Performance management isn't an annual review—it's a continuous process. By the time someone is on a performance improvement plan, you've already failed to give early feedback.

markdownmarkdown
## Performance Tracking System
 
### Weekly observations (private notes)
- What did each team member ship?
- Where did they struggle?
- What skills are developing?
- Any concerning patterns?
 
### Monthly synthesis
- Review weekly notes for patterns
- Compare actual vs expected performance
- Identify coaching opportunities
- Prepare for any necessary conversations
 
### Quarterly career conversations
- Where are you now vs. where do you want to be?
- What specific skills need development?
- What projects would stretch those skills?
- What does the next level look like for you?
 
### The performance conversation spectrum:
  ┌──────────────────────────────────────────┐
  │ Positive  → Coaching → Concern → PIP     │
  │ "Great    "Here's     "This    "Formal   │
  │  work on   how to      needs   improve-  │
  │  X"        level up"   to      ment      │
  │                        change" plan"     │
  └──────────────────────────────────────────┘
  Most feedback should live on the left side.
  If you're jumping to the right, you waited too long.

Protecting Your Team's Time

As a manager, you're the shield between organizational chaos and your team's ability to focus. This means saying no to meetings, pushback on unreasonable deadlines, and absorbing context-switching so your team doesn't have to.

markdownmarkdown
## Meeting Audit Checklist
 
For every recurring meeting involving your team, ask:
1. Does this meeting have a clear purpose?
2. Does my team member need to attend, or can I represent?
3. Could this be an async update instead?
4. Is the attendee list the minimum necessary?
 
## Shield patterns:
- Attend cross-team syncs yourself → relay relevant info in standup
- Batch interruptions → "I'll check with the team and get back to you today"
- Protect maker schedule → no-meeting blocks on the team calendar
- Filter context → not every leadership concern needs to reach your team

Key Takeaways

The fundamental shift from IC to manager is that your output is now measured by team output, not personal output—success means your team ships more, grows faster, and operates more independently than when you were doing the work yourself. One-on-ones are your highest-leverage activity: run them weekly, let the team member set the agenda first, focus on growth and obstacles rather than status updates, and consistently ask for feedback on your own management. Delegate intentionally by matching the autonomy level to the individual's experience and domain knowledge—under-delegating creates bottlenecks and atrophy, while over-delegating without support sets people up for failure. Give feedback using the Situation-Behavior-Impact framework immediately when patterns emerge, because constructive feedback delivered late lands as a surprise rather than a coaching opportunity, and waiting for formal reviews means the behavior has already calcified.

Wilfredo Rujel

Wilfredo Rujel

Full Stack Software Engineer

Share this postX