Production Patch Notes: 15 Years of Figuring it Out

HISTORY

» What did your workflow really look like back when the team was still tiny?

Back in the day, the dev loop was dead simple. A single “task” could mean building an entire scene from scratch: narrative, animation, programming, and other disciplines. When you finish your part, then you toss the “hot potato” to the next person so they can do theirs. To be fair, though: it was a very different scale of production compared to where we are today. Projects were smaller, and so were the teams. When you’ve only got five or six people working on the project, you don’t need complex PM tools or corporate bureaucracy to get work done.

Even so, MHG knew that “winging it” wouldn’t scale forever, and always aimed to have a tool that helps teams track what needs to be done. My first job was to level up our production discipline: to have better reporting, more visibility through the tools, and stronger predictability in planning and delivery.
We’ve been through a whole gauntlet of platforms trying to find the perfect fit, too. Over time, we evolved through several different tools: ActiveCollab, moved to Targetprocess, took a turn with Jira, flirted with ClickUp, and eventually back to Jira again.

» What’s something that passed for a “process” back then that would be unthinkable to do now?

There was this one ritual we swore we’d absolutely never repeat. 🙂

Ritual itself wasn’t evil, of course, and it did get us to the finish line. At the time it was our only real weapon against timelines and budgets. The ritual? Every single Friday, we had a deal to ship a build. No exceptions. It had to be playable, completely free of game-breaking blockers, and actually deliver the exact value we committed to that week.

Unfortunately, this became a more than often a reason for sleepover at the studio. Anyhow, that weekly grind forced us to realize the Friday chaos was just a symptom of a deeper problem. The real issues were systemic: how we planned our weekly tasks, managed scope, hit milestones, tracked progress, and approached build stabilization in the first place.

EVOLUTION

» What’s the first thing that falls apart on the production side when a team starts growing fast?

A ton of things can go sideways when you try to grow, but velocity (how much work a team successfully completes during a specific time period) is the first and most obvious casualty.

Your output is going to take a hit no matter how much you prepare to scale, but without a solid plan, it will be an absolute disaster. When new people show up, your core dev team has to stop what they’re doing to onboard them. Suddenly, you’re stressing over keeping everyone busy, making sure nobody is sitting idle, and you catch yourself micromanaging individual tasks and team members rather than focusing on the actual game.

In the end, you look around and realize the velocity of your massive new team is actually slower than when you were just a tight crew a fraction of the size.

As you can see, we’ve learned the hard way that before we add a single person to the squad, our processes and pipelines need to be absolutely rock solid. This is no walk in the park: it takes a ton of heavy lifting to build workflows that are both efficient and sustainable, and you have to know exactly what a new hire brings to the table, making sure they actually level up the team instead of just throwing off your rhythm.

» What’s something you tried that seemed like it would work but didn’t – and why?

To this day, I still wonder if anything actually works. 🙂

Over the last 15 years, we’ve tried a lot: from textbook industry “best practices” to custom workflows we built from scratch. It’s not that they completely failed, it’s just that they usually only worked halfway. But you stick with it anyway, keep pushing, try to optimize, and just end up spinning your wheels in circles.

Early on, we thought we cracked the code by mapping out clear development phases for our features or system solutions – version 1, version 2, version 3 etc. In theory, it sounded perfect: you define exactly what V1, V2, and V3 should look like, so you know exactly how many steps it takes to reach the final product.

But in practice, figuring out what actually belongs in a V1 is insanely hard. What’s even harder is to make sure that the V1 answers the right questions during the early development phase. It turns out you aren’t really building a neat, predictable version 1, you’re just iterating. And honestly, you have no clue how many iterations it’s going to take until you’re deep enough in the weeds to finally figure out the next step.

»The industry moves fast, and new technologies are changing what “keeping up” even means. How do you decide when it’s the right moment to adopt something new – and when it’s smarter to wait?

When it comes to our tech stack, we don’t just blindly chase the shiny new thing. We are incredibly cautious, every update has to run through a strict evaluation so we can map out the exact impact, the integration cost, and the potential risks. Only then do we decide if (and when) we’re actually going to pull the trigger on something.

Production practices, though, are a whole different story. Game dev is inherently chaotic, so we can’t just copy-paste textbook “best practices” or trendy management frameworks and expect them to magically work. They rarely fit our actual reality. While we absolutely keep an eye on the market, our real breakthroughs are always custom-built. We find them by constantly experimenting, tracking the data, and ruthlessly tuning our workflows to stay as efficient as possible.

THE PROCESS

» Has there ever been a moment where you felt the process was getting in the way of the work? How did you course-correct?

Of course those moments happen. The process is supposed to serve the team and the product, providing the structure you need to quickly spot what’s broken, what works, and what needs tuning. Without that, you’ll slide into chaos and ad-hoc development real fast, and you’ll just end up running around trying to put out a million different fires, but you won’t actually extinguish a single one.

That said, treating the process like a rigid, binary rulebook is just as big of a trap. It’s not about cutting corners or skipping steps, but you have to understand the actual why behind the workflow. You need to know when to break script and play a situation differently just to keep the team moving forward.

» What’s a tool the team loves using vs. one they tolerate but nobody’s excited about?

We have a dead simple philosophy: tools should work for you, not the other way around. We refuse to do extra chores just to please a piece of software.

The bottom line is always whether the team feels a tool actually helps them or if it’s just extra homework. If it’s the latter, they’re going to resist it, no matter what software you throw at them. It also comes down to mindset: do you actually want structure and clarity, or do you prefer a loose, informal way of working?

In our experience, tools with great UX that actually support creative work always get the best reception. Miro is a perfect example of this – the team genuinely loves using it because it helps them visualize their ideas in a super simple, engaging way. On the other hand, you always see pushback with a tool like Jira, mostly because of the clunky UX and just the nature of the software itself.

» How do you get a team to actually adopt a new process or tool? What works and what doesn’t?

There is no one-size-fits-all playbook here, it entirely depends on the situation. We always explicitly explain why we are changing things up or bringing in something new. If people actually understand the problem and the reasoning behind the change, the chances of total buy-in skyrocket. Every single initiative comes with a clear rollout plan shared with the team, followed by the actual upkeep needed to ensure the new workflow.

And of course we’ve had new practices completely tank on the first try. Some processes demand serious heavy lifting and stamina that the production team just doesn’t have at that exact moment, so we end up having to loop back and try deploying it multiple times.

At the end of the day, whether a new process, practice, or tool actually sticks depends heavily on whether the team recognizes the actual need for it, clear communication, and the production crew having the determination and focus to see the implementation through to the finish line and keep it alive.

» What’s the one tool or system change that had the biggest positive impact on how the team actually works day to day?

From where I’m sitting, the real game-changer for us was actually introducing and locking down clear production pipelines. That gave us total clarity on the specific steps the team needs to take to hit our milestones. We know exactly what development stage we’re in, and we can instantly spot the blockers we need to clear so the next phase can unlock and get moving.

LEARNINGS

» What’s a widely accepted best practice in production management that you’re actually skeptical of?

First up is the Sprint. In my experience, the textbook version of this practice simply doesn’t work in a game dev environment. It’s very rare that you’ll get a measurable increment, or a standalone feature in every sprint. Work is constantly interdependent across different disciplines, and features, experiences, and systems take months to bake. At MHG, we use the sprint just as a timebox and a planning tool.

The second thing is the Retrospective. Even though I think the concept itself is incredibly valuable, we just couldn’t maintain consistency and commitment in practice. The culprits are always production dynamics and deadlines. So, we shifted our focus to solving problems the exact moment they’re identified. The second we spot an issue, we work on fixing it, and we always aim to solve it systemically, rather than a temporary band-aid.

» If someone is just starting out, what’s the one production decision they absolutely have to get right from day one?

If you’ve got absolutely zero experience, my advice is to find a back door into the industry. I’m not saying don’t be ambitious – you should be. But you need a serious reality check on what you can actually pull off right now. Build something that actually matches your current skillset.

Do not try to make your ultimate dream game right out of the gate. Start with a game you are 100% sure you can actually finish. Trust me, shipping anything is way harder than it looks. That’s the only way you’ll ever learn how games actually get made. It’s how you learn to make tough choices, figure out what matters, prioritize under pressure, kill bugs and eventually figure out how to bring the right people on board.

» Is there something you’d still like to change about how we work – a problem no tool has solved for us yet?

There’s always room to optimize how we work, no matter what tools or processes we’re running.

Right now, the area we really need to level up is how we define milestone deliverables. We need to kill the guesswork and minimize different interpretations of goals. The whole squad needs to be clearly aligned on what the final output actually looks like, what we’re gunning for, and have every single dependency mapped out clear as day.

You can never truly finish or perfect a production process. It’s a constant loop of updates, patches, and hotfixes. We’ve gone through many sleepless nights, and almost 70 projects later – the team is still moving forward, and we are still trying to be better than yesterday. As we continue to spiral into the future, we’re focused on achieving more clarity, streamlining our milestones, and making sure our tools are always working for us, never the other way around.

Here’s to 15 years of figuring it out and always finding a way to ship 🥂