This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.
I’ve been working for a few months now with a new team in a part of the industry that’s completely new to me. I keep thinking back to a post I read a while ago by Owen Mahoney about the 4 industries of video games. My hands-on experience is confirming that the different worlds Mahoney identifies really are different.
Communication is genuinely different
In mobile f2p, as a designer I always have to justify everything with KPIs and metrics — that’s just the deal. In the PC/Console world, though, that kind of thing is generally frowned upon. These are games far more grounded in the creators’ personal taste, which brings another consequence with it: to avoid too much noise and keep the development process from getting muddy, people very often don’t communicate properly. You work in isolation, and you have to trust your teammates completely.
My previous professional experience pushed me to look for solutions to this problem, but I was stopped almost at the first attempt. I took it pretty badly at first — I’ll admit I felt almost useless in that context. But then something shifted: as a designer I don’t have to justify every single thing with numbers, and that is genuinely an improvement.
So all I’m left with is complete trust in my fellow travellers — but one fundamental problem remains: the feeling of being lost. Sharing is limited, documentation is all over the place, and it’s easy to feel disconnected from the bigger picture.
How I’m tackling this challenge
My years of experience, even if not directly in high-end games, are still there, and I’m adopting some techniques to get my bearings. Fair warning: they’re not for everyone — not everyone can make themselves vulnerable and risk coming across as the person who doesn’t know what they’re doing. But for me, the goal (my personal and professional growth, and my connection with the team) outweighs any bruised ego.
The first technique, which I call probing, is to keep putting proposals to the team. I structure them properly, make the best case I can, and table them in a meeting with everyone present. The typical response is that it can’t be done that way, that it’s always been done differently, that the game is not what I’m imagining. And that’s exactly what I’m after: the designers who know the product better than I do finally start sharing what they know. Sometimes they even argue amongst themselves — I just sit there and listen, taking it all in.
The second technique I use is reverse-engineering assets and commits. Following comments and discussions in the code helps me really understand what everyone is actually trying to achieve.
The third technique is mapping the team’s knowledge holders. Domain experts, and sometimes short one-to-one chats to concretely understand how something works. The trick there is to go in with an idea already formed, then ask for confirmation. Something interesting always comes out of it.
Finally, the last thing I spend time on is being a bit of a documentation archaeologist. The information is fragmented and often contradictory, but it’s still something. My goal is always to track down documentation written for external partners, because that’s usually where you’ll find the clearest articulation of the vision.
Change isn’t easy, but it makes you richer
Sometimes I have to sit with feelings of helplessness and incompetence — but for me, that’s exactly where the real personal, spiritual, and professional growth lives. I hope this post can be useful to anyone who finds themselves in the same situation, or something like it.
It’s also really important to make yourself useful: pick up simple tasks that nobody wants to do, so the team understands you’re there to help, not to act as a consultant. There’s a bias against people who come from mobile, like me — no point pretending otherwise. The only way I know to push back against it is to roll your sleeves up and get on with it.
