Team Members Are NOT Mind Readers

Have you ever encountered a situation where team member did not do what was supposed to do?

I have.

And usually the one to blame is NOT the team member… It’s usually the guy that stares at you from the mirror when you are shaving. Yes, that would be you – the game producer. For some reason game producers – or at least me – think that team members can read our minds. You have all plans sorted out in your mind, game play roughly sketched on paper and ideas dotted down… and you go to the artist or the programmer to do some task. After he has finished the task, he comes to you and you look stunned: the result is NOT what you asked. That’s because he cannot read your mind. If you think how something should be done, that’s not enough.

When mind reading fails, these tricks might be handy:

  • Write down what you want
  • Write also what you don’t want
  • Describe the situation
  • Make sure you write in a language he understands, not the language only you understand. Art monkeys don’t necessarily know programming terms!
  • Draw pictures
  • Draw flow charts
  • Draw diagrams
  • Use mind maps
  • Build/show/use physical objects if you need to! (Like they do in films studios – they build small objects to represent what needs to be seen in the movie. If you have a nice looking knife or chair you’d like to get modeled, show that to your artist)
  • Show design documents
  • Have references to other games when necessary
  • Give links to screenshots that might be relevant for the task
  • Use phone, skype or MSN to speak & chat, and to make sure the task is understood
  • Ask if the team member understands what he is supposed to do
  • Ask the team member to describe what he needs to do, or to somehow confirm what needs to be done
  • Sum up: number the tasks he needs to do ((1) 512×512 texture, (2) 2000 polygon 3D orc model, (3) …) instead of telling a fuzzy objective (‘I need an orc model’)

That ought to get you started.

Now, do you know what you are supposed to do when giving the task?

Juuso Hietalahti


  1. @Engeor: Yep, that’s true – for some people. There are others who do nothing but read. It’s true that a proper document / contract about work that needs to be done (with some kind of service level agreement) is good to have then I believe it’s the relationship that counts. When one needs to start pointing out ‘what the contract’ says they are getting in a wrong direction…

  2. I don’t know what is your experience but in my case no one read the text sometimes. On the other side, everyone look at the picture :-) In fact I don’t want to underestimate detailed documentation because when I recieve bad work (especially from external coworkers who are paid by finished work) I can allways say “but in the documentation it is described in another way” and it saves my nerves :-)

  3. Rule #5167:

    Don’t call your art monkeys “art monkeys”… at least not anywhere where they could see it… :p

  4. lol, “Art Monkeys”. Anyway, yeah this applies to managing a team generally anyway. It’s always good to get them to repeat back their understanding of the task (if they don’t have a problem with this, and they shouldn’t if they are professional).

    Also this article relates to customers. Sometimes a staff member would say, Custoer A is stupid, they have done this wrong or they didn’t understand me etc. I would say “No, it’s your fault if they didn’t understand. You are the professional, they are the end-user. It’s your job to work everything out for them and lead them by the hand so they totally understand and a grateful”. It’s a bit like teaching, blaming the pupil is not good, you just have to find a different way to get the information across.

Comments are closed.