The Manager's Paradox: Why Your Best Developers Make Terrible Leads

The email notification popped up on my screen: "Re: Resignation - Marcus Thompson." My stomach dropped. Marcus was our second engineering resignation in three weeks, and both departing engineers had requested exit interviews specifically to talk about "team dynamics." I knew exactly what they were going to say. I'd known for months. But I'd been avoiding the uncomfortable truth: **my best technical decision of the year had been my worst leadership decision**. Six months earlier, I had promoted David Park to Engineering Lead. On paper, it was the most obvious promotion I'd ever made. David was: - Our most productive developer (easily 3x output of anyone else) - Technically brilliant (solved problems others couldn't even understand) - Fast (shipped features in days that would take others weeks) - Dedicated (first one in, last one out) - Self-motivated (never needed direction or hand-holding) He was, by every metric I tracked, our best engineer. And by traditional Silicon Valley logic, that meant he should lead our engineering team. Six months later, team velocity had dropped 40%, we'd lost two senior engineers, three others were actively job hunting, and David was miserable in his new role. I had learned, the hard way, that **great individual contributors and great leaders require opposite skill sets**. This is the story of that failure, and the five fundamental truths I learned about engineering leadership that nobody bothered to tell me. ## The Promotion: How We Got Here Let me set the scene. It's September 2024. Our startup has just raised a Series A, and we're scaling from 8 engineers to 20 in six months. I'm the CTO, and I need someone to lead the core platform team while I focus on hiring, architecture, and board meetings. The logical choice seemed obvious: David. Here's what my reasoning looked like: ```typescript // My flawed leadership algorithm function selectEngineeringLead(engineers: Engineer[]): Engineer { return engineers.sort((a, b) => { // Sort by technical ability (WRONG) const technicalScore = b.linesOfCode + b.algorithmsImplemented - (a.linesOfCode + a.algorithmsImplemented); // I didn't even consider these factors: // - Communication skills: ??? // - Empathy: ??? // - Patience: ??? // - Delegation ability: ??? // - Teaching skills: ??? return technicalScore; })[0]; } ``` David accepted the promotion immediately. In our one-on-one, he seemed excited about the opportunity. He talked about architectural improvements he wanted to make, technical debt he wanted to eliminate, new frameworks he wanted to introduce. I should have noticed: **he didn't mention the team once**. ## Month One: The Performance Machine The first month was actually great. David hit the ground running. He: - Reorganized the sprint planning process - Implemented stricter code review standards - Introduced mandatory architecture review meetings - Set up automated performance testing - Created detailed technical specifications for every upcoming feature Team velocity went UP 15%. I congratulated myself on the great hire. I even submitted him for the company's quarterly excellence award. But I didn't see what was happening beneath the surface. David was doing what made him successful as an individual contributor: **he was creating a system that worked perfectly for him**. The problem? The rest of the team wasn't David. ## Month Two: The Cracks Appear It started with small comments in my skip-level one-on-ones: **From Jenny, Senior Engineer**: "David's code reviews are... thorough. Maybe too thorough? He spent 45 minutes in my PR yesterday explaining why I should have used a different data structure. The code worked fine, it was readable, it had tests. I think he just would have done it differently." **From Marcus, Mid-level Engineer**: "I don't understand the new architecture David proposed. I asked him to explain it, and he sent me links to three academic papers and told me to read them before our next meeting. I have a one-year-old at home; I don't have time to read academic papers at night." **From Lisa, Junior Engineer**: "I'm afraid to ask David questions. Last week I asked him how to implement OAuth, and he looked at me like I'd asked him what a variable is. Then he just implemented it himself and told me to 'study the code.'" I dismissed these as adjustment pains. "David has high standards," I told myself. "The team will rise to meet them." I was wrong. ## Month Three: The Exit Interview Marcus handed in his resignation letter on a Friday afternoon. He'd been with us for two years, was one of our strongest engineers, and had been working on our most critical systems. His departure would hurt. In his exit interview, he was blunt: "I'm leaving because of David," he said. "I know he's technically brilliant. I know he means well. But working with him is exhausting. Every PR is a battle. Every design discussion turns into a lecture. Every question makes me feel stupid. I used to love coming to work. Now I dread it." "Here's the thing," Marcus continued. "David is solving problems nobody has. He's optimizing for theoretical performance issues we'll never encounter. He's introducing complexity because he finds it intellectually interesting, not because we need it. And when I push back, he can't explain WHY we need something in plain English—he just points to benchmarks and papers and acts like I'm being difficult." I asked Marcus if he'd talked to David directly. "I tried," he said. "David told me I was being 'resistant to technical excellence' and that I needed to 'level up my skills.' I have a degree in Computer Science from MIT and ten years of experience. I don't need to level up. I need a manager who listens." That night, I went home and did something I should have done three months earlier: **I actually looked at David's performance as a lead, not just as a developer**. ## The Data Didn't Lie I pulled our sprint metrics for the six months before David's promotion and the three months after: | Metric | Before David Lead | After David Lead | Change | |--------|------------------|------------------|---------| | Story Points Completed | 142/sprint | 85/sprint | -40% | | Average PR Approval Time | 4.2 hours | 26.7 hours | +535% | | Code Review Comments | 12/PR | 67/PR | +458% | | PRs Requiring Revision | 34% | 78% | +129% | | Developer Satisfaction | 8.2/10 | 5.1/10 | -38% | | Code Quality (bug rate) | 2.3/month | 1.8/month | -22% | The only metric that improved was code quality—bugs went down 22%. But **we were shipping 40% less code to achieve that reduction**. The cost in velocity and morale was staggering. I also looked at David's calendar. In a typical week, he was spending: - 18 hours in meetings - 12 hours on code review - 8 hours on architecture planning - 4 hours on one-on-ones - **2 hours actually writing code** For someone whose superpower was writing code, he'd been promoted into a role where he barely got to use it. No wonder he seemed frustrated. ## The Intervention: Hard Conversations I sat down with David the following Monday. I pulled up the metrics. I explained what I was seeing. I read him (with permission) excerpts from Marcus's exit interview. David's immediate reaction was defensive: "Those metrics don't show the whole picture," he said. "Yes, velocity is down short-term, but we're building a much more solid foundation. The code quality improvements will pay off long-term. The team just needs time to adjust to higher standards." "Marcus was never that strong an engineer anyway," he continued. "He was comfortable with mediocrity. We're better off without dead weight." And there it was. The fundamental disconnect. **David thought his job as a lead was to make the best technical decisions**. He saw developers who disagreed or struggled as obstacles to overcome or, worse, as "dead weight" to cut. **But an engineering lead's real job is to multiply the effectiveness of the entire team**. Not to be the best engineer. Not even to make the best technical decisions. To make the team better. I tried a different approach: "David, when you were an individual contributor, what made you successful?" "I could solve hard problems efficiently," he said. "I could deep-dive into complex system, understand them completely, and build optimal solutions." "Right. And what percentage of your time did you spend coding?" "90%," he said. "The rest was meetings and code reviews." "And now?" He was quiet for a moment. "Maybe 5%." "So you've been promoted from a role where you spent 90% of your time doing what you're world-class at, to a role where you spend 5% of your time doing it. How does that feel?" "Honestly? Terrible. I miss building. I miss solving problems. Code review is frustrating because I could implement most of these features better and faster than explaining to someone else how to do it." And there was the core issue: **David had been promoted into a job he was bad at and didn't enjoy, away from a job he was great at and loved**. I had broken David. I had broken the team. And it was 100% my fault. ## Truth #1: Great ICs and Great Leaders Need Opposite Skills After that conversation, I did a retrospective on all the engineering leads I'd known in my career—both good and bad. I identified the core competencies of each role: ### Great Individual Contributors Excel At: - **Deep focus**: Spending hours/days in flow state on a single problem - **Technical perfectionism**: Optimizing every implementation detail - **Independent problem-solving**: Working autonomously without guidance - **Speed**: Shipping code quickly when unblocked - **Complexity**: Thriving in complex technical domains - **Individual output**: Maximizing personal productivity ### Great Engineering Leads Excel At: - **Context switching**: Jumping between different problems/people constantly - **Strategic compromise**: Choosing "good enough" solutions to unblock the team - **Collaborative problem-solving**: Drawing out ideas from others - **Patience**: Letting others learn even when you could do it faster - **Simplification**: Breaking complex problems into digestible chunks - **Team multiplication**: Maximizing collective productivity **These are not just different skills. They're often mutually exclusive**. The deep focus that makes a great IC is directly at odds with the constant context-switching required in leadership. The perfectionism that produces great code leads to analysis paralysis in decision-making. The independent streak that makes an IC productive makes a leader isolated and intimidating. ## Truth #2: Leadership is Not a Promotion—It's a Career Change Here's the mental model I got wrong: I thought of the Engineering Lead role as "Senior Engineer + Management Duties." I thought David would keep being a great engineer while also managing a team. But that's not how it works. **Moving into leadership is not a promotion—it's a complete career change**. It's like promoting a great surgeon to hospital administrator. Yes, medical knowledge helps! But the day-to-day work is entirely different. Most surgeons would hate it. After my realization, I did something I should have done before the promotion: I asked David what he actually wanted from his career. "I want to be the kind of engineer who solves problems nobody else can solve," he told me. "I want to go deep on hard technical challenges. I want to build systems that are elegant and robust." Notice what's not in that answer: "leading a team," "growing other engineers," "making strategic decisions." David didn't want to be a manager. **He'd accepted the promotion because he thought it was the next rung on the career ladder**. In most companies, it is. But it shouldn't be. ## Truth #3: You Need Parallel Career Tracks After the David situation, I redesigned our engineering career ladder. Here's what it looks like now: ``` Senior Engineer II (L5) ├─→ Staff Engineer (L6) [IC track] │ └─→ Sr. Staff Engineer (L7) │ └─→ Principal Engineer (L8) │ └─→ Engineering Lead (L6) [Management track] └─→ Engineering Manager (L7) └─→ Director of Engineering (L8) ``` Key differences: - **Same title levels, same compensation** - Staff Engineer and Engineering Lead are both L6 with identical pay bands - **Different competencies** - Promotions evaluate completely different skills - **Switching tracks is possible** - But treated as a lateral move requiring a "trial period" - **IC track goes higher** - Principal Engineers outrank Engineering Managers in scope and pay This solved several problems: 1. **Talented ICs don't feel forced into management to advance** 2. **Managers are people who actually want to manage** 3. **Technical leadership and people management are separate skills** ## Truth #4: Trial Periods Should Be Mandatory Here's what I should have done with David's promotion: Instead of announcing "David is now Engineering Lead," I should have said: > "We're trying something new. David will be taking on team lead responsibilities for the next quarter as a trial. During this time, he'll split his time 50/50 between leadership duties and IC work. At the end of the quarter, we'll evaluate whether this role is the right fit—both David will assess if he enjoys it, and the team will assess if it's working. No commitment either way." This approach has several advantages: 1. **Lower stakes** - It's easier to back out of a trial than a promotion 2. **Real feedback** - You learn what the role actually feels like 3. **Team input** - You can gather team feedback before making it permanent 4. **Safety net** - The person keeps doing some IC work and doesn't lose those skills When we implemented this policy, something fascinating happened: **40% of people who did leadership trials decided not to accept the permanent role**. They tried it, realized they hated the constant interruptions / political dynamics / slow pace of team work, and happily returned to IC work. And because we'd framed it as a trial, there was zero stigma. If anything, we praised them for self-awareness. ## Truth #5: Some People Should Never Lead (And That's OK) The hardest conversation I had was telling David that I wanted to move him back to a senior IC role. I was terrified he'd quit. In the startup world, getting "demoted" is usually career death. But I framed it differently: "David, I made a mistake. I promoted you to a role that doesn't play to your strengths. You're an exceptional engineer—one of the best I've worked with. But I don't think you're enjoying the lead role, and the metrics suggest it's not a good fit." "I want to move you to a new role: Staff Engineer. Same level, same compensation, but focused entirely on technical leadership. You'd work on our hardest problems, you'd set technical direction, you'd mentor engineers through code and architecture—but you wouldn't manage people or run sprints." "What do you think?" I could see the relief wash over him. "Can I be honest?" he asked. "I hate being a lead. I hate the meetings. I hate the politics. I hate feeling like I'm not building anything. I only took the role because I thought it was the only way to advance." We made the change that week. I brought in Maria Rodriguez—a senior engineer who'd previously been an engineering manager at Google—to take over as Engineering Lead. Maria wasn't our strongest coder, but she was an incredible communicator, mentor, and organizer. ## Six Months Later: The Results The transformation was dramatic: ### Team Metrics (3 months under David vs. 3 months under Maria): | Metric | Under David | Under Maria | Change | |--------|-------------|-------------|---------| | Story Points Completed | 85/sprint | 156/sprint | +84% | | Developer Satisfaction | 5.1/10 | 8.9/10 | +75% | | Voluntary Attrition | 2 engineers | 0 engineers | -100% | | Average PR Time | 26.7 hours | 5.3 hours | -80% | | Code Quality | 1.8 bugs/month | 2.4 bugs/month | -25% | Yes, bug rate went up slightly. But we were shipping 84% more features. The trade-off was absolutely worth it. ### David's Impact as Staff Engineer: In his first six months as Staff Engineer, David: - Solved our scaling crisis by redesigning our data pipeline (something that had blocked us for months) - Reduced our AWS costs by 40% through architectural optimization - Built our ML-based fraud detection system (shipped in 3 weeks, would have taken the team 3 months) - Mentored 4 engineers on advanced topics through pairing sessions and design reviews - Published 2 technical blog posts that drove significant recruiting interest His impact as an IC was 10x what it had been as a lead. And more importantly: he was happy. ### Maria's Impact as Engineering Lead: Maria wasn't our strongest coder. If we'd ranked engineers by lines of code or algorithmic complexity, she wouldn't crack the top 5. But she: - Reduced sprint planning time by 60% through better organization - Created a mentorship program that doubled junior engineer productivity - Resolved interpersonal conflicts before they became exits - Improved our design review process to be more collaborative and less combative - Made the team feel heard, valued, and empowered ## The Framework: Identifying Leadership Potential After this experience, I developed a framework for identifying actual leadership potential. Before considering someone for a lead role, I now evaluate: ### 1. Do They Want It? Not "are they willing to accept a promotion," but "do they genuinely enjoy the work of leadership?" I ask specific questions: - "When in your career have you felt most energized and fulfilled?" - "Would you rather solve a hard technical problem yourself or help someone else solve it?" - "How do you feel after a day of back-to-back meetings?" If the answers emphasize personal technical achievement, they're probably not right for leadership. ### 2. Do They Multiply Others? I look at their history: - Do junior engineers seek them out for help? - After pairing with them, do others code better? - Do they celebrate others' wins as enthusiastically as their own? - Have they ever voluntarily taken a step back from a problem to let someone else grow? David rarely did any of these. He was too focused on his own work. ### 3. Do They Communicate Clearly? Technical brilliance means nothing if you can't explain concepts in simple terms. I now do a "teaching trial": ask the candidate to teach a junior engineer a complex concept. Great IC candidates create brilliant solutions. Great leadership candidates create brilliant explanations. ### 4. Do They Make Others Feel Capable? This is the most important and least talked about trait. After interacting with some engineers, you feel confused and inadequate. After interacting with others, you feel energized and capable. Great leaders are the latter. I started asking team members: "After your last one-on-one with [candidate], how did you feel?" If the answer is "motivated" or "understood," that's a green flag. If it's "dumb" or "overwhelmed," that's disqualifying. ### 5. Do They Think About Systems, Not Just Code? Leaders need to think about: - Team dynamics - Communication patterns - Onboarding processes - Knowledge sharing - Motivation and morale If someone's mental model of engineering is purely technical, they'll struggle with leadership. ## What I Wish Someone Had Told Me If I could go back and advise my earlier self, here's what I'd say: ### 1. "Best engineer" and "best leader" are unrelated Stop assuming your top performer would be a great lead. Evaluate leadership competencies independently. ### 2. Not everyone wants to manage Many engineers take leadership roles only because they think it's the only path to career growth. Give them an alternative. ### 3. Leadership is a different job Don't promote someone into leadership thinking they'll "also" keep coding. Management is a full-time job requiring different skills. ### 4. Trial all promotions Give people a low-stakes way to try leadership before committing. Many will discover they hate it. ### 5. Create parallel career tracks Let ICs advance to the highest compensation and prestige levels without managing anyone. ### 6. Train leaders before promoting them Don't throw someone into a lead role and expect them to figure it out. Provide coaching, mentorship, and resources. ### 7. Measure what matters Don't just track lines of code and bug rates. Measure team velocity, satisfaction, retention, and growth. ## The Broader Industry Problem My failure with David isn't unique. It happens at every tech company, constantly. The pattern: 1. Company identifies their best IC 2. Promotes them to lead without training 3. Team performance drops 4. Company blames the team or the lead's "soft skills" 5. Either the lead burns out or gets "managed up" to a role with less impact 6. Repeat with next best IC This happens because the industry has a fundamental misunderstanding: **we treat leadership as a promotion rather than a career change**. We wouldn't promote our best engineer to VP of Sales without any sales experience. But we routinely promote our best engineers to people management roles with zero management experience. The solution isn't complicated: 1. Create robust IC career tracks 2. Treat leadership transitions as major career changes requiring training 3. Evaluate leadership competencies separately from technical ones 4. Make leadership trials standard practice 5. Normalize "unsuccessful" trials as smart career decisions, not failures ## My Advice to Individual Contributors If you're an IC being asked to consider a lead role: ### Ask Yourself: - Do I enjoy mentoring others more than solving problems myself? - Am I genuinely curious about people's motivations, emotions, and growth? - Can I stay calm when juggling multiple urgent, unrelated problems? - Am I willing to have my personal technical output drop dramatically? - Do I get energized by helping others succeed, even when I don't get credit? If you answered "no" to most of these, **leadership probably isn't for you**. And that's not a failure—it's self-awareness. ### Ask Your Company: - Is there a parallel IC track with equivalent compensation? - Will I lose my technical skills if this doesn't work out? - Can we do a trial period before committing? - Who will mentor me in this role? - What does success look like in 6 months? If your company can't answer these questions, they're not ready to support your transition into leadership. ## My Advice to Engineering Leaders If you're about to promote someone to their first lead role: ### Don't Promote Based On: - Technical skill alone - Tenure - Who deserves a "reward" - Who's demanding a promotion - Who you're afraid to lose ### Do Promote Based On: - Demonstrated leadership competencies - Genuine enthusiasm for people development - Track record of multiplying others' effectiveness - Strong communication and empathy - Systems thinking beyond just code ### And Always: - Provide training before the promotion, not after - Create a trial period with clear success criteria - Have a no-stigma fallback plan - Measure team outcomes, not just individual ones - Support them with coaching and resources ## Conclusion: Different Paths, Equal Value Three years after the David situation, both he and Maria are still with the company. David is now a Principal Engineer (L8)—our highest IC level. He's our go-to person for impossible technical challenges, and he's mentored a generation of engineers in advanced topics. He's never expressed interest in management again. Maria is now our Director of Engineering (also L8), leading three teams. She's not the strongest coder on any of her teams, but those teams are the most productive, most satisfied, and most stable in the company. **They have equal titles, equal compensation, and equal respect**. But they have completely different jobs, matched to completely different strengths. That's how it should be. The myth that great developers make great leaders has damaged countless careers and teams. It's time we acknowledge a simple truth: **leadership is not a promotion from engineering—it's a different profession that requires different talents**. Some of the world's best engineers would be terrible leaders. Some of the world's best leaders are mediocre engineers. **Both are crucial. Neither is superior. They're just different.** My biggest regret isn't promoting David—it's not having systems in place to recognize this distinction before I made that mistake. The framework we've built since has helped us make much better decisions about who leads, who builds, and who does what. If you're a CTO or engineering leader facing this decision: pause. Evaluate leadership competency separately from technical ability. Create parallel tracks. Offer trial periods. And above all, **let your best engineers keep being great engineers**. Not everyone needs to lead. Not everyone should. Your highest leverage decision as a leader is putting people in roles where they can thrive. For technical superstars, that often means keeping them as far from management as possible. --- *The author is a CTO at a high-growth startup who learned these lessons the hard way. Names and identifying details have been changed to protect the innocent (and the not-so-innocent). He thinks about organizational design way too much and can be found on Twitter @definitely_not_my_real_handle.*