That word belongs to the category called “doom words”.
Producers who use the word “should” in their work, are taking steps towards doom.
Whenever a producer says “Here’s something we should do” nothing good really happens. Saying “that is something we should discuss” is equally bad. Hearing the word “Should” is something that makes people feel bad and something they forget pretty fast. If somebody walks around the office saying “what the team should do” isn’t really helping the project.
A producer that has good ideas that “should be used” is annoying at best.
So… what should the producer do?
Instead of using the word “should” producers could for example:
1) Decide how things are done and put them into action right away.
2) Suggest a date when decision for certain matter is done or agreed.
You really should consider this – for the sake of your team.
Couple of days ago I was asking our Dead Wake programmer how’s things and what has he completed. He said that “everything was fine until you came here…”
Luckily he was joking.
He had almost finished the list of tasks I’ve given to him, and said that he wanted to complete them before discussing with me. I was so curious to know where he was, so he continued joking that he couldn’t continue programming since I was asking all these questions.
Eventually he said that everything was indeed fine and explained what he had done, but this funny comment made me think how true this statement can be.
Are helping others to get their jobs done?
Producers from EA, Sony, Relic, Gas Powered Games, and others have given me hints about the role of the producer. All these producers agree that one key responsibility of a producer is to assist others to get their jobs done. If you keep bugging others asking what they are doing, when will they do this, could they do that, have they heard it, and thousand more questions – you eventually might get people to think “everything went fine until you came here”.
On the other hand, if you never ask any questions chances are that others start to think “what do you care – you never ask about what we want”.
So, how do you know whether you are assisting others, or just a hindrance?
The best way I’ve used is pretty simple: ask them.
If you encourage people to suggest how you could improve your game development practices, chances are that they will say something. Asking them “how we could improve our work” can be very effective, if you actually do something. Asking things “because there’s reflection phase in agile work” is not going to work unless you actually take time to implement those ideas.
Avoiding interrupting other people’s work while helping the team members to get their work done more effective is essential for every game producer.
Here’s an article that shows how the producers job is to focus on the solution, not on the problem. It’s not about somebody winning and somebody losing – it’s about creating a win-win situation if possible.
Two team leads were having a problem. The lead of the testing group was worried that new versions are not released as often as they should. When test versions don’t come soon enough, it might mean that testers need to test the game version that crashes often. It also means that new features aren’t tested as soon as possible, but rather that there could be weeks of delay before the group got their hands into new version.
The leader of the programming group on the other hand was worried that building new releases every other day takes too much time, since it require compilation of everything and making sure proper versions are used and that there’s no test code in the package. He was worried that making new release packages take too much time, when concentration should be on finishing the actual game. Lead of the tester team was requiring more releases, and the lead of the programming group was pointing out that compiling each release is away from actual programming.
These two guys had been “fighting” over this same thing earlier, and the game producer had also heard about this earlier. Now, the producer was in a tough situation: (1) Should he delay the tests in order to have more time for making the game? Or (2) should he delay making the game to ensure that there’s enough time spent for testing. It seemed to be a win-lose situation.
Instead of picking either of these options, the producer started to think: how can everybody win? Is there any other options? The producer came up with a simple answer, and he asked the team leads: “Why not make the release process faster?”.
Instead of spending too much time making release packages – over and over – it was suggested that the programming team would spend some time improving the release process, so that it would take only a few minutes at maximum. This option pleased both the lead tester and the lead programmer.
The system got automated and lead programmer was happy since it took no significant amount of time from his team to build each release, and the lead tester was happy since now he was having new test versions almost real time.
Also the producer was happy that he didn’t have to hear no more fighting in coffee breaks…