Stockholm Syndrome with Your Build System
If you’ve ever sat in a standup and heard someone say “yeah, that stage is weird but it usually works” — and nobody blinked — keep reading.
There’s a moment when a broken pipeline stops feeling broken. When the workarounds become the workflow. When the team stops fighting the build and starts protecting it.
That’s not resilience. That’s Stockholm Syndrome.
Seven signs your studio has it.
Sign 1: “That’s Normal”
The build crashes at the cook stage every third run. Someone restarts it. Nobody files a ticket.
Someone on r/unrealengine described it perfectly: their Jenkins job would randomly fail on the shader compilation step. Maybe 1 in 4 runs. Everyone knew. Nobody fixed it. They just re-ran it.
This is the gateway sign. A failure becomes expected, and the moment it does, it stops being treated as a failure. It becomes weather. You don’t fix the rain. You bring an umbrella.
But builds aren’t weather. They’re infrastructure you built and you can change. Nobody investigates because the failure has won. The team plans around a broken system instead of fixing it.
The cost isn’t the five minutes to re-run. It’s the slow erosion of the belief that the build should work every time.
Sign 2: “Part of the Process”
Full builds take 90 minutes. Sometimes two hours. The team has adjusted.
Engineers batch their commits to avoid triggering multiple builds. Artists push at end of day and check results in the morning. The producer builds buffer time into every milestone because “builds are unpredictable.”
Nobody calls this a crisis because it didn’t happen overnight. Build times crept up — 45 minutes became an hour, an hour became 90 minutes, 90 minutes became “well, that’s just how long an Unreal build takes.”
It’s not how long an Unreal build takes. It’s how long your Unreal build takes on your pipeline with your configuration. And that’s a choice, even if it doesn’t feel like one.
Every hour of build time is an hour of iteration lost. Studios that ship polished games don’t do it because they’re more talented. They do it because their infrastructure lets them move faster.
Two-hour builds aren’t the process. They’re the bottleneck you’ve mistaken for the process.
Sign 3: “At Least It’s Consistent”
The pipeline fails the same way every time. Same stage, same error, same workaround. “At least we know what to expect.”
This is the most dangerous sign because it feels rational. You’ve mapped the failure modes. You have a playbook.
But a playbook for managing failures is not reliability. It’s damage control your team has gotten so good at, it looks like competence.
Sign 4: Nobody Touches the Pipeline
The Jenkinsfile is 3,000 lines of Groovy. It calls shell scripts that call other shell scripts that set environment variables that a third script reads. It works — mostly. And nobody will touch it.
When changing one stage can break three others, people stop making changes. That’s not stability. It’s fear.
Feature requests for the pipeline get deferred indefinitely. “We’ll fix that after launch.” Small improvements that would save hours per week never happen because the risk of breaking everything is too high. The pipeline becomes a museum piece. Don’t touch it. Don’t breathe near it. Definitely don’t upgrade.
Technical debt compounds this way. Not because people are lazy — because the system punishes anyone who tries to improve it.
Sign 5: You Have a Build Wizard
One person understands the pipeline. Maybe two. When that person is out sick, out on vacation, or in a meeting, pipeline issues wait.
You know who this person is. So does everyone else. They get Slacked at 7am on Saturday. They get pulled into meetings about build failures that have nothing to do with their actual job. They are simultaneously the most important person in the studio and the biggest single point of failure.
The wizard exists because generic CI requires so much custom scripting that only the author understands it. As one build engineer put it on Hacker News: “the tooling for automating builds really sucks. You have to jump through many hoops.” He couldn’t even separate build processes into discrete stages. The pipeline isn’t documented because it can’t be — it’s tribal knowledge held together by convention and muscle memory.
This isn’t a people problem. It’s a tooling problem. When CI doesn’t understand the build, someone has to teach it. That person becomes the wizard. And when the wizard leaves — for vacation, for another job, for a sick day — your studio’s ability to ship leaves with them.
Sign 6: Workarounds Have Workarounds
The pipeline can’t handle multi-platform builds reliably, so engineers build locally for each platform. But local builds need specific SDK versions, so there’s a shared document tracking which machine has which SDK. But the document is always out of date, so people Slack the Build Wizard to ask. But the Build Wizard is in a meeting, so people just guess and re-run if it fails.
Each individual workaround makes sense. It’s the accumulation that’s insane.
Signs of a workaround stack:
- A shared Google Drive folder for distributing 100GB builds because the pipeline can’t deploy them
- A Slack channel called #build-status where someone manually posts whether the nightly succeeded
- Local builds that engineers run “just to be safe” before committing
- A spreadsheet tracking which builds are valid and which need re-running
- A calendar invite blocking off time to “babysit the build”
None of these are solutions. They’re scar tissue — formed around failures the pipeline couldn’t handle. And now the scar tissue is load-bearing.
Sign 7: Build Discussions Dominate Team Meetings
You have a game to make. But your standups are about the build.
“The nightly failed again.” “Can someone check if the Windows build is still running?” “We need to re-run the console build before QA can test.”
At Ayelet Studio, we had standups where the first fifteen minutes were pipeline debugging. We were making Son of Thanjai — an action RPG — and instead of talking about combat feel or level pacing, three engineers were arguing about which Jenkins job to restart first. The producer was calculating milestone risk. The artists were quiet because they had no idea what any of it meant.
That was the week we stopped and counted. We had all seven signs. Every single one.
When the pipeline is the loudest voice in the room, the studio is serving it. Not the other way around.
The Score
Count how many you recognized.
1-2: You have normal pipeline friction. Worth improving, not urgent.
3-4: Your studio has adapted to a broken system. The workarounds are masking real costs.
5-7: Your pipeline is not serving your studio. Your studio is serving your pipeline. And if you’re being honest, you’ve known for a while.
Why This Persists
It’s not because your team is bad at DevOps. We had three co-founders with ten-plus years of enterprise software and DevOps experience each, and we still ended up with all seven signs. That’s the thing nobody wants to admit: experience doesn’t protect you. The tooling is the problem.
Jenkins, GitHub Actions, TeamCity — they were built for web applications. Small artifacts. Linear pipelines. Fast feedback loops. An Unreal build is none of those things. It’s a dependency graph with parallel stages, 100GB+ artifacts, shader compilation, cooking, multi-platform packaging. When you force that into a tool designed for web deploys, you get scripts. When the scripts break, you get workarounds. When the workarounds break, you get workarounds for workarounds.
Eventually, you get a team that has forgotten what “working” looks like.
This post doesn’t cover how to fix it. That’s a different conversation — and it depends on your project size, your team, your VCS, and a dozen other things I can’t know from here. What I can tell you is: the sunk cost argument (“we’ve spent months on this pipeline”) is the single biggest reason studios stay stuck. It feels rational. It’s not. Every week managing the pipeline is a week not spent on the game.
What the Other Side Looks Like
When the pipeline understands the build — reads the .uproject, knows the dependency graph, caches what can be cached, rebuilds only what changed — the symptoms disappear.
No wizard needed. Failures are precise — one step, one log, one commit. Artists see what happened to their assets without asking anyone. The producer checks a dashboard instead of a Slack channel.
The build stops being a topic of conversation.
“That’s Normal”
Normal is not the same as acceptable.
If you recognized three or more signs, your pipeline isn’t helping you ship a game. It’s teaching your team to work around its failures. And your team — because they’re good at their jobs — will get really, really good at working around it. That’s the trap.
The question isn’t whether you can live with it. You obviously can. You already are.
The question is what it’s costing you that you’ve stopped counting.
If you want to compare notes — abrahamk@speedrun.ci
Never miss a ue5-main update.
Get them delivered straight to your inbox.
