You did the logical thing. Your Lead Engineer was crushing it—shipping feature after feature, rewriting broken legacy code over the weekend, and holding the architecture together with sheer intellectual horsepower. They were your "10x" developer. So, when your VP of Engineering said the team needed a manager to handle the growing headcount, you promoted the person everyone already looked up to.
Six months later, your shipping velocity has plummeted. Morale is in the tank. Your best engineer is now spending 30 hours a week in meetings they hate, and your junior developers are flailing because they aren't getting coached—they're getting micromanaged by a boss who just wants to "fix the code" themselves.
You have triggered one of the most expensive anti-patterns in scaling technology companies: The Competency Curse.
By promoting your best individual contributor (IC) to management, you have effectively fired your best engineer. You traded a known asset (high-velocity code output) for an unknown liability (untested management capability). In my experience across dozens of portfolio companies, this transition has a failure rate hovering around 40-50% in the first 18 months. But the real cost isn't just the salary.
When a high-performing engineer fails as a manager, the blast radius affects the entire organization:
The assumption that "better at code" equals "better at leading coders" is empirically false. Google's internal research, Project Oxygen, spent years analyzing what makes a great manager at a deep-tech company. Their findings were a shock to Silicon Valley: Technical expertise ranked dead last among the eight key behaviors of effective managers.
What ranked first? Coaching. What ranked second? Empowering the team and not micromanaging. Your 10x engineer likely excels at technical execution but may view coaching as a distraction from "real work."
The data gets worse. According to Gallup, companies choose the wrong manager 82% of the time. Why? Because the talent required to be a great manager—natural ability to engage people, drive accountability, and build relationships—is rare. Gallup estimates only one in ten people possess high talent to manage.
When you force a brilliant introvert who loves flow states into a role defined by constant context switching and conflict resolution, you aren't offering a promotion; you're offering a punishment.
Let's quantify the damage. If this promotion fails, you likely lose the engineer (who leaves out of embarrassment or frustration) AND 1-2 members of their team. Replacing a senior engineer costs between 30% to 200% of their annual salary in recruiting fees, onboarding time, and lost productivity. For a team of five, a bad manager can easily trigger $2M in replacement costs and lost product velocity in a single year. That's a direct hit to your EBITDA that no amount of late-night coding can fix. (See: The Real Cost of Bad Hires).
If you are currently watching this slow-motion train wreck, you need to intervene immediately. Do not wait for the resignation letter. Here is the operational playbook to reverse the damage.
Sit down with the engineer-manager today. The goal is to destigmatize the move back to IC. Frame management as a role change, not a level change. Use this script: "I’ve noticed you’re spending 80% of your time fighting fires and 0% of your time doing what you love. We need your architectural brain more than we need your calendar management. Let's design a role where you influence the product without managing the people."
Your org chart is broken if the only way to get a raise is to manage people. You must build a Staff/Principal Engineer track that runs parallel to the Management track.
Ensure that a Principal Engineer can earn as much (or more) than a Director. This removes the financial pressure to accept a management role they don't want.
For future promotions, never make the move permanent on Day 1. Institute a 90-day "Acting Manager" period. Set clear KPIs that have nothing to do with code:
At the end of 90 days, give them a "Golden Bridge" to return to their IC role with no loss of face if they (or you) decide it's not a fit. If the situation is already critical and key stakeholders are threatening to leave, you may need a more drastic stabilization plan (See: When Your CTO Quits).
Great code does not equal great management. The highest-leverage move you can make is to let your best coders code, and hire managers who actually enjoy management. Stop solving for status and start solving for strengths.
