You have a senior engineering role to fill. Maybe a tech lead slot opened up, maybe you're adding a new team and need someone to anchor it, maybe your current lead just gave notice and you have four weeks to figure it out.
Your first instinct is to look internally. You have someone in mind — solid engineer, respected by the team, been here two years. Promoting them feels like the right call. It rewards loyalty, it's faster, it's cheaper, and you already know what you're getting.
All of that is true. And none of it answers the actual question.
What You're Actually Optimizing For (And It's Probably Not What You Think)
Most managers frame this as a cost-and-speed problem. External hires take longer to source, cost more to bring in, and need time to ramp. Internal promotions are faster and cheaper. Case closed.
But that framing collapses the moment you ask: what does this role actually need to do in the next 12 months?
If the answer is "lead a team that already knows the codebase and needs stability while we ship a big feature," promoting internally is probably right. The person already has context, relationships, and credibility. You're not buying anything new — you're formalizing something that's already happening.
If the answer is "set technical direction for a domain we're entering for the first time, manage a team that's been underperforming, and push back on product when they're wrong," that's a different job. And the question becomes whether your internal candidate has actually done those things, or whether you're betting they'll figure it out.
That distinction — demonstrated capability versus potential plus familiarity — is where most of these decisions go sideways.
The Hidden Constraints Nobody Puts on the Whiteboard
There are a few variables that rarely make it into the explicit analysis but usually determine the outcome.
The ceiling problem. Promoting someone into a role they're not quite ready for isn't inherently bad — stretch assignments are real. But there's a difference between a six-month stretch and a two-year gap. If your internal candidate would need 18 months to grow into the full scope of the role, ask yourself what happens to the team during those 18 months. Someone is absorbing the cost of that learning curve, and it's usually the people they're managing.
The relationship inversion. When you promote an engineer to lead their former peers, you're not just changing their job title — you're asking them to renegotiate every working relationship on the team. Some people navigate this well. Many don't. The ones who struggle tend to either over-correct into authoritarianism (overcompensating for imposter syndrome) or under-correct into conflict avoidance (not wanting to damage friendships). Neither is great. This isn't a reason to never promote internally, but it's a variable that deserves explicit attention before the decision, not after.
The external hire's real cost. Research from the Wharton School of Business found that external hires are paid roughly 18% more than internal promotions for equivalent roles — and still tend to receive lower performance evaluations during their first two years. That's a real number worth sitting with. You're paying a premium for someone who will, statistically, underperform your internal candidate in the near term. The question is whether what they bring — new patterns, outside experience, specific domain knowledge — is worth that premium given your actual situation.
The signal you send either way. Whoever you don't choose will notice. If you pass over a strong internal candidate for an external hire, you've just told your team something about how you value tenure and loyalty. If you promote someone who isn't ready and they struggle visibly, you've told the team something about your judgment. Neither outcome is fatal, but both have downstream effects on retention and trust that don't show up in the immediate decision.
Where These Decisions Usually Break Down
The most common failure mode isn't choosing wrong — it's choosing for the wrong reasons.
Promoting internally because it's politically easier (the team expects it, the person has been waiting) is how you end up with a struggling new lead and a resentful team six months later. External hiring because you're excited about a candidate's resume and want to "level up the team" is how you end up with someone who can't ship anything for eight months because they don't understand the codebase or the culture.
The second failure mode is treating this as a one-time decision rather than a system. I'd argue the managers who handle this well aren't making better individual calls — they're maintaining a clearer picture of who on their team is developing toward what, so the decision isn't made under pressure with incomplete information. When a senior role opens up and you're genuinely uncertain whether anyone internal is ready, that's often a signal that you haven't been investing in development conversations consistently enough.
The third failure mode is conflating technical seniority with leadership readiness. A strong staff engineer who leads through technical influence — setting direction, shaping architecture, mentoring others — is not automatically ready to manage people. Those are genuinely different skill sets, and very few people have both and can deploy them simultaneously. Promoting your best IC into a people management role because they're your best IC is a classic way to lose a great engineer and gain a mediocre manager.
How You Know If It's Working
For an internal promotion: within 90 days, the new lead should be running their own team meetings without you, having direct conversations with product and stakeholders, and making at least some decisions you disagree with. That last one matters. If they're still checking in on everything, they haven't actually taken ownership — they've just gotten a title change.
For an external hire: the ramp period is real and you should plan for it explicitly. But by month four or five, they should be contributing something the team couldn't do before — a different way of approaching a problem, a pattern from their previous context, a harder conversation with product that needed to happen. If they're still just learning the codebase at month six, something went wrong in either the hire or the onboarding.
Three Questions Worth Asking Before You Decide
What would I need to believe about my internal candidate for this to be the right call? Write it down. If the list includes things like "they'll figure out the conflict avoidance thing" or "they'll get better at pushing back on product," those are bets, not plans.
What does this role need to do in the next 12 months that it hasn't needed to do before? If the answer is "more of the same, just more of it," internal promotion is probably right. If the answer involves genuine new capability, be honest about whether you're buying that or betting on it.
Who on my team is watching this decision, and what will they conclude? Not because you should optimize for optics — you shouldn't — but because the downstream effects on trust and retention are real costs that belong in the analysis.