The transition from writing code to leading people who write code is one of the most jarring shifts in a technical career. Here's what I wish someone had told me.

Your Job Changes Completely

As an individual contributor, success meant shipping features. Lines of code. Pull requests merged. Problems solved directly.

As a lead, success means enabling others to ship features. The work happens through people, not despite them.

This sounds obvious. Feeling it takes time.

I spent my first months trying to do both—lead and contribute as a top IC. I burned out and did both poorly. Something had to give.

The day I stopped measuring my value by code written was the day I started becoming an effective leader.

The Multiplier Mindset

One profound shift: your impact is now multiplicative, not additive.

An hour helping a teammate unblock is worth more than an hour of your own coding. A well-run planning session saves the team days of confusion. A good hire changes the team's trajectory for years.

The math is clear:

• Your code: 1 unit of output
• Unblocking a teammate: They ship + you preserve relationship + you learn their challenges = 3+ units
• Good process improvement: N teammates × time saved × duration = exponential impact

The leverage is in people and systems, not in your personal output.

What Actually Matters

After various mistakes and course corrections, I've found these things matter most:

1. Clarity

People can't do great work if they don't understand what great looks like. Be explicit about:

• Expectations: What does success look like for this role? This project? This quarter?
• Priorities: When everything is important, nothing is. Force-rank ruthlessly.
• Decisions: Explain not just what we're doing, but why. Context creates autonomy.

Ambiguity feels like flexibility. It's actually stress. Teams function better with clear boundaries.

2. Context

Share the "why" behind decisions. Teams with context make better autonomous decisions and feel more ownership.

Instead of: "We need to finish the API by Friday." Try: "Sales has a demo on Monday that depends on this API. If we miss it, we lose a $200k opportunity."

The second version motivates differently. It also lets the team suggest alternatives you might not have considered.

3. Feedback

Timely, specific feedback—both positive and constructive. Waiting for performance reviews is too late.

I try to give feedback within 24 hours of observing something. Positive feedback in public (when appropriate), constructive feedback in private.

The formula I use:

• Situation: "In yesterday's code review..."
• Behavior: "You pointed out three edge cases no one else caught..."
• Impact: "That prevented a bug that would have hit production."

Specific beats generic. "Great job" is nice but forgettable. Detailed feedback sticks.

4. Psychological Safety

Create space for people to take risks, admit mistakes, and ask "dumb" questions. Innovation requires safety.

This means:

• Admitting your own mistakes publicly
• Celebrating learning from failures, not just successes
• Never punishing people for honest errors
• Asking for help yourself

The team will match your vulnerability. If you're invulnerable, they'll pretend to be too—and hide problems until they're crises.

The Hardest Part

Watching someone struggle with a problem you could solve in minutes. The instinct to jump in is strong.

But taking over teaches nothing and creates dependency. The team learns that struggling = leader will rescue me.

Instead:

• Ask questions instead of giving answers
• Guide toward solutions without providing them
• Let them make small mistakes that teach large lessons
• Be available for support, not salvation

It's slower initially but builds a stronger team. Your job is to make yourself unnecessary, not indispensable.

Mistakes I Made

Hiring for Skills Over Culture

I hired a brilliant engineer who was toxic to the team. Output was great; morale was destroyed. We eventually parted ways, but not before losing two good people.

Lesson: Skills can be taught. Values usually can't.

Avoiding Difficult Conversations

A team member was underperforming. I kept hoping it would improve, gave vague feedback, avoided the hard conversation. Six months later, we had the same problem—worse.

Lesson: Quick, compassionate honesty serves everyone better than slow, kind avoidance.

Not Setting Boundaries

I was available 24/7. Every question came to me. I felt important; I was actually bottlenecking.

Lesson: Boundaries protect you and develop your team. If they can't function without you, you've failed.

Trying to Be Friends

I wanted to be liked. This made it hard to give critical feedback, make unpopular decisions, and hold people accountable.

Lesson: You can be friendly without being friends. Respect is more important than likability.

What I'm Still Learning

Leadership isn't a destination—it's a practice. Things I'm actively working on:

• Listening more, talking less: My default is to fill silence with solutions
• Coaching vs. directing: Asking questions instead of giving answers
• Delegation: Truly letting go, including the outcome not just the task
• Strategic thinking: Zooming out from daily fires to quarterly vision

The best leaders I know are the ones who never stopped being students. They read, they seek feedback, they adapt.

Books That Helped

• "The Manager's Path" by Camille Fournier
• "High Output Management" by Andy Grove
• "Radical Candor" by Kim Scott
• "Turn the Ship Around" by L. David Marquet

Final Thoughts

Leadership is a skill, not a personality trait. It can be learned, practiced, and improved.

If you're considering the transition from IC to lead, know that:

• It's harder than it looks
• The skills that made you successful won't make you successful anymore
• The rewards are different but real

Watching a team you've built ship something great—that's a feeling no commit can match.