Details
Team Size: 18 + 10 contrators
Genre: 3D Platformer
Role: Project Lead & Producer
Engine: Unreal Engine 5.4
Tools Used: Jira, Confluence
Google Suite, SharePoint, Perforce,
and Jenkins & Agile Methodologies
My Responsibilities as a Project Lead
Pipeline & Tools
Built a custom Excel prioritization tool for art assets using the task’s description and production status, improving execution efficiency by 35%.
Created a clearer “What’s next” queue for the artists to reduce lost time on checking priorities and stating the ownership.
Team Culture
Introduced an anonymous feedback system and facilitated open dialogue to resolve interpersonal friction and strengthen team morale.
Turned feedback into concrete working agreements, like communication norms and escalation path.
Playtesting
Ran A/B playtest scenarios to evaluate task clarity + camera positioning, increasing first-play completion by 20%
Created standards for documenting findings and converted them into actionable changes.
Design Creation
Co-authored the Game Design Document, aligning creative vision with implementable details.
Designed 2 of 4 core mechanics and many smaller ones, supporting clear implementation and consistent player experience.
Experience and Postmortem
What I’ve Learned
I learned fast that leading a team isn’t just about schedules and tasks.
This project was my first experience working in a mid-size team, and honestly, it went about how a first project should go: a lot of progress, a few bumps, and a ton of learning.
It was also my first time leading a team with different roles and skill sets. Going in, I didn’t really know how to work in an Agile environment, how to use tracking tools well, or how to think ahead about dependencies. And I definitely wasn’t ready for how much of the job is noticing interpersonal issues early and helping resolve them before they turn into bigger problems.
On top of that, it was my first time working with so many Americans on one team, which was a bit of a cultural shock for me as someone from Russia — but it pushed me to get better at reading the room, communicating clearly, and checking in more often instead of assuming everything is fine.
1. Agile is the key
A producer should always be prepared for change.
I wasn’t ready to be “Agile.” Honestly, at that point, I didn’t even fully understand what Agile meant in a real development environment. All my previous experience was with small teams and short projects, so going into a 6-month production, I didn’t really know what to expect.
The biggest lesson was how quickly one missing piece can block everyone else. If a mechanic isn’t in, a level designer can’t properly test the level they built around it. Back then, I wasn’t ready to step in and say, “Let’s postpone this section,” or “Build an alternate route that doesn’t rely on that mechanic yet,” so progress kept getting stuck behind missing dependencies.
I also didn’t realize how important it is to define mechanics early — or cut them — so they don’t quietly transform into schedule killers that drag everything else with them.
In short, I didn’t know how to adjust plans on the fly. Now I get that being Agile isn’t a buzzword—it’s a survival skill.
2. Tracking tools
A producer should always have a clear way to see change.
Before this project, tools like Jira, Monday, Trello, Asana, ClickUp, and HackNPlan meant nothing to me. They were just weird names. Once we got into real production, I realized they’re basically the backbone of staying on track — keeping the deadline visible, making ownership clear, and giving the team a shared source of truth.
More importantly, tracking tools make progress (and problems) measurable. They helped me see what was actually moving, what was blocked, and where we kept losing time—so we could adjust, improve, and not rely on “I think we’re fine.”
3. Interpersonal problems
A producer should be able to negotiate the problems, not just track them.
Our team was made up of young, not-so-experienced people who were genuinely eager to release a game. The issue was that we didn’t share the same definition of what “release” even meant. For some people, releasing a game meant getting something out the door. For others, it meant putting in thousands of hours, polishing every detail, and treating the project like it was personal. And yeah — we had both extremes on the same team.
That gap created a lot of friction: differences in feedback, communication styles, expectations around progress, and overall work ethic. At the time, I wasn’t prepared to manage that many different personalities, and I didn’t catch the root causes early. I let problems sit for too long, and over the course of the project, they piled up until things started breaking in bigger ways.
4. Learning the Unspoken Rules
Same words, different meanings.
When I first started working in the U.S., I underestimated how different workplace communication norms can be across cultures. In many American teams, concerns are often shared indirectly or saved for the “right time” to avoid tension. In contrast, in Russian teams, issues tend to surface earlier and more directly, which makes it easier to catch misalignment before it piles up.
In this case, a few points of confusion, caused by a mix of language and cultural context, were not raised until late in the process. Because that feedback came near the end of the project, we had very little runway to adjust, and the result was a release that never reached the level of polish we wanted.
Over time, I’ve learned that cross-cultural collaboration works best when you set the communication rules early. Define how and when people should raise concerns, confirm understanding more often, and make it safe to surface risks without worrying about how it will come across. People operate within boundaries shaped by the norms they grew up with, so aligning on how we communicate matters as much as the work itself.