Growth Engineer

There was a long stretch where marketing filed a ticket whenever it wanted to change the signup screen. The ticket joined the back of a queue, engineering picked it up in turn, review followed, and it shipped. Three weeks a lap. But roughly eight out of ten of these attempts fail. At three weeks a lap you get four laps a quarter, and if three of the four fail the whole quarter produces one result.

Speed wasn't the only problem. From the developer's side, building that screen properly is the right instinct: add tests, handle edge cases, keep it consistent with everything around it. Two weeks of that work getting deleted two weeks later is demoralizing for the person who wrote it and wasteful for the company. The people building and the people requesting held two different beliefs about how long the code was going to live, and nobody ever wrote that assumption down.

The growth engineer role exists to remove that mismatch. Put a developer who writes for deletion inside the team running the experiments and the three-week lap becomes two days, with nobody uncomfortable about the short lifespan.

Most of the day goes into getting this week's attempt in front of users. Build a signup screen with two input fields instead of five, run it alongside the existing one, and instrument both so the pass-through rates can be compared. That's typically one to three days of work.

The job cycles through four kinds of task.

1. Build and ship two variants. This is the implementation side of an A/B test, where users are split at random and only one group sees the change. The split ratio and targeting conditions stay out of the code and live behind a feature flag, because a losing variant has to come down the same day without a deploy.
2. Make the result countable. Which button was clicked, which screen people abandoned — none of it can be read later unless it was recorded. Wiring up event tracking often takes longer than building the screen itself.
3. Delete once the result is in. The losing branch, its flag, and any scaffolding come out. Skip this cleanup and three months later dozens of flags are live that nobody can explain.
4. Turn the repeated parts into tooling. If every experiment attaches flags and events the same way, that part gets built once and configured thereafter. Cutting a lap from two days to half a day is the real output of the role, and it compounds: the quarter that starts with eight possible experiments ends with twenty.

What differs from ordinary product engineering is where the finish line sits. If a screen built in two days answers the same question as one built in two weeks, the two-day version is correct. That isn't permission to be careless. Experiment variants run in production in front of real users, and if one throws errors, those users simply leave. Winning variants get rewritten properly, and experiment code left running loose in production can stop an entire quarter of testing after one incident.

The closest working relationship is with the growth lead, who decides what gets tested and in what order. Thirty ideas get narrowed to the five worth running this quarter and handed over. The engineer builds them and hands back an estimate for each, because a three-day attempt and a three-week attempt sitting in the same list usually change the order.

With a growth marketer the meeting point is the top of the funnel. When ad traffic needs to land on several versions of a landing page, the marketer writes the copy and the engineer builds the machinery that splits traffic across versions. With a data analyst the meeting point is the other end: judging whether an observed difference is real belongs to the analyst, and making sure the records that judgment needs actually exist belongs to the engineer.

Boundaries with the product team need managing. If product is editing the same signup screen, two changes collide. That's part of why this role usually sits in a separate growth team — product, design, and analytics mixed into one group that owns metric improvement rather than feature delivery. The mixing exists because a single attempt passes through all four disciplines, and handing a ticket to the next team and waiting for its queue puts you right back at three weeks.

"Let's put a growth engineer on it and have something live in two days."

Don't put it in the regular roadmap; test it as an experiment.

"Please put it behind a flag — we need to be able to pull it fast."

Build it so it can be turned off without a deploy.

"I'm starting the week by cleaning up last quarter's experiment code."

Removing the leftover branches and flags is this week's work.

At Pagedeck, Theo covers this role. When Ravi brings evidence that ad traffic converts poorly at signup, Theo builds two versions of the screen and shows each to half the arrivals — one with the existing five fields, one asking only for email and password. He instruments both and waits two weeks.

Results land in one of three places. The new version wins and gets rewritten as real code; it loses and the flag goes off and the code comes out that day; or the difference is ambiguous and the call goes to Mia and Ravi. What Theo doesn't do is pick the version he likes. Building two of them was the way to remove that judgment.

The common misreading is a developer who doesn't care about code quality. "Build fast, delete it" invites that. But short-lived code and sloppy code are different things. Experiment variants run in production against real users, and an error there sends those users away for good. What actually changes is not the quality bar but where the time goes: error handling and instrumentation get attention, while visual consistency with the rest of the app and reusable structure wait until something wins.

The other frequent belief is that running experiments faster raises the metric. More attempts, more winners — it sounds reasonable. But volume does nothing if the choice of what to test is weak. Changing a button color twenty times on a screen that already converts well is worth less than one attempt at the place where most people drop out. Speed only pays on top of a good question, which is why this role is paired with someone whose whole job is choosing the questions.