Building and Maintaining the Right Studio Culture

The folks at Casual Connect were awesome enough to make all of this year’s Seattle conference lectures freely available online. My talk was called building and maintaining the right studio culture. Check it out!

273 Responses to Building and Maintaining the Right Studio Culture

  1. Really great talk, thanks! I can see where bonuses are bad, but a situation ( especially applicable to game companies ) where they are good is where the company works on milestone payments and that’s the easiest way ( financially ) to compensate employees for meeting deadlines. To be honest, i prefer the concept of higher general compensation, but sometimes finances won’t allow.

  2. This explains the past few years of my life, and hopefully the next few years as well. I’ve lived the majority of this spectrum, except for the Engineering mean.

  3. Very informative lecture, as always. And congrats on starting Spritebox!

  4. “Spry Fox”. Blog post to come on that subject shortly. And thanks! :-)

  5. Ahhh, sorry for mishearing it. When a blank, more-to-come-soon type of page greeted me at spritebox.com, I assumed I got the right name!

    Well, either way, congratulations on the company, and I’ll save my questions for when you’re in Toronto for IN 2010.

  6. Jacek Wesołowski

    Great talk! I’ve been looking forward to hearing this ever since I read a Gamasutra report on a similar lecture you gave on a different occasion. A few questions, if I may:

    How does one tell the difference between an Autocratic company and a (say) Star company gone wrong? Is an Autocracy merely a Star company where the top star is a “bad apple”, or can you create an Autocracy deliberately? It strikes me that even militaries and such, with all that strict hierarchy and discipline of theirs, are still more like Star or Bureaucracy cultures, i.e. a colonel won’t give direct orders to privates, while exceptional individual performance (a.k.a. heroism) is generally held in high regard.

    I used to work for two companies I wouldn’t hesitate to call autocratic, but they only had two things in common: that people were promoted based on their willingness to maintain the status quo (they were NOT required to be particularly “loyal” or competent, for example), and that their projects were unstable due to frequent random changes imposed by the top bully. Other than that, they were two opposites, for instance one put emphasis on minimising ETAs, while the other put emphasis on technical excellence. One had several intermediate layers of hierarchy, while the other had only one, even though the development team was similar in size.

    Do you think it’s possible to marry Star and Commitment archetypes succesfully? On one hand, they seem to be mutually exclusive in that you can’t have a star without giving them broad agency, but nothing seems to strangle the sense of being in a family as quickly as the chain of command does. On the other hand, both archetypes have something important to offer.

    The Star culture gives a chance to one’s focused vision (which may or may not be brilliant, but that’s the risk one’s taking with this scheme). Brilliant ideas tend to seem crazy until they suddenly become obvious, so implementing them requires a certain amount of “blind” trust. But the Commitment culture seems perfect for sharing insight between specialists from different disciplines. I think this ability is extremely important in a medium where programmers, designers, writers, graphic artists, and musicians need to work hand in hand.

    Conversely, it seems that Star cultures only give you the incentive to excel among your equals, rather than reaching out to non-programmers, non-artists, non-designers etc. At the same time, any consensus driven development seems vulnerable to design-by-committee, which is very efficient at killing less-than-obvious solutions to complex problems.

    Lastly, one of key takeaways from your lecture is that changing company culture is extremely difficult at best. But are there any methods that at least give you a chance of success? I’m asking this because, as a designer, I’m often confronted with team cultures that don’t regard game design as an informed art. That is, they don’t acknowledge that game design involves technical skill and knowledge, nor do they acknowledge the interplay between interactivity, presentation and the underlying technology.

    In a sense, design is magic to them. Even on a rare occasion when the team considers me their resident wizard (rather than keeping all the “fun” decisions to themselves), I still have huge trouble convincing them that succesful design requires things like prototyping, playtesting, or even asset creation. In other words, the cultures of companies I’ve worked with so far have been consistently know-how resistant. How can one potentially try and change that?

  7. > can you create an Autocracy deliberately?

    There are people who want to hire employees who simply do what they are told, and who don’t care whether their employees are attached to their work or to the company itself, as long as the employees get the job done (out of desire for payment.) Such people are likely to found autocracies.

    > Do you think it’s possible to marry Star and Commitment archetypes succesfully?

    Nope.

    > one of key takeaways from your lecture is that changing company culture is extremely
    > difficult at best. But are there any methods that at least give you a chance of success?

    Start a subsidiary (i.e. a new studio) in a completely different location with a completely new team. ;-)

    (I’m being mostly serious. I’m sure there are ways to gradually move a company’s culture in a more positive direction, but I’m not personally acquainted with those techniques and on a personal note, I don’t see the point in working for a company whose culture I don’t like, knowing as I do that changing the culture is so difficult.)

    > I still have huge trouble convincing them that succesful design requires
    > things like prototyping, playtesting, or even asset creation.

    IMO, the way you convince people of the value of prototyping, playtesting, etc, is by demonstrating the value. It takes at least one executive sponsor who has the wisdom to support you and the mojo to defend you as you adopt a more productive development methodology, and it takes a team of people around you who are open to change. It does not necessarily require the entire organization to undergo a major cultural shift (though it might, in some companies.)

    In other words, this may be less of a cultural issue and more of an educational one, if you’re lucky. Analogy: if I’m using a rock to pound nails into two by fours, you’re not changing my deeply-ingrained cultural beliefs by teaching me to use a hammer! I’m still pounding the nails into two-by-fours for the same reason (i.e. I need the money), and I’m still managed the same way (i.e., told what to do by my autocratic boss) but now I’m more efficient and my hands don’t hurt as much. ;-)

  8. Jacek Wesołowski

    The reason why I’m inclined not to give up on existing team cultures is pragmatic, namely: my quitting jobs I didn’t like has led to me literally running out of employers in my area of residence. I’m probably going to need to move abroad at some point. Also, I guess my CV must be screaming “bad apple” by now. Nobody wants improvers, only adapters, so I’m looking for ways to become a more adaptive person without throwing the baby out with the bath water. :-)

    I agree that new methodology or technology does not automatically equal new culture, but I think it also depends on the scale of change. A hammer is, in a sense, a rock with a handle attached to it. It’s a rock 2.0 – an incremental change. But a switch from manual labour to automated factories is a revolutionary one – it’s a new quality (hence luddites, labour unions, rapid urbanisation and all that 19th century stuff). Similarly, the spiral software development model can be seen as incremental improvement over greenlighting, but switching from waterfall to Scrum is a major shift of paradigm.

    A real-life example. One of my employers was a company that didn’t believe in hierarchy. In particular, producers were considered the root of all evil. Consequently, there were no leads or producers in a team of thirty, except for the studio head. The studio head had a final say on everything, but in general the members of the team were supposed to make decisions between each other.

    One of my first tasks was to balance the two weapons and three enemies that already existed in playable form. Technically, this involves adjusting parameters, such as rate of fire, damage per hit, enemies’ hit points etc. The technical problem I encountered was that my changes were being overridden by level designers who thought different parameters fit their levels better, and programmers who thought different parameters would be more cool. The result was that different parts of game used different, local setups. My balancing of features wouldn’t show in the game proper (as opposed to proofs of concept), because no part of the game actually used my setup.

    The team made most decisions through brainstorming. Basically, if you wanted a bunch of people to arrive at a common solution, you had to brainstorm with them. Any individual brainstorm session was fine in itself, but the results of several sessions were not consistent between each other. Also, team members who didn’t agree with my opinion on how the game should be balanced, instigated brainstorm sessions while I was away, rather than talking to me. The results would override previous agreements, and I wouldn’t even know that a brainstorm session occurred until I checked configuration files on the following day.

    I believe it was mostly a technical problem of insufficient communication. The team had no memory. My proposed solution was to create a new rule: “we generally stick to decisions we’ve made before” (of course, there would need to be some kind of revision process etc.).

    The problem is that, in order to stick with a decision, you need to know what the decision is. So either you need to be able to recall it, or you need someone or something to remind you. Someone would have to keep track of decisions. But that’s pretty much what a lead or manager does, sans the right to say “oh, you can’t do that”. There was a technical problem, but the solution would affect the team culture.

    It got rejected, of course.

  9. This video has been an eye opener. I have never though about this subjects in the way they are presented here. This level of abstraction surely helps to focus better.

    Thanks for sharing! Adding this blog to reader right now.

  10. I have watched this twice now. I have worked in or contracted for all of the company types you mentioned and can affirm that your insights are very accurate. I am currently trying to establish a very small (3-5 person) commitment modeled company for mobile edutainment applications. Can you recommend any additional resources or reading materials on how to establish a business structure and managing style based on a “commitment” model? I am specifically interested in more real-life examples of how these ‘commitment’ styled companies operate.

    Thanks in advance!

  11. Hey Carl — most of the material I have on this comes in the form of articles that were combined into a custom packet that I received at MIT. I don’t know what good books and/or articles there are that are readily available. Sorry about that. :-/

Leave a Reply