immutable.build
Work
immutable.build
Production record

The Build Log.

immutable — the standard doesn’t move

17 titles · 3 franchises + select work · 2006–2024

Every title I’ve shipped, in order: from QA Tester in 2006 through Senior Producer, across Tony Hawk, Guitar Hero, and Call of Duty. Most recently: Senior Producer leading a 20–40-person engineering org (Engine & Graphics, Tools, Systems, Build & Release) behind Warzone, owning live-service crash rate from 2021–2023 and defending an under-3% per-platform target.

// Continuous studio tenure 2006–2023 through Neversoft’s wind-down and merger into Infinity Ward carried the move from Guitar Hero to Call of Duty. Years above are title release dates; production wraps before a game ships. Since 2023: a deliberate sabbatical. Independent technical work, self-hosted infrastructure, AI-directed tooling (see /projects and the résumé). And now a return to studio work.

// verify — credits on MobyGames ↗

branch: Call of Duty · 7 titles 2013–2024 · Neversoft → Infinity Ward
Call of Duty: Warzone Mobile 2024 · Senior Producer
7d3674c
Modern Warfare II 2022 · Senior Producer
1b19013
Warzone 2020 · Senior Producer
29a9d5a
Modern Warfare 2019 · Senior Producer
5eddd6b
Infinite Warfare 2016 · Producer
3c442c5
Advanced Warfare 2014 · Producer
343582d
Ghosts 2013 · Producer
35d933b
branch: Guitar Hero · 7 titles 2007–2010 · Neversoft
Warriors of Rock 2010 · Associate Producer
84aad89
Band Hero 2009 · Production Coordinator
a7bf2ee
Guitar Hero 5 2009 · Production Coordinator
ebdde38
Guitar Hero: Metallica 2009 · Production Coordinator
e13e174
World Tour 2008 · QA Lead
95fd139
Aerosmith 2008 · QA Lead
99c9cb6
Guitar Hero III: Legends of Rock 2007 · QA Tester
86ad44b
branch: Tony Hawk · 2 titles 2006–2007 · Neversoft · Neversoft ran both titles in 2007: QA title reflects the project, not a demotion
Tony Hawk's Proving Ground 2007 · QA Lead
65a0199
Tony Hawk's Project 8 2006 · QA Tester
a5ec155
branch: Other · 1 title 2014
Duck Dynasty 2014 · Mo-Cap Producer
567319a
// field report

Same collision, every sprint.

Committed tooling work kept missing its sprints, even though the calls that bumped it were usually the right ones. How burndowns read sprint over sprint showed where the tooling time was going, and the case for splitting Tools from Build & Release.

6 → 8
engineers across both
teams, plus a director
~6 months
from pitch to
two teams standing
Burndowns
and a list of build fires,
put in front of my directors
situation — see it

In 2019, Tools and Build & Release at Infinity Ward were one team. The same engineers built the studio’s tooling and kept the build pipeline running. When a build broke, the pipeline usually won, because an unstable build blocks QA, and most of the time that was the right call. The cost showed up in the tooling work, which slipped sprint after sprint.

diagnosis — solve it

The case I took to my directors was sprint slippage. Any one sprint’s burndown just looked like a busy team; the rollover only showed sprint over sprint. So I brought the burndowns across sprints, with the committed tooling tickets rolling over, and a list of the build fires that had pulled engineers off them. The same fires lined up with the rolled-over tickets. As long as one team did both jobs, the next fire would pull the same engineers off the tooling work again.

outcome — seal it

I pitched separating the two teams and made the case. They took the recommendation and hired a Build & Release director to run that team. Two tools engineers moved over and two more were hired in, so the combined teams went from six engineers to eight, plus the director. It took about six months from pitch to two teams standing, and I produced both. What I saw after: tools shipping on their own cadence, and build support that got faster and more visible across the studio.

// field report

Fix the cause, not the noise.

How a scattered Warzone live error got diagnosed down to a single root cause, and why understanding the system is what made the fix obvious.

Same day
hotfix coordinated
and shipped
1
root cause behind
many symptoms
3
teams, each owning
its durable fix
situation — see it

A live error was surfacing all over Warzone. It was being worked as many separate problems: different symptoms, different owners, no shared cause, and it kept coming back. It looked like many problems. It was one.

diagnosis — solve it

I built the repro from first principles, traced the behavior back to a single root cause, and could show exactly where it entered the pipeline and why it kept returning. I didn’t start this one by triaging symptoms. I started by understanding the system well enough to know what was actually broken. Once the cause was understood, the fix was obvious, and so was the team that owned it.

resolution — seal it

I coordinated the hotfix, and it shipped the same day. Each durable fix landed with the team that owned the gap: content, build, and QA.

// field report

Two years under three percent.

The incident above was one day. This is the standing system behind every day: the crash-rate program that kept the game under its target across three platforms and three modes.

Under 3%
crash rate held
per platform
Daily
triage cadence,
every morning
Handed off
run day to day by a
production coordinator
situation — see it

Call of Duty was live on three platforms and in three modes: Warzone, Multiplayer, and Co-op. All on one shared codebase, so most crashes reproduced everywhere. The target: under 3% per platform. Every weekly update went out through QA; the crashes that reached players were the kind that only surfaces at live scale. When I took the program on, the platforms’ crash data was there but we didn’t have a daily view of crash rate, and every team ran its own crash list with its own priorities. The crashes that didn’t reproduce everywhere were exactly the ones those lists buried: an Xbox-only crash was never going to top the PlayStation team’s list.

system — solve it

I stood up a daily review of crash rate first, then unified the scattered lists into a single source of truth. The program settled into three parts:

→ A daily loop: every morning, confirm the top crash classes each have a named owner and a live status, and chase the ones that don’t
→ A studio-visible wiki: every active crash class with its priority, its owner, and its tracking issue; one page, one priority order, every team reading the same list
→ Searchable callstacks: I pulled crash dumps off the platform holders’ portals, extracted the callstacks, and pasted them into the tracking issues. A new crash got searched before it got worked; most turned out to be a class we were already tracking

Every issue went out with the QA manager, the team’s producers, and the engineering lead already in the loop, and I did the tedious parts myself first (pulling dumps, writing status) before asking anyone else to. The process stuck because following it cost every team less than ignoring it.

outcome — seal it

The target held: under 3% per platform, 2021 through 2023. That was never a flat line: rates spiked, and the system caught spikes and drove them back under. Once the loop had proven its worth, I delegated it deliberately and moved to the next problem that needed a system; the handoff is its own story. The target was still holding when I left.

// the method in full — The dashboard is not the system →

// field report

Six years of Tuesdays.

The Warzone report above was one day. The crash program is the safety net. This is the day job: the milestone cadence, resource planning, and unblocking that kept the org shipping for six years.

3 titles
shipped on this loop
2019–2023
20–40
person engineering org
across four disciplines
Early
slipping targets flagged,
not deadline surprises
situation — see it

A 20–40-person engineering org, one Call of Duty title at a time, and, from 2020, Warzone’s live service running alongside it, with tools support for Warzone Mobile under that live service. Some disciplines, mostly Build & Release and Tools, were pulled toward more than one deadline. None of that was a crisis. That was a Tuesday. The job was to keep the org shipping without making engineers absorb the churn.

system — solve it

The loop I ran, over and over, for six years:

→ Prioritize where the tradeoffs live. Prioritization sessions with the tech director, including the tools program serving a 300-person studio, turned into milestone plans and sprint schedules the teams could actually commit to
→ Allocate resources. Resource allocation sat in my production lane alongside sprint planning and risk management
→ Guard focus time. Inbound tool and pipeline requests hit me first, not the engineers; I gathered the full context, triaged, and escalated only what was worth an engineer’s attention

And when a target moved (on a live franchise, it always does), I re-planned scope and trajectory and flagged the change early. Flagged early, a change is a plan. Flagged at the deadline, it’s an apology.

Once, the fix was the org itself: in 2019 I made the case for splitting Tools from Build & Release. That story is the first report on this page ↑

outcome — seal it

Three titles shipped between 2019 and 2023 on that loop, with Warzone live underneath from its 2020 launch. Not every target held still. When one moved, we re-planned and still landed close to what we’d committed. The reports above are what the hard days looked like. This loop is the rest of the calendar.

// next — The record is verifiable. The producer is available.
Get in touch →