What the hell is a growth engineer?
And do you actually need one?
Hi there,
A friend of mine was looking for a new senior role in data and Business Intelligence. He’s the kind of brilliant, experienced operator you’d trust to run your entire analytics function without blinking.
So, naturally, I did what any good friend does: went full detective mode.
Scrolling job boards, stalking company careers pages, asking around to see what’s actually out there.
And that’s when I kept coming across a role that made me think: what the…
Growth Engineer
I stared at it for a while. Closed the tab. Opened it again. Read the job spec twice.
A few days later, Ioana from AI Goodies posted something about design engineers, and it clicked. This is not a one-off; this is a shift.
So I went down the rabbit hole to figure out what’s actually going on here, and more importantly, whether this is:
a) a real evolution in how companies build and grow
or
b) another shiny “fix everything” title, like growth hacker (speaking as a former one… I was young, okay?)
So what even is a Growth Engineer?
In theory, a growth engineer is exactly what it sounds like: an engineer focused on growth. Sure, that tracks.
But theory and job specs are very different things, as anyone who’s ever hired a Head of Growth will know. I looked at five real Growth Engineer job specs across companies in the UK, France, and the US, and mapped out the responsibilities the same way I did for Head of Growth roles back in 2022. Here’s what I found:
The core appears consistently across almost every role:
A/B testing and experimentation
Full-stack feature development
Analytics instrumentation
Cross-functional work with product and design
That’s the job. That’s the base.
But then things start to diverge.
Companies 1 and 4 are building product-led growth machines: engineers who ship customer-facing features, run experiments, and own the conversion funnel end-to-end.
Company 2 sits closer to a data-heavy growth analyst with strong engineering chops; they want someone owning CAC, activation rates, and retention cohorts alongside the build.
And then there’s Company 3. Their Growth Engineer, GTM AI role is almost a different job entirely. It’s about building AI agents and automated workflows that power the sales and marketing motion, closer to RevOps engineering than product growth.
No A/B testing in sight. The only thing it shares with the others is the word “growth.”
Which brings me to what worries me.
My concern: the Head of Growth problem, but for engineers
Cast your mind back. Remember when every startup needed a Head of Growth? Or a Growth Hacker? And they were expected to be a data analyst, performance marketer, CRO specialist, product manager, and brand strategist all at once?
I wrote about why that goes wrong in 2022 — still relevant.
The mistake wasn’t hiring for growth. It was conflating “growth is important” with “one person can own all of it.”
I’m starting to see the same pattern here. Some of these Growth Engineer job specs are asking for someone who can:
Build and ship full-stack product features
Design and run rigorous A/B tests
Write SQL and own analytics dashboards
Build AI automation workflows
Partner with marketing on GTM strategy
Mentor junior engineers
Companies 2 and 5, especially.
That is four different jobs. And much like the Head of Growth situation, when you ask one person to do all of it, you usually end up with a jack of all trades and a master of none.
When the role genuinely makes sense
That said, I don’t think this is a bad trend. I think it’s real, and I think it’s the result of two things converging at once.
Ioana made a point in her article about design engineers that applies directly here:
The role isn’t a product of AI, but AI has dramatically accelerated both its visibility and its accessibility — by collapsing the distance between what different disciplines can each do.
A growth person who used to depend entirely on engineering resources to ship an experiment can now build more themselves.
An engineer who used to think purely about code quality can now engage more meaningfully with growth questions.
The gap is narrowing on both sides.
Being a generalist used to be a bad thing; it’s now becoming a strength. AI helps with deep knowledge/perfecting.
Now, understanding how it fits together and challenging the bigger picture is the strength, not specialist knowledge, and asking the right questions to make sure you approach it right
I’ve heard of brands already running fully autonomous growth experiments, an AI agent that handles research, analysis, and test setup with no dev support needed at all. That’s not science fiction anymore.
Someone needs to build and oversee those systems. That someone is increasingly being referred to as a Growth Engineer.
So yes, the role makes sense. But only if it’s scoped correctly.
The three flavours, and why you need to pick one
If you’re hiring a Growth Engineer, or thinking about it, the most important question to answer first is: which type do you actually need?
Even the best generalist will be slightly stronger in one area or another.
Flavour 1: The product growth engineer (Company 1 & 4)
Primarily a frontend or full-stack engineer who lives and breathes experimentation. Strong on shipping, strong on the product funnel.
Their currency is experiment velocity and conversion lift. Hire this person if your growth is primarily product-led and you need someone to build and test features fast.
Flavour 2: The data-led growth engineer (Company 2)
Analytically heavier, owns the metrics, comfortable in SQL and dashboards as much as in code.
Hire this person if you’re at a stage where you need someone to connect the dots on data to build smarter experiments, not just run them.
Flavour 3: The GTM/AI engineer (Company 3)
Much closer to a technical RevOps or GTM systems role (Should they even be called a growth engineer?).
They’re building the infrastructure that powers sales and marketing, not the product experience. Hire this person if your growth bottleneck is in go-to-market execution, not the product funnel.
Conflating these three will get you into trouble. Just like a Head of Growth who’s brilliant at paid acquisition is not the same as one who’s brilliant at product-led loops — the title sounds the same, but the skills are completely different.
The other thing to nail down before you hire: where does the role sit? Growth Engineers who report into engineering tend to be held to engineering standards.
Those who report into growth or marketing tend to skew more strategically but can struggle to get prioritisation.
Neither is wrong, but it’s worth being intentional about it.
My take
Growth Engineer is a real role.
But like a lot of new roles that emerge in the startup ecosystem, it’s currently a container that different companies are filling with very different things.
The underlying insight is correct: as AI speeds up building, the best growth people will increasingly be those who can build, not just strategise. I’m building prototypes and landing pages these days without dev and automating more and more.
And the best engineers focused on growth will increasingly need to think like growth people, not just ship features.
But if you hire a Growth Engineer hoping they’ll be your full-stack developer, your data analyst, your experimentation lead, your AI automation builder, and your GTM strategist?
You’re going to end up with the same frustrated, stretched-too-thin hire that the growth hacker era gave us.
First, define the flavour. Then hire.
Recommendation
In every edition of Growth Waves, I share a resource related to the week’s topic.
Two recommendations this week, since they sit nicely together:
Ioana’s deep dive on design engineers — a different role, but the same underlying shift. If you found this interesting, her piece adds useful context on where engineering and creative disciplines are converging more broadly.
PostHog’s take on what a growth engineer is — interestingly, their take also includes quite a bit of technical SEO. They have some great points about the characteristics a good growth engineer should have.
If you’re considering a Growth Engineer hire, write down the five things you’d most want this person spending their time on.
Then look at the chart above and see which flavour that maps to. If it maps to all three, you’ve found your scoping problem before it becomes a hiring mistake.
Till next week,
Daphne