Skip to content


How not defining responsibility can sink a great studio.

Rami Ismail
Rami Ismail
4 min read
Photo by Sigmund / Unsplash

A few years ago I was called into a 10-person indie studio in one of the countries I used to visit frequently to help them resolve an issue: they had made a great game, they had made an unexpected amount of money for their needs, they had even hired a few new people throughout. Yet, despite what might seem like a very successful start of a studio, now everything was falling apart.

Like many indie studios, this team had started their career as a group of students working on a game jam project together. The team worked in harmony - their goals were aligned, their responsibilities were clear, and the project was well-defined. The game ended up a clever and soulful project, and it performed beyond any of the students’ wildest dreams. Both critically and financially, they had achieved success - and it seemed clear that a bright future lay ahead for the jovial scrappy-students-turned-studio.

They said it was “not quite a fight” yet, but it was not quite clear to me what separated the situation from being a fight either.

Almost a year later, I would be sitting under the air-conditioning in their once-cozy office as tensions had run high among the team. A seemingly irreconcilable rift had appeared between three small but equally-sized factions in the once-harmonious team, as they argued about what the next game should be. They said it was “not quite a fight” yet, but as I listened to them it was not quite clear to me what separated the situation from being a fight either.

I took every single person on the team apart and had a conversation with them to figure out what their goals and worries were. Despite a bit of a language barrier, it was clear that the goals of the three factions had become misaligned: one group aimed to make a direct sequel to their hit game, one group aimed to create a very different project to prove their creativity and versatility, and one group wanted to grow the studio and aim for a far higher production quality bar. More importantly: that the trust between the team had diminished significantly.

There were two immediate issues to resolve: the stalemate was the obvious one, but the diminished trust was far more critical. They had tried to resolve the stalemate through all sorts of voting systems, but every exercise would end in an argument and a return to the stalemate. Every time the team had gone through this cycle over several months of stalled progress and arguments, the trust had eroded a little further.

Ultimately, there was little I could do to save the full team. When I was done, the team had agreed to assigning one person creative director responsibilities, one person a studio manager position, and one person a producer position. Each of them had negotiated the power to use a tiebreaker vote if a vote relative to their new position got stuck for an extended period of time, and then worked with the team to define boundaries, responsibility, and processes.

I had already flown on to my next destination when I got a message from the new creative director. They had discussed with the studio manager and the producer, and they had made a final call on what project to work on next. One person left the team in protest, and another would leave the studio somewhat later during the development of that next project - a project they simply did not care for. The team grew a bit to compensate, and have remained stable since.

The next project wasn’t nearly as big as their original jam game was, but it kept the studio afloat, and the team restored their sense of trust. Having clear responsibilities and processes helped in ensuring that people understand how decisions get made, and a pre-defined and agreed upon process makes it feel more fair when difficult situations have to be resolved.

I realized that at Vlambeer, the biggest invisible power we had was a clear delineation of responsibility and accountability, a growing trust in each others' ability, and processes for conflict resolution defined prior to the conflict. This happened naturally at the founding of the studio, as we were clear what our expertises were - my co-founder held sole veto-power over design, and I did over marketing and business.

It can be easy to forget when you're an indie struggling to make games while staying afloat, but a majority of really difficult problems at games studios aren't technical problems or design problems, or even financial problems, but people problems - issues of motivation, ownership, accountability, communication, alignment, boundaries, and trust - so ensure that you design the human structure of your studio with the same level of care that you would design your dream game.


  • Evaluate the processes in your team or studio: are their any decision-making processes that could end in a draw? Is there an agreement on how to resolve such a situation? It can help to imagine professional conflicts that aren't there -worst case scenarios- between teams or disciplines.
  • If you're larger than a few people, look at exercises like a RACI chart - which is technically severe overkill for small teams, but can still be a useful exercise as your team grows if you can't get the conversation going otherwise. I have done RACI charts (or variations thereof) with teams as small as four people. Visualising this can help you see which roles might be over-tasked, underutilized, or otherwise unfairly burdened.
  • If you have not, codify these responsibilities and processes in a way that allow you to unambiguously refer to when the need arises. If not, sit down with your entire decision-making team, and start codifying who decides what, how, and when while you all still like each other: when conflict arises, any attempt at creating conflict resolution processes will be filtered through the lens of that existing conflict - very few people will agree to a rule that makes them lose the current conflict even if it is clearly the right choice. There is no right way of doing this: whether you write a document, enshrine it into your founding contract (you do have a founding contract, right?), or make a fancy matrix or flowchart - whatever works for your team works best.

Rami Ismail Twitter

Gamedev. Exec.Director of & creator of presskit(). Speaker, consultant, helps devs globally. 33% of the The Habibis podcast. Traveler. Was 50% of Vlambeer. He/Him. Muslim. Dutch/Egyptian


Related Posts

One Way Doors

A lot of studios spend years making a bad version of a good idea - until they go and figure things out. It's not because their ideas or team are bad - it's because their development process does not have One Way Doors.

One Way Doors


In my consultancy I've received quite a few questions about how to set up your milestones for an optimal development cycle. Very frequently, these questions come from young producers, or producers moving into the games space from other industries - who are often taken aback by how different


Prototypes & Vertical Slice

Most indies mix up the purpose of the Prototype and the Vertical Slice, and lose out on a lot of time and money in doing so.

Prototypes & Vertical Slice