The Engineer-Producer Dual Role: A Replayable Founding Pattern

Twice in my career I've taken a producer job at a studio that was too lean on engineering, taken on hands-on engineering work for the first stretch, and then handed it off as the team scaled. Once on Real Racing Next, where I was Lead Producer of a team that started as a literal duo with the technical director and grew past thirty by the time we hit Early Access. Once now, at a founding-stage studio where the engineering bench was thin relative to what the project demanded.

The arc ran the same way both times. An engineer-capable lead producer takes on the engineering load at the founding stage because the team can't yet supply it, then moves back to producer-at-scale once the bench is deep enough. This post is what I've learned about how the arc runs, where it goes wrong, and where it's supposed to end up.

The Arc in One Sentence

An engineer-capable producer, a lean engineering team, and founding pressure produce a temporary engineering lead, who then becomes a scaled producer.

That's it. The whole thing fits in a sentence because none of the steps are subtle, and the ways it goes wrong come down to missing one of the three preconditions or forgetting that the destination is producer-at-scale, not staff engineer.

The Upside

There's a temptation, when describing roles like this, to treat the engineering work as a tax. Time spent away from "real" production, a necessary evil at the founding stage, something to apologize for. In my opinion that framing is wrong.

The engineering credibility built during the founding stage is what makes the producer role at scale more effective, not less. A year inside the build pipeline means the producer can read architecture decisions critically, catch math errors in design specs, and make informed trade-off decisions when scope arbitration gets technical. The role is more effective for having both halves, because the producer at scale is the person making bets the engineering team will live with for years. Making those bets blind is how studios end up with the wrong stack on the wrong project for the wrong reasons.

The engineering work is also, at the founding stage, the only path the studio has to a working product. Pretending otherwise, holding out for "real producers don't do engineering," is a luxury position that the calendar will not honor.

The Costs

That said, the dual role isn't free, and the costs are predictable.

The first cost is the gravitational pull. Once the producer has built the launcher, the build farm, the open-source library scaffolding, those things feel like theirs in a way that's hard to give up. Every escalation pulls them back into the codebase. Every new feature looks like a thing they could just write themselves in an afternoon, faster than explaining it. The producer role suffers in proportion to how much of that pull they indulge, and the damage is invisible until something a producer should have caught slips past.

The second cost is shadow scope. There's almost always an unstated third role, some technical or infrastructural responsibility carried over from the founding period and never fully handed off. AI governance, technical hiring, build-server uptime, any of them. The shadow role is the part of the job that doesn't appear in any job description and yet eats real bandwidth. Left unsurfaced, it stays invisible and it stays the producer's forever.

The third cost is recognition. Founding-era engineering work often shapes the studio's first three years more than anything else does, and it's also the work that's hardest to explain on a CV from a producer role. "I chose Azure DevOps over GitHub and held the choice for four years" is a real engineering decision. It doesn't read like one outside the building.

The Handover Beat

The turning point in both runs of this arc was the handover. When and how the producer starts it determines whether the studio scales healthily or whether the producer becomes a permanent bottleneck.

The signal I trust is team capacity, not role title. When the engineering team can supply more than the project demands, the handoff should already be underway. When the team can supply exactly what the project demands, it's late. When the team can supply less than the project demands, the studio is still in the founding stage and the handover is theoretical.

The handover itself is best done as a split between two co-recipients rather than a single hire. One person inheriting the entire founding-era engineering surface gets stuck firefighting. Two people splitting it along clean lines, one for tools and infrastructure, one for engine and build and TD-scope, can each hold their half. That split is its own post, and I will write it.

The dual-track period is where the actual handover happens. I'm still on call, still in the channels, still the person people DM when something breaks, while the new owners are taking the lead, deferring to me only when they need to, and increasingly not needing to. Six months minimum. Often nine. The handover meeting is just a marker. The work is the months on either side of it.

Naming the Destination

What I did on Real Racing Next, and deliberately replayed at the current studio, was name the destination at the start of the founding stage.

In November 2023, six weeks into the current role, I sent a DM to the studio cofounder that said something like: I don't think I can make as big an influence in tech. There's more I can contribute. Real Racing Next showed me I can do more by doing less. That message wasn't me discovering the plan, it was me explicitly applying a known lesson to a new situation. The destination is producer-at-scale. The engineering work right now is the founding-stage tax.

Naming the destination matters because it changes how the producer makes decisions during the founding stage. The producer refuses to take on permanent technical work. The producer hands off rather than hoards. The producer hires engineers who can grow into the work being done now, rather than engineers who will slot in below. And when the moment comes, the producer has an answer to "what does the producer role look like at scale" that isn't just "the same job but bigger."

The studios I've watched go badly, where the founding engineer becomes a permanent bottleneck or burns out in year three, are almost always studios where the destination was never named. The work just kept arriving and the role just kept stretching to fit it.

The Boundaries of the Arc

This is not a story about engineers becoming producers. The arc only works if the producer role is the destination from day one, and the engineering work is the temporary detour the calendar demands.

It's also not a story about heroic founding contributions. The work I'm describing is real and consequential, but the heroism framing is a trap. It makes the handover feel like loss instead of completion. The point of doing the founding-stage engineering well is that the producer can leave it cleanly when the bench is deep enough to take it on.

The arc is a playbook for the specific case where a studio needs more engineering than its bench can supply, and the producer it's about to hire happens to be capable of supplying it temporarily. That case is more common than the industry talks about, especially at the indie scale. The arc is replayable, the destination matters, and the producer who names it at the start is the one who gets to leave the founding stage behind cleanly.