You already know you have a problem. The engineer is missing deadlines, or the code quality is slipping, or they're checked out in planning. You've had one uncomfortable one-on-one about it. Maybe two. And now you're sitting with the question that feels like it only has two answers: do I invest more in this person, or do I start the exit process?
The framing is wrong. And the framing is what's going to cost you.
The Two Variables That Actually Matter
The fire-or-invest decision gets murky because managers conflate two separate questions: Can this person do the job? and Are they willing to do the job? GritHR's framework makes this split explicit, and it's more useful than any performance improvement plan template you've ever seen, because it forces you to diagnose before you prescribe.
If someone can do the job and is willing — they're coachable. They need feedback, clearer expectations, maybe a different structure. You're not managing a performance problem; you're managing a support gap.
If someone can't do the job but is willing — that's a training and development problem, not a people problem. This shows up constantly in fast-growing companies that promote internally without building formal development systems around the promotion. Technori's review of engineering career ladders makes the same point: when companies skip structured progression frameworks, engineers plateau not because they lack ability but because the organization never built the scaffolding to develop them. The engineer isn't failing; the organization failed to set them up.
If someone can do the job but won't — that's a behavior problem, and coaching it like a skill gap is where companies waste the most time. GritHR is direct about this: the capable-but-disengaged engineer who's coasting or quietly undermining team norms isn't going to respond to a new mentorship arrangement. You're not solving the right problem.
And if someone can't do the job and isn't trying — that's the clearest case, and the one managers still delay on. If you're already asking whether someone deserves "one more chance," you often already know the answer. PanDev Metrics frames the EM role around exactly this kind of leverage: the highest-impact thing a manager does isn't technical — it's the conversation that prevents the wrong outcome from compounding.
The diagnostic matters because it changes what you do next. Managers who skip it end up coaching people who need to be exited, and exiting people who needed coaching.
The Conversation You're Postponing Is the Decision
Here's the part that doesn't show up in any framework: the timing of when you have the conversation is the decision.
Kevin Goldsmith writes about this directly from his time managing at Adobe. He had a senior engineer who kept raising legitimate architectural concerns and kept getting drowned out by louder voices. Goldsmith agreed with him. He just didn't want the confrontation with the rest of the team. He kept asking the engineer to be patient. By the time he decided to act, the engineer had already accepted an offer elsewhere to lead an architecture group. The loss wasn't from a wrong decision — it was from not deciding soon enough.
The pattern Goldsmith identifies is worth sitting with: the cost of being wrong is immediate and visible. You said something, the person was having a bad week, you damaged a relationship over nothing. But the cost of being right and late is delayed and diffuse. The pattern hardens. The person adapts to the absence of feedback. The team makes up its own story about why nothing is being said.
This applies in both directions. If someone is underperforming and you're waiting for more data before having the hard conversation, you're not being careful — you're letting the situation calcify. And if someone is genuinely struggling but could grow, every week you don't give them clear, direct feedback is a week they're operating without the information they need to improve. Reuters reported on a 26-year-old engineer who opted out of the promotion track entirely — a reminder that some engineers aren't underperforming, they're misaligned with what the role is asking of them. That's a different conversation than a performance conversation, and conflating the two wastes everyone's time.
Vaidehi Joshi's piece at LeadDev is useful here: the engineering manager's job is to support the team as a unit and the individuals within it, and those two things are sometimes in tension. The team pays attention to what you tolerate. If a struggling engineer is dragging delivery and you're running a quiet, private coaching track while the rest of the team absorbs the slack, you're making a team culture decision whether you intend to or not.
What You're Actually Optimizing For
The question worth asking before you decide anything: what would I need to believe for continued investment to be the right call?
You'd need to believe the performance gap is diagnosable and addressable in a timeline that doesn't damage the team. You'd need to believe the person is genuinely engaged and responsive to feedback — not just agreeable in one-on-ones. And you'd need to believe the investment cost (your time, the team's patience, the opportunity cost of a role that could be filled differently) is worth the upside.
Retention research flagged by ai-infra-link points to a related trap: companies over-index on retention as a goal in itself, when the actual goal is a high-functioning team. Keeping someone who can't or won't perform isn't retention — it's avoidance dressed up as loyalty.
If you can't answer yes to all three questions above, you're not investing in someone's growth. You're deferring a decision that's already
