Interview with Kasper Mouritzen, Producer at CREY Games

Could you tell me more about your role? I had a conversation with Andrew Gomes, a project manager at Paradox Interactive. He told me that in every company, the responsibilities in certain roles may slightly differ, so I’d like to learn more about that. 

Kasper: My role requires focus on three P’s: People, Production, Planning. Through the role as producer, I try to collect various sources and funnel to the according setups, and make sure the road is clear and understood by the very experts who will help deliver great things. I help with setting team structures, personal development, delivery, setting deadlines, making sure tickets and development is rolling, explaining why we do what we do for specific feature development deliveries (gives good time for questions to bring to decision stakeholders etc.)

People: Among my critically important areas would be the health of individuals and teams. For this to be truly successful, trust is in most cases essential. To help develop and support, it often requires safe, open, and honest conversations. This is an interesting topic in the times of working from home and various hybrid setups. Some prefer ‘behind-the-screen’ without cam. Others need a face to face. As producer I don’t care what people prefer. If the room is safe and honest, it’s a good start. Whatever comes my way, I will prioritize to help people with. Easy mode is software, hardware, license, office supplies etc. The more difficult areas are dysfunctional teams or unhappy people. This is where the social skills of a producer become immensely important. Retrospectives are important to understand what can be improved moving forward. Sometimes a team might disperse after a delivery, and so a retro is also a good indication of what to bring forward to other teams elsewhere. But the rule of thumb is that there is not just one recipe fit for all. It is vital that you understand people, to truly create trust and understanding. I discuss team support and structure with other producers and production directors. And help pinpoint challenges and propose solutions to various scenarios.

Production: Having people understand ‘why’ is a powerful first step in setting up a shared understanding of the meaningful impact their work will result in. Whatever you use to run meetings, create tickets, share brainstorm sessions, show timeline overview, the producer will need to be on top of having it available to teams. Autonomous setups can be immensely strong. If the tools make sense for the people/teams and the objectives are clear, then it’s also about getting out of the way as a producer. Help support what is needed and check in at the planned times.

Planning: Understanding what to do after a ticket, when tomorrow arrives, when the delivery is out and shining, next quarter and so forth. Having a set vision and mission will help product development and prioritizing a lot. Building good backlogs with all stakeholders makes for good fundamentals. Understanding that objectives can be altered and/or removed is the harsh reality. But rather do it before going into development. If something changes mid-development, I will always, as producer, go to directors and ask why as it is fatiguing to work on things that might be trashed. Keeping morale high through solid clear road ahead is super important. So, defending the team from unforeseen changes helps plan in healthy frames.

‍

As you started as a community manager, could you tell me a bit about your path to becoming a producer? 

‍

Kasper: My producer role is shaped by the footsteps within the company. I joined the company when it was still a startup and pre live product. It has now reached scale-up. On a journey like that, for me not two weeks were alike in the beginning of the journey. I’ve been privileged in having had opportunities to try various roles and responsibilities. Having worked closely with all parts of development throughout a decade has, so far, been immensely inspiring. In this company, I’ve done social feat. Design, community management/team lead, PR, and now producer work. This means my knowledge of the product is tight, which has been a plus, when questioning expectations, deliveries and doing risk assessment. I am celebrating 10 years in the industry this year. I've worked closely with developers, designers, producers, directors, QA etc. across different studios. And in CREY, having been there since the beginning, I knew the product extremely well, and went through design and community responsibility to being a producer.

‍

What teams do you work with?

‍

Kasper: I've worked with feature development teams. So, if we needed to deliver a new feature or upgrade/update and existing, I helped do that.

‍

What does your daily routine look like? Do you have one?

‍

Kasper: Check Slack, Outlook, and anywhere I am tagged (message routine), go through JIRA updates and make sure all is on track and that any questions/comments will be picked up and answered or passed on if needed. Oh, and coffee and a good playlist is usually part of this. 

‍

Can you define a “typical team” or do you adjust the team's structure depending on the project they're working on?

‍

Kasper: I am not sure I can define a 'typical team', as I imagine this depends very much on the team structures tied to what works for the company and people in different places. But I think it should consist of the disciplines needed to deliver on whatever it might be. Having all devs. and designers present from the beginning, to make sure the alignment around the development steps is a big plus. This often means the high-level approach is covered by all experts who will be involved throughout the delivery. And this can save time with questions from different corners of the delivery. A team also needs to consist of people that can support each other in the disciplines they have.

Can you identify any soft-skill or character feature patterns that you use for structuring the teams you’re working with? E.g. mixing introverts with extroverts etc.

‍

Kasper: I think it is a big old bonus if someone in the team can translate tech. talk into something digestible for non-tech people. Sometimes the input and discussions benefit greatly from a shared understanding of different corners of development. It is for a good producer to identify the people within the team, to make sure there is a structure where people feel comfortable communicating with each other. Example: you don’t want a setup where a team doesn't feel safe talking with each other unless it’s at the weekly meeting or daily stand-up. A self-driven team with people who trust each other is an incredible force.

‍

If you had to point out one thing that, in your opinion, is crucial when it comes to structuring an effective team, what would that be?

‍

Kasper: Make sure people understand why we do what we do. Make sure it is meaningful for those who will execute on it. And if possible, make sure to share how users/customers/players react to it, to make sure the positive impact it brings is shown to the developers/teams. “What you’ve worked on is appreciated by so many people! Great work!” And then open the champagne and applaud if it was a tricky dev. cycle or falls under your celebration code of conduct 😊

‍

What are the key things that you look for when you’re hiring people, are there any specific character features that you look for? One of my favourite answers to this question was ”a willingness to try to understand why another group does things a different way, I think is vital to being able to join a team and integrate with the best practices that typically have evolved for good reason.” (Andrew Gomes quoted)

‍

Kasper: First off, it’s a bit old-school: People who took their time getting hands on with the product immediately stand out in a positive light. Someone who prepared thoughts around why they applied, is also a plus. I try to assess how I think they can fit in. People are complex. And social dynamics and culture is vital. Healthy culture growth through diversity and fresh eyes is a plus. It can really vary depending on the role being hired for. Will this person be the company face of for the community? In that case the person should be comfortable talking with all kinds of people (streamers, community members, interviewers etc.). Whereas a backend dev. might be uncomfortable with being streamed, but it doesn’t matter. So, depending on the role and responsibility there is no recipe that I think is truly reusable. Also: be nice!

‍

What are your core ideas for improving both team's efficiency and morale?

‍

Kasper: Listen and react to what the teams say. You don't want to impose your book theory practice or previous experience to everyone without running a healthy check-in on how things are going retro/postmortem). Teams are people. People are different. Set an environment where you do not become a bottleneck for communication and greenlighting of e.g., meetings between devs. But make sure there is a transparent area of responsibilities and understanding of autonomous self-driven culture. All this requires strong trust, communication, and agreement. Trust the people who will do the magic and never ever micromanage(!).

‍