When You Can't Tell Who's Good, the Good Ones Leave
Why your best engineers keep quitting (and it might be your fault)
In 1970 George Akerlof published a paper called “The Market for ‘Lemons’” that eventually won him the Nobel Prize. It’s about used cars, but the mechanism it describes has been playing out in engineering orgs for decades. And I think it’s one of the least-discussed reasons good teams decay.
I’ve been circling this for a long time. Pieces show up in things I’ve written about IC leadership, staying on the tools, technical judgment. But I never connected the threads explicitly. The lemons framework does it, and the implications are uncomfortable enough that I want to lay them out.
Akerlof’s thing, in plain terms
His insight was about what happens when the seller knows the product’s quality but the buyer doesn’t. Used cars. Some are good (“peaches”), some are bad (“lemons”), but the buyer can’t tell at the point of sale. The seller knows.
Because the buyer can’t distinguish quality, they’re only willing to pay the average price – somewhere between peach value and lemon value. Rational from the buyer’s perspective. But it creates a brutal dynamic.
The peach sellers look at the average price and think, “My car’s worth more than that.” They leave the market. The lemon sellers look at it and think, “This is more than my car’s worth.” They sell happily.
As peaches leave, average quality drops. The buyer adjusts their price down. More peaches leave. The cycle continues until the market’s dominated by lemons or collapses entirely.
The mechanism is information asymmetry. When the party doing the evaluation can’t accurately assess quality, the market selects against quality. Not through malice. Just cold incentive logic.
Your eng org as a lemons market
Swap “used cars” for “senior engineers” and “buyer” for “engineering leadership.”
In a healthy org, leadership can assess the quality and impact of senior ICs. They see who’s making good architectural decisions, who’s elevating the team, who’s doing the hardest technical work, who’s coasting. With that visibility, the org can reward its strongest performers. Those people stay because they feel recognized.
But in many orgs – more than I’d like to admit – that visibility doesn’t exist. Leadership can’t effectively tell the difference between a staff engineer who’s genuinely shaping technical direction, preventing outages, multiplying the team’s capability, and a staff engineer who attends the same meetings, uses the same vocabulary, produces the same volume of documents, but whose actual technical contribution is thin.
That’s the information asymmetry. And once it takes hold, Akerlof’s mechanism kicks in.
How the cycle plays out
Rewards converge to the average. When leadership can’t differentiate senior IC performance, compensation, recognition, and opportunity all converge to the mean. Everyone at the same level gets roughly the same raise, bonus, project opportunities. Feels fair because it’s equal. But equality isn’t equity when contributions aren’t.
High performers end up subsidizing low performers. The staff engineer carrying a disproportionate technical load notices their colleague – who does less, decides less, builds less – gets the same rewards. The high performer is effectively subsidizing the low performer through uncompensated effort. Doesn’t last.
High performers leave. Like the peach sellers. They look at the average reward and think, “I’m worth more than this.” They interview, get offers that reflect their actual capability, and go. That’s adverse selection. The market’s selecting against quality.
Average quality drops. With the strongest performers gone, the senior IC cohort’s average capability declines. The org might not notice immediately – the remaining engineers still have the same titles, attend the same meetings, produce artifacts. But decision quality degrades. Architecture gets less coherent. Mentoring gets less valuable. The codebase accumulates debt faster.
The cycle repeats. The next tier of high performers – the ones who were average but are now the best remaining – face the same dynamic. They’re doing more than their peers for the same reward. Some leave too. The floor drops again.
I’ve watched this happen. Doesn’t happen overnight. Two to three years for the full cycle. By the time it’s visible to leadership – when outages get worse, velocity drops, new hires have no one strong to learn from – the damage is structural. Hiring a few senior engineers won’t fix it, because the culture and systems that drove the good ones away are still there.
Where the information asymmetry comes from
So why can’t leadership tell the difference?
I’ve written before about staff engineers as force multipliers and the importance of staying on the tools. The lemons framework sharpens why that matters: when senior ICs aren’t doing demonstrable technical work, the information asymmetry that drives adverse selection becomes inevitable.
Here’s the mechanism. As ICs advance to staff, principal, distinguished – there’s a pull away from technical work and toward org work. Meetings, strategy docs, alignment sessions, roadmap reviews. Some of that’s legitimate and valuable. But when it becomes the entirety of the role, something dangerous happens: the observable output of a high-performing senior IC and a low-performing one becomes indistinguishable.
Both attend the same meetings. Both produce documents. Both give opinions in design reviews. Both have “influence” that’s hard to measure. Both speak confidently about architecture and strategy. From the outside – from a VP or director who isn’t deep in the technical details – they look the same.
The only reliable signal of technical capability is technical work. Code written. Systems designed and built. Incidents debugged and resolved. Performance problems diagnosed and fixed. Migrations planned and executed. Concrete, verifiable artifacts that reveal the difference between someone who can do the work and someone who can only talk about it.
When you let senior ICs operate entirely in meetings, documents, and “leadership” without producing hard evidence of technical impact, you’ve eliminated the signal. You’ve created the conditions for a lemons market.
The IC-as-manager trap
There’s a specific failure mode I’ve seen too many times: the senior IC who’s effectively become an unlicensed manager.
They don’t write code. They don’t debug production systems. They don’t build prototypes. They don’t do deep technical investigations. Instead they coordinate work, run meetings, manage stakeholders, “lead” through org influence rather than technical contribution. They’ve drifted into management without the title, the accountability, or the evaluation criteria.
Bad for everyone.
Bad for the org because you’ve got someone evaluated as a technical contributor who’s actually doing management work. Their technical judgment atrophies – they’re not exercising it. Their architectural opinions detach from codebase reality because they’re not in the codebase.
Bad for the team because they lose a senior technical voice and gain an unofficial manager who doesn’t have the training, feedback loops, or mandate to manage effectively.
Bad for the IC because they’re in a role that doesn’t match their title. They’re not developing as a technical leader (no technical work). They’re not developing as a manager (not being coached or evaluated as one). Organizational limbo.
And critically, bad for the lemons dynamic. It inflates the apparent supply of senior technical talent while reducing the actual supply. The org thinks it has ten staff engineers. Reality: six staff engineers and four people doing unfocused management work with staff titles. The six real staff engineers notice. They’re carrying the technical load for ten. The rewards don’t reflect that. The cycle begins.
What actually breaks the cycle
The solution isn’t complicated. It does require honesty and discipline.
Require demonstrable technical output at every IC level. I don’t mean micromanaging what senior engineers work on. I mean a clear expectation that staff, principal, and distinguished engineers produce concrete technical artifacts – code, systems, investigations, prototypes, specs with implementation involvement – as a non-negotiable part of their role. The ratio of hands-on to org work can shift as level increases, but it should never hit zero. A principal who hasn’t touched a production system in six months isn’t functioning as a principal.
Make impact legible. Orgs need mechanisms to make senior IC impact visible to leadership. Technical leadership reviews where staff+ engineers present their work – not their influence, not their meetings, their work. What did they build? Fix? What decision did they make and what was the outcome? If an engineer can’t articulate concrete impact, that’s information.
Differentiate rewards based on evidence. Equal rewards for unequal contributions is gasoline on the lemons fire. Uncomfortable because it requires qualitative judgment about people’s work. But the alternative – pretending everyone at the same level contributes equally – is slow-acting poison. Use the technical evidence to differentiate. Pay your peaches like peaches. If you can’t tell who the peaches are, solve that first.
Close the IC-manager gap. If someone at staff+ is spending most of their time on coordination, stakeholder management, org work – have an honest conversation. Either they shift back toward technical work, or they move to the management track where their actual contributions get evaluated appropriately. The hybrid state – managing without the title – serves no one.
Create evaluation criteria that resist gaming. The lemons market thrives when quality signals are easy to fake. Documents can be produced without insight. Meetings can be attended without contribution. “Influence” can be claimed without evidence. Senior IC evaluation should emphasize outcomes over activities, artifacts over presence, measurable impact over self-reported influence. If your performance system can’t distinguish between a staff engineer who prevented catastrophic data loss through careful system design and one who attended 200 meetings, your system’s broken.
The uncomfortable part
The lemons problem persists because confronting it requires leaders to do something difficult: evaluate senior people critically, differentiate among them publicly, accept that some people at high levels may not be performing at those levels.
Most orgs avoid this. It’s socially uncomfortable. Easier to give everyone the same rating, same raise, same feedback. Avoids conflict. Avoids hard conversations. Feels equitable.
But Akerlof showed what happens when you can’t – or won’t – differentiate quality. The market selects against your best people. Not immediately or dramatically. Steadily and irreversibly until you look around and realize the people who made the org great are gone, and the ones who remain were comfortable with average rewards for average work.
I’ve written over the years about IC leadership, staying on the tools, developing technical judgment. The lemons framework explains why these matter at an org level. It’s not just individual career development. It’s about maintaining the information fidelity that lets an org recognize and retain its best people.
The moment you lose the ability to tell who your best engineers are, you’ve already started losing them. You just don’t know it yet.