A growth engineer's day has almost no coding in it
I asked two of them to walk me through an ordinary day, and you'll be as surprised as I am.
It's my birthday today 🎈 I can't invite all of you over for cake, so I'm doing the next best thing (debatable, I know):
Inviting you to my free webinar with Andrew Capland on August 19th at 5pm (GMT+1), all about the rise of growth engineers. More on that to come, but don't forget to sign up!
Hi there,
I asked Kameron Tanseli to walk me through an ordinary Tuesday. He runs growth engineering at Flora, and built it at Fyxer.ai while it went from $1m to $32m ARR.
Here’s what he sent back, more or less as written:
Wake up. Double espresso from the Sage Bambino, over ice (snap, same coffee machine!). Gym, breakfast.
Open PostHog. Check the metrics, check the running experiments. (His note next to this line: “peeking lol.”)
Come up with two or three ideas for the backlog and add them to Linear. He’ll often point an LLM at PostHog and BigQuery to do the data science part for him.
Hand the build to Devin, or write it in OpenCode with AI assistance, depending on complexity.
Devin QAs every pull request end to end, with video and screenshots.
Lunch, and a walk in nature.
Merge to production. Launch the experiment. Post it in the #experiments Slack channel.
Meetings from 3pm to coordinate bigger launches with other squads.
6pm: brain dead, go cook dinner.
Read it again and notice what isn’t there:
There’s almost no building in it.
He specs, an agent builds, an agent tests, he merges. The part I always assumed was the job, the part founders think they’re paying an engineer for, has been squeezed into an afternoon and mostly handed to something that doesn’t sleep.
So what actually fills the day
Ben Fanning, a growth engineer at Fyxer, doesn’t describe a schedule at all. He describes a cycle:
Data first
Then ideation
Then design
Then the build
Then analysis
Then improving the tooling that does all of the above.
“There’s a lot of days where you do all of these things in one day, which is part of the joy of growth engineering.”
Six stages, one person, one day. Which only works because five of the six are decisions and one is typing.
Three things eat the hours.
Deciding what’s worth testing. Kameron adds two or three ideas to the backlog a day. Almost none become experiments. He runs one, maybe two a fortnight. The gap between those two numbers is the actual job: analysing, understanding and prioritising.
Checking it’s real before it’s built. Kameron and I approach this similarly: running a few quick calculations before choosing experiments goes a long way toward ensuring you have enough traffic to test and that the opportunity is worth it (MDE = Minimum Detectable Effect).
Checking it’s real after it’s built. At Flora, Devin signs up as a customer for every pull request and sends screenshots of each variant. Kameron’s example: it tried the Stripe checkout, found a coupon leaking in from a different experiment, fixed it, and sent him the new screenshots. His reaction was “I don’t need QA engineers anymore.”
Nobody has ever enjoyed that job. It’s the first one I’d hand over too.
Why one person can hold all of it
Ben describes the role as the centre of a Venn diagram: part software engineering, part experimentation and data, part product and user psychology. Drop a circle and you land in a different job.
Nobody arrives holding all three. There are three routes in, he says: engineering, data, or business. And the most common one now is business, “especially now with AI making the coming from the technical side potentially less important.”
The gate is moving, not closing.
Three things to steal, without hiring anyone
Most of you reading this are five to fifteen people; you might hire one growth engineer, but you won’t have a full team.
So here is what you can learn:
1. Give one person one metric and don’t let them change it. At Flora, one person’s entire job, week after week, is the percentage of new signups who generate an image. Weekly dashboard, weekly experiments, keep going until the number moves. Not a theme. Not an area. One number.
2. Draw a box around it. Kameron’s rule for avoiding collisions is brutally simple: “I will say to an engineer, you are from sign up to paywall. That is your area. You can draw a box around it. No one else is going to really touch it.”
3. Size the test before you build it. You don’t need Fyxer’s platform. You need an honest answer to how long a result would take at your traffic. If it’s four months, you’re testing in the wrong place. Go further down the funnel, where the numbers are smaller, and the money is bigger.
None of those needs a new hire. All three need someone to decide.
What I’d recommend this week
Join us on 19 August. I’m doing a free webinar with Andrew Capland on how these growth roles are pulling apart into different jobs with the same title.
The building has quietly become the cheap part. What’s left is knowing which two of your twenty ideas are worth twelve days, and being honest with yourself when the answer comes back.
Speak soon,
Daphne