I have a joke in my stand-up act:
We spent 20 years telling coal miners to learn how to code, and now AI is doing all the coding and needs more electricity to run, so… back to the mines they go!
It’s a joke, but it belies an underlying truth. Coding boot camps became a refuge for people whose industries and roles were being automated out from under them. Now the refuge itself is getting automated and software engineers are in a quandry.
So what’s a software engineer supposed to do?
One option is to get very good at reviewing AI output: reading PRs, catching logical mistakes, doing regression testing on things AI built. Nobody signed up to be a full-time reviewer of a machine’s work, but that’s honestly where a lot of knowledge work is heading. In fact, I am editing an AI’s revision of this article right now! Playing Where’s Waldo for hallucinations and bugs is becoming the job.
Another option is to specialize. Data engineering, ML engineering, and GTM engineering are all ways of commanding surgeon money rather than general practitioner money, making you harder to displace.
My extremely biased take… GTM engineering is the strongest of these bets.
What a GTM engineer actually does
A GTM engineer isn’t just building product surfaces. They’re stitching together disparate systems to orchestrate the workflows that get a company to market. I’ve written before that building software is no longer the bottleneck, getting it to market is.
GTM engineers are building the engine that monetizes the product, not just the product itself. Being tied directly to revenue is a rare and enviable spot for an engineer. The ROI of their output is concrete and measurable, not something you have to argue for.
Growth and core product should be separate teams
In a well-designed product org, growth and core product are two separate teams, each with its own PM and engineers, sharing resources like PMM, design, and UX where it makes sense.
I say this all the time when explaining this bifurcation: a growth team builds features that benefit the company, while a core product team builds features that benefit the customer. Put both mandates in one backlog and the customer requests will (and should) always win. That’s not a knock on customer requests, it’s just how prioritization works. You build what the customer wants. No customer has ever asked for a new paywall, a tighter plan limit, or a bigger CTA, but those things matter to the business and they’ll never survive a shared backlog with customer-facing work.
Split the teams and the growth org can actually build for revenue impact and measure it. That measurability changes how the engineers on that team think, too. They’re not optimizing for customer delight, they’re optimizing for revenue, and that’s a different and more in-demand skill and mindset to develop.
The bet
Not every company partitions growth from core product. In my not-so-humble-and-definitely-correct opinion, those are the companies that are already poised for failure, and no sane engineer who can see the big picture should want to be there anyway.
Splitting the team early lets a company build for growth from day one, and that does two things at once: it gives an engineer a way to justify their cost with measurable benefit, and it puts them at a company that’s structurally set up to win instead of one that keeps deprioritizing the function that pays for everything else.