'Growth engineer' isn't a marketer who can code

Every few months someone posts a growth engineer job spec that is really a marketing ops role with 'SQL a plus' bolted on the end. The two jobs look similar from the outside - both live near the funnel, both touch the CRM, both get asked for numbers on Friday. They are not the same job, and hiring for one when you needed the other is how teams end up with a HubSpot instance nobody trusts.

The test

A marketer who can code automates the thing they already do. A growth engineer changes what the team does, because a system now exists that didn't before. The difference shows up the moment volume moves: the first solution breaks at 10x, the second was designed with a failure mode.

Concretely: if a lead comes in through a form, a marketer who can code writes a Zap that posts it to Slack. A growth engineer asks what happens when the form fires twice, when the company field is 'aaa', when the enrichment provider returns a 429, and when sales changes the routing rule at 6pm on a Friday. Then they build something that answers all four without a human in the loop, and that tells you loudly when it can't.

What it actually looks like

A real week from my side: a sales rep drops a voice note in Slack after a call. An n8n workflow picks it up, transcribes it, extracts the company and the intent, checks the company against an official registry (INSEE in France, FMCSA in the US) so we're matching on a legal identifier rather than a string, then writes a structured record into HubSpot. If the registry match is ambiguous, the workflow doesn't guess - it posts back into the thread and asks.

The interesting part isn't the transcription. Anyone can call an API. The interesting part is the verification step, because that is the difference between a CRM full of records and a CRM full of records anyone believes. That step is an engineering decision with a revenue consequence, and it's the reason the role sits where it sits.

Three things the job actually requires

• Systems thinking over channel thinking. You are wiring lead gen, enrichment, scoring, nurturing, routing and reporting into one graph, not optimising one campaign.
• A tolerance for owning production. If it runs on Sunday morning, it is production, even if it lives in n8n and not in the main repo.
• The ability to read a funnel like a dataset. Cohorts, base rates, confidence intervals. 'It went up' is not a finding.

Where the title earns its keep

The strongest argument for the role is throughput. Marketing, sales and CS all have small, unglamorous asks that a product team will never prioritise: a banner that needs to ship today, a bandwidth view so CS can see who is drowning, a quote generator that removes an hour of copy-paste. Individually none of these justify a sprint. Together they are weeks of team capacity every quarter.

A growth engineer is the person who ships the things that are individually too small to prioritise and collectively too large to ignore.

If you're hiring: stop asking for 'a marketer who can code'. Ask for someone who can draw the system on a whiteboard, name its failure modes, and then go build it. That's a different candidate pool, and it's the one you actually wanted.