In 2004, I was promoted to Vice President of Application Development at Countrywide Financial. I’d spent the previous two years as a senior developer leading the architecture for a .NET middle-tier platform. The work was hard, the architecture was sound, and the company decided I should run a team.
I managed 13 people through a major core banking conversion. The work shipped. The team held together. Nobody got fired.
I still wasn’t doing my best work, and I knew why. I couldn’t delegate. I was still too in love with writing code, so every problem the team brought me turned into a problem I solved myself instead of a chance to coach the person who brought it. I held the same standard I’d always held as a developer (get it right, do it well, ship it), but now I was holding it for 13 people instead of one, and doing it the only way I knew how: with my own hands.
That’s the trap, and it’s an easy one to walk into.
Why is the promotion harder than it looks?
The logic looks airtight from the founder’s chair. The strongest developer already makes the right technical calls. The team respects them. The promotion costs a title change and a raise instead of an executive search. So the person who’s been right about the code gets the leadership seat.
When it doesn’t work, it isn’t because the person is bad at their job. It’s because the job they’re promoted into is a different job.
Developers are builders. We’re hired, trained, and rewarded for solving problems ourselves. Leadership is mostly the opposite: delegating, coaching, saying no, explaining technical tradeoffs to people who don’t speak the language, and making decisions with incomplete information and living with them. The skills that made someone the best engineer in the room don’t transfer. Some of them, like the instinct to just fix it, actively get in the way.
When it goes wrong, the company can lose twice. The leadership seat isn’t really filled, and the best engineer isn’t really engineering anymore either.
What changed for me
I didn’t figure this out in that role. I learned it over the years after it.
The biggest change was learning to step back. I let people own their work and stepped in only when they actually needed me, not whenever I would have done it differently. The other change was learning to coach instead of take over, and accepting that coaching looks different for each person. Some people do their best work left alone. Some need a push. The job is figuring out which one you’re dealing with.
One example stays with me. Years later, I had a developer on my team who was very laid-back. My boss and a colleague complained that he didn’t show enough urgency. The younger me would have laid into him. Instead, I told him plainly what the complaint was and walked him through what would fix it: how to communicate when an issue came up, so people knew where things stood without having to chase him. I also made it clear he could always come to me for help.
His communication improved. His laid-back nature didn’t change, and that was the right outcome. The problem was never his personality. It was one specific habit that was costing him credibility. Coaching meant fixing that one thing, not turning him into a copy of me. He was someone we wanted to keep.
Years after that 2004 promotion, a developer who reported to me wrote this in a recommendation:
He did not hover. He did not check in just to check in. He let me own my work.
The younger me couldn’t have earned that sentence.
That’s the shift a promoted engineer has to make, and it’s a hard one to make alone.
When shouldn’t you promote them?
Sometimes the answer is to not promote them at all, with or without support. Three situations tell you that.
They don’t want it. Plenty of great engineers take the promotion because it’s the only way up, not because they want to lead. If the honest answer is that they’d rather keep building, believe it. A reluctant leader becomes a frustrated one.
There’s no leadership instinct outside the technical work. Look at what they do when nobody’s asking. Do they mentor the junior developer without being told to? Do they explain decisions in terms the rest of the company understands? Do they handle disagreement without making it personal? If all of their strengths show up only in the code, the leadership skills are still theoretical.
Nobody’s taking over their engineering work. This is the one founders miss. The promotion only looks cheap if you don’t count the work the engineer used to do. If the plan is that they’ll lead the team and keep their old workload, the plan is a problem.
That last one deserves a closer look. On a small team I could switch hats between leading and building, and it worked. That stops working as the role gets bigger, and the limit isn’t company size. It’s team size, platform size, and how much the leadership job actually demands. Past that point, something slips, and which thing depends on the person. If the person can’t let go of the technical work, the leadership goes undone. If they throw themselves into leadership, the engineering work slips. Either way, something nobody planned for ends up without an owner.
What does real support look like?
If they want it, and they’ve shown the instinct, my answer is to promote them. Just don’t leave them alone with it.
A non-technical founder can’t provide that support. Coaching someone into a technical leadership role takes someone who has held one, made the mistakes, and knows which parts of the job are new. Good support covers three things.
The first is someone carrying the senior technology responsibilities the new lead isn’t ready for, or that were never a team lead’s job to begin with: the board conversation, the hard prioritization calls, the vendor negotiation. Those don’t wait while someone learns.
The second is coaching on the work that’s actually new. That means delegation, saying no, and communicating up and across the company. These are learnable skills, but they’re learned by doing them with feedback, not by reading about them.
The third is a plan for stepping back. The support should taper as the new lead takes on more.
This is work I take on as a fractional CTO. The person you promoted leads the team. I hold the senior technology leadership above them part-time, and I coach them through the parts of the job that are new. As they grow into it, I step back. The goal is a lead who doesn’t need me.
An internal senior leader or an outside coach can fill the same role. What matters is that someone does. In 2004, nobody filled it for me.
If you’re about to promote your strongest developer, ask them honestly whether they’re ready to stop being the best developer in the room, and whether they want to. If the answer is yes, give them someone to learn from. If your plan is “they’re great at the technical part, and we’ll figure out the rest,” you’re about to repeat my 2004 promotion with someone else in my seat.