Posts Tagged ‘management’

GDC Online: How to create a diverse team and keep it


Donald Harris and Sheri Graner Ray hosted a round table on my last day at GDC Online about diversity in game studios.

Why I Went

The topic sounded interesting to me – diversity in my mind was a given as I have seen the power of mixing people from different backgrounds within the talent melting pot of Lionhead Studios.  Encouraging retention in particular was interesting to me, as people sometimes do not just leave a studio but the entire game industry itself.  I believe some of those leaving would have chosen to stay if there was a better work-life balance; e.g. improved working practices that supported fathers and mothers spending time with their children, rather than have them routinely spending extra hours at the office.  Those reading this blog entry interested in overtime practices and their impact on the workplace should review DeMarco(1999) and Keith(2010), as this topic was not discussed in depth at this round table.

First Impression

The round table discussion started with Donald asking everyone to introduce themselves and to explain what they wanted from the hour.  Diversity was understood by the room in two ways, genetic and skill.  Despite the room being mostly white and male, the entire room did declare interest in diversity in both regards.


The first question after introductions was “why would you want diverse teams?”

Diversity in skills was briefly addressed, with some questioning the value of mixed discipline teams.  Questions about improving communication between artists and coders were asked but never really answered.  The meeting was steered back to people with diverse skills rather than mixed discipline teams.

Personally I can see the value of mixed discipline teams as suggested by some in the industry including Keith (2010 pg.160-161); but in larger studios these disciplines do seem to be organized in to single discipline departments.  The different terminology and ways of communicating between disciplines does make people who can communicate easily with each very useful.

Interestingly during career track talks on Friday this kind of generalist attitude seemed to be under-valued, as graduates were being repeatedly encouraged to be more specialized.  I do wonder if the message of specialization given through career advice both before and after entering the industry could be creating deeper communication silos, thus hindering integration of disciplines in to cohesive cross-discipline teams.

Donald made the point that a modern game set in a city made by a diverse team would be inherently more believable because of the combined cultural knowledge of a diverse team.

Sheri steered the room towards recruitment ideals, clarifying the “how to create a diverse team” part of the title into “where to source skilled diverse people from”.  A side point here quickly resolved is that hiring an under-qualified candidate from a under-represented type of person is counter-productive.  Fulfilling corporate targets based on genetics rather than required skill builds weaker teams and breeds contempt.  The room declared the door was open to candidates with the right skills from diverse backgrounds, but sourcing those people can be difficult.

A grass roots suggestion about working with schools to encourage more diverse candidates interested in developing skills useful to the game industry was quickly discussed but ultimately the room was steered back towards addressing more immediate recruitment.

Places suggested included:

  • College campus
    • Talk to instructors directly, ask for interns
  • IGDA diversity groups
    • Cannot directly advertise, but there are networking opportunities
  • Mod Community
  • Linked in
  • Different types of colleges and universities
    • Architecture School
      • Level designers
    • Art School
    • Business School
  • International candidates
    • Localization & bring knowledge about their own culture
  • Community and customer management candidates
    • Starbucks, PapaJohns, etc
      • Received good customer service while serving studio,  worthwhile interview to represent studio.
    • Customer base
      • Passionate about product, though can be double edged sword
  • Game forums
    • Fans can be recruited in to community management
  • Poaching from other studios
  • Poaching talent from other industries

At one point I did suggest to the room that if working practices were to be improved that mothers and those physically unable to work a full day could be an untapped source of talent, especially if they could job share.

Behavior interview techniques were mentioned, with a split about whether the practice of letting every member of the team spend a few minutes with a candidate being interviewed was good or not.  DeMarco (1999) also advocated using a similar technique.  It was suggested that perhaps this practice is better for smaller teams, though some said that it worked with larger ones too.  An objective set of criteria for questions to be asked by the team if a team interview is done was agreed to be crucial for the practice to be effective.


In the closing minutes the elephant in the room was the word “diversity” itself.  It is a big word that can be quite confrontational (“You’re not diverse… you are BAD people!”).  Someone else said “I hear diversity, I think of lawyers”.  Corporate diversity training was spoken of briefly – some found it comforting, others thought it was just a box ticking exercise providing some kind of metric proving to someone somewhere that a company was diverse.

I found the round table discussion interesting though not quite what I expected  – it focused on recruitment rather than team cohesion and retention.  It was comforting to hear that my experiences working within a diverse team in Lionhead are repeated in studios elsewhere.  From my experience, Lionhead has recruited from many sources. My own recruitment into the studio was from a different industry – I used to create software for libraries and learning centers!  It was good to hear that many other studios also have open minds when it comes to recruiting from different pools and developing talent.


Donald Harris :

Sheri Graner Ray:

Keith, Clinton. (2010).  Agile Game Development With Scrum. Pearson Education, Inc. Amazon UK, Amazon US.

DeMarco, Tom. & Lister, Timothy.  (1999).  Peopleware: Productive Projects and Teams.  Dorset House Publishing Co., Inc.  Amazon UK, Amazon US.

Podcasts – a great way to absorb extra info


Podcasts are audio recordings usually in mp3 format that often specialise in a particular niche.  If you commute, work out to music, or are at a loose end during a long build you might consider listening to one of these shows.

I subscribe to quite a few podcasts via google reader (my rss client of choice) – though the term podcast itself has iPod heritage so iTunes is also often used as a delivery mechanism.

I have listed a few of my favourite podcasts below.  Please comment and recommend any podcasts you listen too that I might be missing out on. 🙂

Game & Software Development

Industry Broadcast This is an excellent idea; the best game developer blog articles read out for your convenience
Platform Biased Behind the scenes info from Redmond
Hansel Minutes Technological discussion, usually focusing on .Net related technologies


Career Tools Solid advice about how to improve your career prospects
Manager Tools Management tips in plain language.  Even if you are not a manager it can make you think about what you are like as an employee to manage 😉
Manager Tools (Basics) I’ve been listening to these guys for years and they refer to concepts introduced in older shows… these are the foundation podcasts


The C64 Take Away Great remixes and sid tunes from the C64
The Roadhouse Signed and unsigned blues artists
The Raven and the Blues Signed and unsigned blues and blues inspired artists


Major Nelson Xbox 360 celebrity often interviews developers and reports sales figures – amongst other things.
OXM Podcast Pretty good 360 podcast from some of the guys behind the American edition of Official Xbox Magazine

Book review: Practices of an Agile Developer


A couple of weeks ago I was in Southampton and the Borders there was having a sale on all computer books… so I picked up “Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt.  Before I discuss the book I am going to go in to a little background.

One of my annual commitments I made back in October 2008 for 2009 was to learn about Agile practices… partially motivated by already being enrolled in a course that I’m taking next week.  I have been interested in these practices for quite some time though so this book is not my first exposure to agile thinking.  Before I left Ds Ltd for Lionhead Studios just over two years ago I had already co-authored an internal standards and practices document that encouraged various agile practices.

During university and the first year as a full time developer I was way more interested in learning some C++ tricks and a then newfangled language called C# that the management were for whatever reason excited about ;).  It is very easy as a developer to neglect the soft skills when there are cool new programming things to learn.

At university we were taught things like the Waterfall model, PRINCE and ISO 9000 accreditation – and whereas these things are important they do create a lot of paperwork.  ISO 9000 for example can fantastically document a horrific failure.  Things like “requests for change” that had to be signed off by more than one person are there to chain a customer to their original requirements.  GANNT charts created by MS Project used to make pretty diagrams that end up being a work of fiction because of unexpected bumps along the way.  It felt like setting up ways to assign blame for what goes wrong rather than concentrating on working together for a solution.  You get requirements, develop the software for a while, then hand it back.  It was contract negotiation over customer collaboration. Knowledge of these management principles is important so that you can make informed choices and discussions later on – but you will find every company has their own twist on the above anyway (the twist at university was everything was so literal and to the letter).

Other soft skills taught at university like uml, data flow diagramming, crc cards, database modelling are immediately useful in the real word for a graduate developer.  Sometimes these things are taught in a way that divorces them from the code too much; design everything first, code everything using the design later. This again isn’t the best way in practice (though probably a good way to create an assignment marking scheme).  While it is important to design up front, going in to too much depth lends itself to over-engineering. For example, classes created where properties would do, usage of patterns adding needless complexity to a solution, another layer of abstraction to solve a problem, “is-a” being taken too literally when applied to inheritance in class designs, etc.

So what better way to stop yourself wasting time and creating software that doesn’t please your users (or even get finished) than to read about other people’s experience first and not make the same mistakes?

“Practices of an Agile Developer” is a decent book that is all about how to be a positive influence on those around you no matter the position you hold.  It holds extra value for managers, producers and those that are in a position to lead from the top of course – but there are many things you can do on a personal level suggested in the book.  Committing to some of the things it suggests has the potential to make you more effective, and perhaps your work day more pleasant.

The book itself is quite short, but that is reflected in the price and concise style.  A chapter concentrates on a specific area of agility skills that is broken in to sections describing individual techniques.  Each technique is documented with a clear structure – identify a good and bad practice (represented by an angel and devil next to a box-out), then a personal experience from the authors and to finish off clear bulleted list of things to do.  The solutions at the end are particularly interesting in that they are always clear that taking the suggested practice too far can often be as harmful as not doing it at all.  Each technique also has “what it feels like” heading which describes the agility pay off when it has been applied in a balanced way.

The authors balanced, non-fanatical standpoint is much easier to digest than other books I have come across.  Ruby is mentioned a few times in a very rosy light, but considering the authors have close ties to the language you can let that pass.  The book does often refer to other books in the pragmatic programmers series which almost seems like advertising – though by not repeating other books it does mean the book keeps a tight communication and personal practice focus.

The first book in the pragmatic programmer series I brought was “Ship it!: A Practical Guide to Successful Software Projects” back in 2005 – which concentrates more on the practical detail of setting up a good production environment and development pipeline than team and customer relationships.  It is another insightful book full of practical examples of how to get things done – I have not read it front-to-back for a while but I may review it in the future.

“Practices of an Agile Developer” is a pragmatic look at practices that have been proven to work in the field.  It is a management book written for developers by developers.  Primarily I would recommend the book to students that aren’t quite getting the connection between modelling, code, and time management.  As for anyone else a bit more experienced  it is a good introduction to agile practices that isn’t terribly preachy – and does not smell of Power Point.


“Practices of an Agile Developer”

by Venkat Subramaniam and Andy Hunt

Buy from

Buy from

“Ship it!: A Practical Guide to Successful Software Projects”

by Jared Richardson and William Gwaltney

Buy from Buy from


P.S. Anyone have any requests for a subject you would like me to write about?  Anything sensible that doesn’t break my NDA will be considered 🙂

%d bloggers like this: