A senior engineer at a fintech company gets promoted to lead a team of eight. She’s the strongest architect in the org. She designed the system that handles 40% of their transaction volume. The promotion makes complete sense.
Within six months, two of her best engineers request transfers to other teams. A third starts interviewing externally. Her skip-level tells her the team feels micromanaged, that she rewrites their pull requests instead of coaching them through better approaches, and that nobody brings up problems in their 1:1s anymore because she always jumps to solving them.
She’s still the best technical mind on the team. That was never the problem.
The Promotion That Nobody Prepares You For
The move from senior engineer to technical leader is one of the most disorienting transitions in any career. You spent years getting rewarded for going deep on hard problems, for writing elegant code, for being the person who could untangle the most complex systems. Then you get promoted, and the job suddenly requires a completely different set of capabilities.
The technical skills that earned the promotion don’t transfer to the leadership part of the role. Knowing how to design a distributed system doesn’t teach you how to tell a teammate their work isn’t meeting the bar. Being able to debug anything doesn’t prepare you for the conversation where two engineers on your team fundamentally disagree about architecture and it’s becoming personal.
This isn’t a maturity issue or a personality flaw. It’s a skills gap. And it’s predictable enough that coaching conversations about it follow a recognizable pattern: the new technical leader is frustrated that their team isn’t performing at the level they expect, and they haven’t yet realized that their own leadership approach is the bottleneck.
The good news is that people skills are learnable. They aren’t personality traits you either have or don’t. But you have to actually learn them, and most technical leaders don’t get any structured support for that transition.
Skill 1: Delegation (Letting Go of the Work That Built Your Identity)
This is usually the first skill that breaks down. A technical leader who built their reputation on the quality of their own output now needs to let others produce that output, sometimes at a lower quality than they’d deliver themselves.
The failure pattern looks like this: the technical leader delegates a task, reviews the work, finds it doesn’t match what they would have done, and either rewrites it or gives feedback so specific that it amounts to dictation. The engineer on the receiving end learns that “ownership” means “do it exactly the way the lead would do it.” After a few rounds of this, they stop thinking independently.
What effective delegation actually requires from a technical leader:
- Delegating the decision, not just the task. Saying “redesign this API endpoint” and then rejecting every approach that differs from yours isn’t delegation. It’s assigning typing.
- Setting constraints instead of solutions. “The response time needs to stay under 200ms and the interface needs to be backward-compatible” gives the engineer a problem to solve. “Use this exact pattern I drew on the whiteboard” gives them instructions to follow.
- Tolerating good-enough. If the solution works, meets the constraints, and the engineer learned something by building it, the fact that you would have done it differently doesn’t matter. Not every piece of code needs to be optimal. It needs to be shippable.
Technical leaders who struggle with delegation often frame it as a quality concern. “I’m not micromanaging, I’m maintaining standards.” But the result is a team that can’t function without the lead reviewing every decision, which creates a bottleneck that slows everything down and drives ambitious engineers away.
Skill 2: Coaching (Asking Questions Instead of Giving Answers)
Technical leaders default to solving. Someone brings a problem, and the leader immediately knows the answer (or thinks they do), so they give it. This feels efficient. In engineering terms, it’s a O(1) response time.
The issue is that it optimizes for short-term speed at the cost of long-term team capability. Every time you hand someone the answer, you reinforce that the fastest path to a solution runs through you. You become the lookup table for the entire team.
Coaching requires a different instinct. Instead of answering, you ask: “What approaches have you considered?” or “What would happen if you tried X?” or simply, “What do you think we should do?”
This feels painfully slow at first, especially when you can see the answer clearly. But it builds something that giving answers never will: engineers who can solve the next problem without you.
A coaching conversation we’ve seen play out repeatedly in technical teams goes something like this. An engineer brings a production issue to their lead. The lead’s instinct is to diagnose it immediately (they probably already know the root cause from the error pattern). Instead, they ask: “Walk me through what you’ve checked so far.” The engineer explains their debugging steps. The lead notices they skipped the cache layer and asks, “What about the caching behavior in this flow?” The engineer connects the dots themselves.
That interaction took ten minutes instead of two. But the next time a similar issue surfaces, the engineer checks the cache layer first. The lead is no longer a required dependency.
The shift from “smartest person in the room” to “person who makes the room smarter” is the single hardest identity change for technical leaders.
Skill 3: Feedback (The Conversations You’re Avoiding)
Most technical leaders are comfortable giving technical feedback. Code review comments, architecture critiques, design document reviews. That feedback is specific, objective, and protected by the shared understanding that the work isn’t the person.
People feedback is different. Telling an engineer that their communication in cross-team meetings is undermining their credibility, or that their resistance to pairing with junior developers is hurting the team’s growth, or that they’re technically excellent but difficult to work with. Those conversations feel personal because they are.
The avoidance pattern looks familiar across technical teams. The leader notices a behavior problem, hopes it resolves itself, gives vague hints during 1:1s (“maybe try to be more collaborative”), watches the problem persist, grows increasingly frustrated, and either ignores it until someone quits or delivers the feedback in a burst during a performance review when it’s far too late to be useful.
What makes feedback land with technical people:
- Be specific about the behavior, not the trait. “In yesterday’s architecture review, you interrupted Sarah three times and dismissed her caching suggestion without engaging with it” is actionable. “You need to be more of a team player” is noise.
- Connect it to impact. Engineers respect cause and effect. “When you dismiss ideas quickly, the junior engineers stop proposing alternatives. That means we’re only seeing solutions you already agree with, which limits our design space.”
- Make it timely. Feedback delivered three months after the incident is archaeology. Deliver it within a week, ideally within a day or two.
- Separate feedback from evaluation. If every piece of feedback feels like it’s going on a permanent record, people stop listening to the content and start managing the politics.
The technical leaders who lose good people are rarely the ones who give too much feedback. They’re the ones who give too little, too late.
Skill 4: Conflict Resolution (When Two Senior Engineers Disagree)
Technical disagreements are healthy. Architecture debates, tradeoff discussions, “build vs. buy” arguments. These make systems better when they stay productive. They damage teams when they become personal.
The technical leader’s instinct when two engineers disagree is to evaluate both positions technically and pick the better one. This works for straightforward technical calls. It fails completely when the disagreement has an interpersonal layer, which it almost always does after the first round.
Consider this scenario: two senior engineers disagree about whether to refactor a core service or build a new one. Both have valid technical arguments. But what’s actually driving the disagreement is that one engineer designed the original service and feels their work is being dismissed, while the other joined recently and wants to establish their own technical direction. The “technical” debate is partly a status negotiation.
A technical leader who only addresses the technical merits will make a decision, but the losing side will feel unheard. The conflict festers. It shows up later as passive resistance, uncooperative code reviews, or the kind of subtle non-collaboration where two people technically work together but actively avoid making each other’s jobs easier.
Effective conflict resolution for a technical leader means:
- Separating the technical decision from the interpersonal dynamic. Address both, but don’t pretend one is the other.
- Giving both parties a genuine hearing before making a call. Not a performative listening session, but enough time that each person feels their reasoning was understood.
- Naming the non-technical layer when it exists. “I think part of what’s happening here isn’t about the architecture. Let’s talk about that too.”
- Making the decision criteria transparent. If you choose one approach, explain which tradeoffs drove the decision. That gives the other person something concrete to disagree with, rather than walking away feeling overruled.
Skill 5: Emotional Intelligence (Reading the Room You’re In)
Technical leaders often describe themselves as “not political” or “just focused on the work.” This usually means they’re not paying attention to the emotional and social dynamics that affect how work gets done.
Emotional intelligence for a technical leader isn’t about being warm or agreeable. It’s about three practical capabilities:
Self-awareness. Knowing that your frustration with a slow code review process is making you short with the team during standups. Recognizing that your tendency to jump into debugging mode during 1:1s means you’re not hearing what your report is actually telling you.
Reading others. Noticing that an engineer who used to contribute actively in design discussions has gone quiet over the past two sprints. Or catching that a team member’s “I’m fine” during a check-in doesn’t match their body language or their recent work.
Regulating your response is the third piece. Not reacting to a production outage by assigning blame in the incident channel. Not expressing your opinion first in a design review when you know your title will anchor the room. Holding back the Slack message you wrote when frustrated, until you’re not.
A technical leader we’ve seen in coaching described a moment that changed how he thought about his role. He’d given his team a quarter to rearchitect a payment processing pipeline. Halfway through, progress stalled. His instinct was to jump in and take over the design (the skill that built his career). Instead, he asked each team member individually what was blocking them. Turns out, two engineers were working from different assumptions about the requirements, and neither wanted to raise the conflict because the last time someone pushed back on this lead’s direction, the conversation went poorly.
The stall wasn’t a technical problem. It was a trust problem. No amount of technical brilliance on the lead’s part would have uncovered it. Only the willingness to ask, and actually sit with the answer.
Why These Five Skills Compound Together
These skills don’t work in isolation. A technical leader who delegates well but can’t give feedback will produce autonomous engineers who never improve. One who coaches effectively but avoids conflict will develop individual contributors who can’t work together. Emotional intelligence without the courage to deliver feedback is just passive observation.
The compound effect works like this: delegation gives people room to grow. Coaching accelerates that growth. Feedback corrects the trajectory. Conflict resolution keeps the team functional when growth creates friction. Emotional intelligence makes all four of the others land properly.
Technical leaders who develop all five don’t just retain their engineers. They build teams that attract other strong engineers, because the reputation of a manager who actually helps people grow travels fast in engineering networks.
How to Start Closing the Gap
If you’re a technical leader who recognizes yourself in the scenarios above, the worst thing you can do is try to change everything at once. Pick one skill. Whichever one is causing the most visible friction on your team right now.
For most technical leaders, that’s delegation or feedback. Start there.
Take a leadership assessment to get an honest read on where you stand across these skills. Self-perception in leadership is notoriously inaccurate, especially for people who’ve spent their careers in roles where competence was more measurable.
Then practice in real situations. Not in a workshop or a role-play. In your next 1:1, your next code review, your next difficult conversation. Leadership skills develop through repetition in context, not through reading about them.
If you want structured support for that practice, try Merlin, Risely’s AI coach. It works through real leadership challenges with you as they come up, focused on your actual situations rather than generic frameworks. It’s there when you need it, not just during scheduled training sessions.
The engineers on your team didn’t leave because you weren’t technical enough. They left because they needed a leader, not just an architect.
Frequently Asked Questions
What people skills do technical leaders need most?
The five that matter most are delegation, coaching, giving feedback, conflict resolution, and emotional intelligence. Technical leaders tend to over-index on technical decisions and under-invest in the people dynamics that determine whether a team actually ships and stays together. Delegation usually surfaces as the first gap because it requires letting go of the work that built your reputation.
Why do great engineers struggle when promoted to technical leader?
Engineering rewards individual problem-solving and deep focus. Leadership rewards the opposite: multiplying others’ output, holding ambiguity, and having difficult conversations. The skills that made someone a top engineer (going deep, finding the right answer, owning the hardest problems) become liabilities when applied to managing people instead of code.
How can a technical leader improve their people skills?
Start with self-awareness. Take a leadership or emotional intelligence assessment to identify your specific gaps rather than guessing. Then focus on one skill at a time, starting with whichever causes the most friction on your team. Practice in real situations with real stakes, not in workshops. Coaching (from a manager, a peer, or an AI coaching tool) accelerates the process because you get feedback on your actual leadership moments, not hypothetical scenarios.
Can you be a technical leader without managing people?
Yes, in a staff or principal engineer track. But even individual contributor technical leaders need people skills. You still influence without authority, resolve disagreements in architecture reviews, mentor junior engineers, and communicate technical direction to non-technical stakeholders. The skills shift from direct management to persuasion, teaching, and collaboration.