The Three Skills a Senior IC Has to Unlearn to Lead

Last updated: July 17, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Here is something that took me too long to accept. In twenty-five years of building teams and running engineering organizations in fintech and mortgage tech, where the cost of a bad quarter is measured in failed audits and not just missed features, I have rarely watched a promoted engineer fail because a skill was missing. Communication and delegation need work, sure. That is not usually what sinks them. What sinks them is the opposite. They fail because they could not stop doing the three things that made them great.

Sit with that, because it sounds backward. Your best individual contributor got where they are by being fast, being right, and shipping constantly. Those are not bad habits. They are elite habits. And on day one of leadership, every last one of them turns into a liability. If you are weighing this move, or you already made it and something feels quietly wrong, this piece is about the specific muscles you have to teach yourself to relax. It sits under our larger guide on promoting your best IC to engineering manager, and it goes a level deeper than the transition plan does.

There is data under the discomfort. When Google studied what actually made its managers effective, in the research it named Project Oxygen, deep technical expertise landed dead last, eighth out of eight behaviors, a finding it published in Harvard Business Review. Read that again. The single trait you spent a decade sharpening is the one that mattered least in the seat you are moving toward. That is not a reason to throw the skill away. It is a reason to accept that the rules changed under you.

The Arc Has a Door Marked “Stop Doing That”

I have written before about the Builder-Leader-Advisor Arc, the idea that your authority as an engineer compounds across three stages rather than replacing itself as you climb. You earn the right to lead by having built. Fine. But nobody warns you that the door between Builder and Leader opens one way only, and there is a sign nailed to it. Stop doing that.

The IC-to-manager skill shift is not really about learning management. It is about unlearning three engineering instincts that fire on their own, before you have decided anything. Your hands reach for the keyboard. Your mind reaches for the right answer. Your gut reaches for the daily proof that you did something real. Leadership, in the beginning, is mostly the practice of catching each of those reflexes in the half-second before it fires and choosing the slower, harder move instead.

One thing to get straight first, because engineers hear “stop doing that” and panic. Unlearning the reflex to build is not the same as going non-technical. It is nearly the opposite. You stay close enough to the work that nobody can sell you a story you cannot check, which is the entire reason I argued in the piece on why the best engineering leaders stay technical that stepping away from the code is a myth worth killing. Staying sharp is the goal. Being the one whose hands are on the keys is the habit you drop. Different things.

Skill One: Being the One Who Produces the Fix

Your whole career, value flowed through your hands. A ticket came in. You picked it up, went heads-down, and came back with a working thing. Merged. Done. The organization learned to aim its hard problems at you because you closed them, reliably, in less time than anyone expected, which is the entire deal of being a senior IC. You are the one who produces the fix.

Then you get the title. The reflex does not know the title changed.

A payments reconciliation job starts throwing errors at 4pm on a Thursday. You know that code. You wrote half of it. Every cell in your body wants to open the file, find the off-by-one in the batch window, and have it patched before standup. Forty minutes of work for you. Maybe two days of stumbling for the engineer it actually belongs to. So you take it. You feel useful. You were useful.

And you just told that engineer their ceiling is you.

That is the part the reflex hides from you. It does not feel like hoarding. It feels like helping. But every problem you personally solve is a problem you quietly took from someone else. They did not get to solve it. They did not get seen solving it. They did not grow. Do that for six straight months and you wind up with a team that waits around for you to hand out the interesting work, and a version of yourself that is drowning in all of it and cannot figure out why. There is a whole failure mode where the leader becomes the thing every decision routes through, and I gave it its own article because it earned the room, on when you are the bottleneck. The version that matters here is smaller and more personal. The urge to grab the keyboard is not about the code. It is about you, needing to feel useful in the one way you always have. That need is the thing to unlearn.

The move is not “never touch code.” I still read pull requests. I still get in the weeds when the stakes are genuinely real. The move is to ask one question every time your hand drifts toward the work. Is this mine to do, or mine to make sure gets done? Nine times in ten it is the second one, and the honest answer costs you the little hit of doing it yourself. Pay it anyway.

Skill Two: Being the Person With the Right Answer

This one hides better, because it comes dressed as competence.

As an IC you earned trust by being right. You called the load-testing gap before the launch. You said the vendor SDK would not scale, and it did not. Over years, the room learned that your strong opinions tended to hold up, and that reputation became a genuine asset. It is also, the day you start leading, a trap with your name carved into it.

Because now a senior engineer walks you through a design, and it is not the design you would have drawn. Yours is cleaner. You can already see the failure mode they are strolling toward. And you have spent an entire career being the person who catches exactly that. So you correct them. You are right. And you have no idea what it just cost.

What it cost is the next design. And the one after that. People stop bringing you their real thinking the moment they learn the meeting ends at your version regardless, so your strongest engineers, the ones whose judgment you specifically hired the team around, quietly downshift into waiting for yours instead of spending their own. You optimized for being right in one conversation. You paid for it in a team that stopped deciding.

Early in my career I worked for a brilliant engineer who reviewed every line and held an opinion on every variable name. I learned an enormous amount from that man. I also watched good people walk, because there was no oxygen in the room to own anything. So when I started leading, I made the opposite bet on purpose, and it is the same bet I would make again today. If an engineer makes a call I would not have made, I want their reasoning before I lay a finger on the outcome, because nine times out of ten the reasoning is sound and I am the one who learns something. The rest of the time it becomes a quiet conversation about tradeoffs, not a correction from on high. Being right stopped being my job. Making the team right became it.

Here is the blunt version, the line I will defend anywhere. If your best engineers are sitting on their hands, waiting for permission to make calls that are already theirs to make, that is not a people problem. That is a you problem. And it almost always traces back to a leader who could not bring themselves to stop being the smartest voice in the room.

Skill Three: The Same-Day Feedback Loop

Nobody warns you about this one, and it wrecks the most people of the three.

Engineering hands you a beautiful feedback loop. You write the code. The tests pass or fail. The build goes green. The pull request merges. You end the day with a thing that exists that did not exist this morning, and there is a small, real hit of satisfaction buried in that moment. You got that hit most days for a decade. Your entire sense of a day well spent is wired straight into it.

Management pulls the wire out.

Your output as a leader is not yours anymore. It is the team’s output, and it shows up late, indirect, and usually with somebody else’s name on the commit. Andy Grove built his classic book, High Output Management, around exactly this idea, that a manager’s output is the output of the organization under and beside them and nothing about the code they personally touched, which reads as obvious on a slide and feels genuinely terrible the first time you live it. It sounds fine. It is not fine. You will end a full day of one-on-ones and planning and unblocking and quietly conclude that you produced nothing, because by the only scoreboard your brain trusts, you did not merge a single line.

Watch what happens to leaders who cannot let this loop go. They go find the hit somewhere else. They grab a ticket at 11pm to feel a merge again. They rewrite an engineer’s pull request instead of leaving a comment on it, and they call it staying hands-on. It is not that. It is a manager feeding a craving the job stopped satisfying, at the direct expense of the people whose loops they are quietly stealing. Call it what it is. Theft, dressed up as diligence.

So you build a new scoreboard. The wins are real. They are just slower, and they arrive wearing a disguise. An engineer makes a hard call without you and nails it. A project ships clean on a week you were out of the office entirely. Someone you coached two quarters ago gets the promotion. Those are your merges now, and they do not light up the same corner of your brain, so you have to teach yourself, on purpose and for a while in writing, to actually count them. The leaders who cross this gap well are the ones who learned to find real satisfaction in output they will never get to put their own name on. Gallup found that managers account for at least 70 percent of the variance in team engagement, in its State of the American Manager research. You have enormous output now. It just does not compile.

What You Were Rewarded For, and What Changed

Line the three up and the shape is obvious. Every reflex that made you a great engineer optimizes for one thing, you personally producing a result today, and every one of them has to be turned around to point at the team producing results over time. It is not complicated. Here is the map I sketch for engineers weighing the jump.

None of this is a knock on being technical. Read the middle column again. The skills were assets. Real ones. The whole mistake is assuming assets stay assets after the job changes shape underneath them.

How to Tell Which One Still Has You

Self-diagnosis is hard here, because all three reflexes feel like doing the job well. So do not ask yourself the useless question of whether you are a good leader. Ask three narrower ones, and answer them like nobody is watching.

When did you last solve a technical problem that clearly belonged to someone on your team? If the answer is this week, and it was not a genuine fire, skill one still has you. When someone last proposed an approach you disagreed with, did you get curious, or did you correct them? If you honestly cannot remember the last time you changed your own mind inside that kind of meeting, skill two still has you. The tell for skill three is the quietest of the three, and it is the one to trust most. Do you end your best days feeling like you accomplished nothing at all? That feeling is not evidence you are failing. It is the first sign you are finally doing the real job, and your old scoreboard simply has not caught up to the new one yet.

Most newly promoted engineers I talk to have one of the three gripping harder than the rest. Usually just one. You are not trying to score a clean zero. You are trying to learn which reflex is loudest in your own head, so you can hear it coming.

When the Right Answer Is to Hire, Not Promote

Here is the part companies get wrong, and it is a talent decision far more than a training one. Unlearning three deep reflexes is genuinely hard, and it is not the right road for every engineer. Some of your best builders do not want to put those skills down, and honestly, they should not have to. Forcing a brilliant IC into management just to hand them a raise is how you lose a great engineer and gain a struggling manager in a single move.

So treat it like a real build vs buy call. The build path is to take a strong senior engineer, give them a genuine transition with coaching and an actual safety net, and accept up front that this runs in quarters, not weeks. How long it actually takes is its own subject, and I mapped it in the piece on the IC-to-manager transition timeline. The buy path is to bring in someone who already unlearned all three, the hard way, somewhere else. Both are legitimate. Promote-and-hope is the one that fails most. By a wide margin.

Now the obvious bias, disclosed. KORE1 places engineering leaders for a living, so we benefit when you decide to hire one. With that said, the number that matters is retention. Just retention. KORE1 holds a 92 percent twelve-month retention rate on its direct hire placements, and for a leadership seat that figure is close to the whole game, because a leader who quietly gives notice at month nine tends to take a piece of your best team out the door with them. If your bench is thin enough that the wrong person is about to inherit a team they are not ready to lead, fix that before the title gets handed out, not after. You can talk it through with KORE1’s engineering staffing team whenever you want a second read on it.

And if you are the engineer standing at this door, weighing whether to walk through it, I am glad to talk that through too. Connect with me on LinkedIn. If you would rather have KORE1’s help getting the right leader into the seat, or deciding whether to build or buy, you can reach their recruiting team here.

What Newly Promoted Engineers Ask Me About Letting Go

How do I stay technical without sliding right back into doing the work myself?

Draw the line at reading, not writing. Stay deep enough in reviews, design docs, and architecture calls that you can smell a bad decision coming, and keep your hands off the implementation itself. The signal that you crossed the line is simple. If your name is on the commit for work that was never a real emergency, you slid back.

Make being technical an input to your judgment, not an outlet for your hands. I read a lot of code I do not write. It keeps me from getting fooled, which is the entire point of staying close to the work, and it steals exactly zero problems from the people whose actual job it is to solve them.

I genuinely miss writing code. Is that a problem?

No. That is grief, and it is normal. You spent years inside a craft you loved, and you just stepped mostly out of it. Missing it does not mean you chose wrong. Acting on it every afternoon by raiding your team’s tickets does.

Give the craving an honest place to go instead. A weekend project. A prototype that nobody depends on. A genuinely ugly production incident where jumping in actually helps. What you are guarding against is the version of yourself who dresses the itch up as leadership and quietly takes the interesting work back one ticket at a time. Scratch it on your own time, never the team’s.

My team’s solution is worse than mine would have been. Do I let it ship?

Usually, yes. If the approach is workable and the blast radius is survivable, let it ship and let them own the result. A solution the team believes in and can actually maintain beats a cleaner one they built on your behalf and never really understood.

The exceptions are real. You will know them on sight. Security. Compliance. A one-way door that costs a fortune to walk back through. Those are the calls where you personally carry the risk if it goes sideways, and those you can hold onto without apology. Everything else is a chance for someone to learn something a correction from you would have quietly robbed them of. Save your vetoes for the decisions that genuinely cannot be undone.

How do I know I did a good job this week if I did not ship anything?

Change what you count. A good week is one where a real decision got made without you in the room, a blocker got cleared before it cost anyone a day, and one person on your team is measurably more capable on Friday than they were on Monday. None of that shows up in a commit history.

Write those wins down for a while, literally, on paper, because your brain will refuse to credit them on its own at first. The old loop was instant and this one is not even close. After a few months the new scoreboard starts to feel real, the itch to measure yourself in merged lines finally goes quiet, and that quiet is the actual sound of the transition completing.

What if I try to unlearn all this and just hate the job?

Then you say so early, out loud, and you step back with your reputation fully intact. Deciding management is not for you is not a failure. It is one of the more self-aware calls an engineer can make, and any organization worth working for keeps a senior technical track that pays you like the expert you plainly are.

The real failure is staying in a leadership seat you resent because stepping back out of it feels like losing face. That helps nobody, least of all a team reporting to a manager who would rather be writing code. The Builder-Leader-Advisor Arc has more than one path up the mountain. Leading people is only one of them.