Six roles, each closer to the software other people build on

Mandate

Make an engine company whose online services had outgrown their foundations into one that studios could trust with launches, licences and long production cycles.

Outcomes

• Disclosed a copyleft licence problem to every customer within twelve days, bought a C$520,000 retroactive licence and cut runtime dependencies from 143 to 88.
• Raised Sternhollow Online availability from 99.71 per cent in the first quarter of 2023 to 99.96 per cent across 2025.
• Cut cost per GPU-hour from C$3.10 to C$1.45 with an owned fleet of 128 servers; GPU spending in 2025 was C$14.2 million against C$27 million projected.
• Moved three of five engine subsystems to a new core, with 38 per cent of active projects opted in, while supporting version 5 for five years.
• Made runtime binaries reproducible and moved release signing into hardware security modules.

Decisions in context

I became CTO in March 2021, four years after joining Sternhollow to build its online services, when one of the company's three founders stepped back from the role. Pelloway Growth Partners invested the same year, and the board that came with that investment expected a technology function able to explain its risks in writing. My first two years were about our customers' trust: a bill of materials for every build, the licence disclosure of 2022 and the reliability programme that followed the March 2023 outage. The next two were about cost and architecture: the GPU fleet, which more than halved our cost per useful hour, and the decision to rebuild the engine's core without stranding studios mid-production. I lead 840 people through seven direct reports and present to the board every quarter. Revenue grew from C$262 million in 2021 to C$402 million in 2025.

Reason for the move

Current role. Not seeking an executive move; considering one independent directorship with the Sternhollow board's consent.

Mandate

Turn a beta multiplayer service used by a handful of studios into a product that publishers would trust with a launch.

Outcomes

• Grew live titles on the service from 9 to 140 and its revenue from C$19 million to C$71 million.
• Opened an online services engineering office in Victoria in 2018, with 40 engineers by 2020.
• Introduced written incident reviews and a monthly availability report published to customers.
• Carried a peak of 1.4 million concurrent players through the 2020 holiday season without a major incident.

Decisions in context

I came to Sternhollow in January 2017 to build a business out of what was then a beta: hosted accounts, matchmaking and game servers used by nine titles, run by thirty engineers who were also writing the software. The engine business was healthy, and the company wanted a second line of revenue that studios would pay for every month. Over four years we grew to 140 live titles and C$71 million of revenue. I opened an engineering office in Victoria in 2018, partly to reach engineers who did not want to live in Vancouver and partly to give the service a second location for its on-call teams. We introduced written incident reviews in my first year and began publishing a monthly availability report to customers in 2019, which made our failures visible and our sales conversations easier. The pandemic years tested the service hard; the 2020 holiday season peaked at 1.4 million concurrent players without a major incident.

Reason for the move

Appointed Chief Technology Officer when the founding CTO stepped back to an advisory role.

Mandate

Build one online platform for all the publisher's studios after its first online title launched badly.

Outcomes

• Built a shared platform for accounts, matchmaking and game servers that carried nine titles.
• Raised availability from about 99.5 per cent to 99.93 per cent.
• Carried a peak of 1.9 million concurrent players.
• Introduced blameless incident reviews and limits on consecutive on-call shifts at both sites.

Decisions in context

Valdrecht's first online game launched in 2012 with servers that failed under load for most of its opening week, and the publisher decided that each studio building its own online services was a mistake it could not afford twice. I was asked to build a central group in Montréal, with a smaller team in Malmö, to serve all eleven studios. It was my first production service and my first role managing managers. Over four and a half years we built shared systems for accounts, matchmaking and dedicated game servers that carried nine titles and a peak of 1.9 million concurrent players, and availability rose from about 99.5 per cent to 99.93 per cent. The harder work was persuading studios to give up their own server code and to accept our release rules. I left because I wanted to build online services that studios would choose for themselves.

Reason for the move

Wanted to build online services as a product that studios choose, rather than a cost centre one publisher's studios were obliged to use.

Mandate

Bring the studio's own engine to the point where it could ship an open-world game on three platforms.

Outcomes

• Shipped a large open-world game on the studio's own engine in 2011.
• Cut the nightly build from nine hours to two with a distributed build farm.
• Introduced automated image tests that caught rendering changes before artists did.

Decisions in context

I joined Grisfell as lead engine programmer in April 2008, a year after Valdrecht bought the studio, and became its technical director in 2010. The studio was building an open-world game for three platforms on an engine it had written itself, and the engine could render beautiful scenes that its own build system could barely produce. A full nightly build took nine hours, so a broken change cost a day of work for 300 people. I spent most of my first year on a distributed build farm that brought it to two hours, and on automated image tests that compared thousands of rendered frames each night, so that a rendering change was caught by a machine before an artist lost a morning to it. As technical director I led 140 engineers. The game shipped in 2011 on all three platforms, and the build and test habits I learnt there are still the ones I insist on.

Reason for the move

Asked by Valdrecht to build an online engineering group for all its studios after its first online game launched badly.

Mandate

Write the renderer for the studio's own engine on a new console generation.

Outcomes

• Shipped two console titles on the studio's engine, in 2006 and early 2008.
• Built a texture-streaming system that cut level load times from 48 seconds to 14.
• Trained four junior programmers who later led teams of their own.

Decisions in context

Studio Rivenord was an independent developer of about 180 people in Québec City, earning most of its revenue from development contracts with publishers and putting the rest into its own engine. I joined in February 2004 as a senior rendering programmer, at the start of a new console generation, and wrote much of the renderer for the engine's second version. From 2006 I led the rendering team of six. We shipped two console titles, in 2006 and early 2008, and the texture-streaming system I built cut level load times from 48 seconds to 14, which mattered because the publisher's reviewers had complained about them. A small studio teaches range: I wrote shaders, fixed tools, sat with artists and answered to a publisher's producer about milestones. I left because a larger studio offered me the chance to lead an engine for an open-world game, a scale Rivenord could not reach.

Reason for the move

Offered the lead engine role at a larger studio building an open-world game.

Mandate

Improve terrain rendering in the simulator visual system while holding the steady frame rate that pilot training depends on.

Outcomes

• Rewrote terrain level-of-detail selection, cutting frame-time variance by 60 per cent.
• Built a test harness that replayed recorded customer sessions, including night and precipitation conditions.
• Corrected a night-approach stutter at a customer's training centre within two days of the report.

Decisions in context

My first job after my master's degree was at Cordillon Simulation in Montréal, which built the image-generation systems that show pilots the world outside a simulator's windows. Frame rate there is not a matter of taste: an image that stutters during an approach undermines the training it exists for. I worked on terrain rendering, rewriting the way the system chose levels of detail so that frame times varied far less. In my second winter a change of mine passed every laboratory test and then stuttered on one customer's simulator during a night approach in falling snow, and instructors stopped using the device for two days. I fixed it within two days of the report and then built a harness that replayed recorded customer sessions, weather and lighting included, before any release. I left in early 2004 because I wanted to work where rendering was the product itself.

Reason for the move

Wanted to work where rendering was the product rather than one part of a training device.