A year ago I made the most rational career move available to me.
I left ML.
I moved off ML engineering into a non-ML role in the Ads org, because that’s where the clean revenue impact was.
A big project.
A number I could point at. A calibration bullet that would write itself.
The logic was sane. Go where the impact is most legible. It’s the advice everyone gives you, and it’s not wrong.
Impact, impact, impact.
I shipped the thing.
And then I switched back to ML.
It’s the worst trade I’ve made at Google.
Not because the project failed! it succeeded and the number was real!
But that was very short term thinking of me.
This post is about the optimal-looking move. The lateral move that everyone, including you, agrees is the smart play but that quietly resets one of the assets you were actually compounding.
Five angles:
Why “impact” and “skill” are different currencies
The contrast: two engineers, same fork, two outcomes a few years out
Why this trade is worse in 2026 than it has ever been
The playbook: how to tell, before you take the move, whether you’re trading up or chasing a high
When leaving your specialty is actually the right call (because sometimes it is!!)
Let’s go.
1. Impact is a currency that doesn’t compound
Here’s the thing nobody tells you when they tell you to chase impact.
You accumulate two completely different kinds of value as an engineer, and they behave nothing alike.
The first is impact. The launch, the revenue number, the metric you moved.
Impact is local: it’s tied to a specific project, in a specific org, at a specific moment. And it’s cyclical: it lands hard at calibration, and then it decays. Two cycles later, last year’s big win is a line in a doc nobody opens.
Impact resets every time you move.
The second is skill. Specific, scarce, portable, compounding skill.
The depth in a domain that takes years to build and that not many people have.
This is the thing that doesn’t reset when you change teams. You carry it across every move. It compounds, because each year of depth makes the next year of depth more valuable, and because scarcity is the whole game: you get paid for the thing few people can do, not the thing everyone’s doing.
The promotion system can only see one of these. Calibration runs on impact, because impact is legible: it has a number and a date.
Skill depth doesn’t show up as cleanly.
So the system points every smart, ambitious engineer at the same target: maximize visible impact, this cycle, wherever it’s easiest to generate.
And the easiest place to generate visible impact is often outside your specialty: in a role closer to revenue, where the number is bigger and the attribution is cleaner.
So you do the rational thing. You go get the impact.
What the system doesn’t price, because it can’t, is that you just traded a compounding asset for a cyclical one. You won this calibration. And you stopped the clock on the thing that was supposed to make you irreplaceable in five years.
That’s what I did. The Ads project was pure impact: a clean number, no specialty depth required.
2. Same fork, two engineers
Let me make it concrete.
Two ML engineers. Same level, same caliber, same fork in the road: a high-visibility, non-ML, revenue-adjacent project opens up.
The impact is obvious. The promo case writes itself.
Engineer A takes it. Correctly reasoned, by the way. This is not the dumb choice. They ship it, the number is real, the calibration bullet is excellent. They might even get the bump.
Two years later, they’re competing for the next thing on generic impact. And so is every strong SWE in the building, because “I shipped a big revenue project” is a sentence half the org can say.
Their ML has atrophied to the level of someone who read the papers but hasn’t built the thing in years.
The moat they had is gone, and they’re indistinguishable from a very good generalist. The market for very good generalists is enormous and crowded.
Engineer B turns it down, or finds a way to generate impact inside the specialty instead (!!!!): a ranking win, a recsys improvement, a number that happens to require the scarce skill to produce.
This looks slower. It probably is slower, this cycle. The impact is less clean, the attribution messier.
Two years later, they’re one of a handful of people who can actually do the hard ML thing at production scale and the impact came anyway, just routed through the moat instead of around it.
They’re not competing with every generalist. They’re competing with almost no one.
Same fork. Same person, even. Two trajectories.
Engineer A optimized for the impact the system could see.
Engineer B optimized for the impact the system could see that also deepened the thing it couldn’t.
Same output at calibration. Completely different positioning long term.
I was Engineer A. The switch back to ML was me realizing it mid-flight and paying to undo it.
🔒 The rest of this post is for paid subscribers.
