There are two kind of people when it comes to asking questions: First of all there are the people who don’t want to ask ‘stupid’ questions. These people are afraid that others would laugh at them, or that others would consider them stupid. The more people are involved in the conversation, the harder it is for these guys to ask for help – even when they know they should. These guys end up paying high conference fees, smiling, nodding and telling how everything was wonderful – although they don’t have a clue what was talked about.

I personally believe there is no such thing as a ‘stupid question’. It’s not matter of stupidity – it’s matter of knowing something or not knowing something. If in the middle of a conversation, a company stakeholder asks “What’s Java?” – the programmers might smile or think “How crazy is this? Guy owns a tech company making applications primarily in Java, and he don’t even know what the term means”. Well, if the programmer then need to ask “What’s ROI?” – the stakeholder might smile. Both are extremely basic information, but you just have to know what they mean if you want to talk about them. It’s not matter of stupidity, it’s matter of knowing terms.

Then there are those people who ask questions. If they don’t know a meaning of something, they might simply others to give more information. They might ask “could you clarify, what you mean by ‘company strategy’ in this context?”. Or they might say “You mentioned bump mapping, I’m not quite sure what it means or how it would enhance the user experience. Could you give me bit more information about how it works?”. The higher levels the talk goes, the more important it is to know exactly what people are talking.

Being afraid does not help anything, and if others smile at you… well, then that’s basically their problem – not yours. You cannot change the way other people think about you, and it’s up to you to whether you understand or not what others are talking about.

We are currently processing getting 3 new team members to our currently 5 member team. I personally don’t think in the idea of “everybody should get into team”, since from my experience that results to lots of wasted time. Sure, it might be fun, and it might you help find the right persons – but I personally try to screen good team players right in the beginning.

Why you need other team members?

This is the most important thing: why do you need team members? Be absolutely sure to answer to that questions before you proceed getting anybody in your team. Our team has had some additional need for animation, programming and concept art. We either need to outsource some of these areas (like concept arts and perhaps animation) or get new people to do these. We are still processing the “hiring” at the moment.

Focus on getting whose who do things, rather those who can do things

When I’m getting new people in the team I’m more concerned about getting people who have time and motivation to do things. I’ve seen many industry professionals, who can do amazing stuff – if only they would have time. I personally try to get talented guys who can actually finish something. I’m always more interested in “how people can contribute to the project” rather than “what piece of work somebody has done in the past”. Naturally, I will check what projects or work team members have finished in the past, but even then I’m more concerned to make sure that these people can get things done.

Increasing headcount means increased management

This one is really important: with 5 members (me included) in the team, there’s quite a lot of management to do. Coordinating, writing, communicating with the other people is always there. Since we are about to increase the headcount to 8, we need to be extra careful what kind of people we get in the team – and what it means in terms of responsibilities. Dealing with 7 other people means quite a lot of time spent on putting everything together.

I recently started thinking how could I make sure that I keep the promises I give. I noticed that I’ve had 2 major factors that have influenced this. The first one is simply promising something that I can keep. I remember I promised to give interview with the makers of Lord of The Rings Online. I made that promise after I received an email from them to send them the questions. After I sent the questions I remember mentioning that “I will be interviewing them in GP blog”. Well, I never got the responses to my questions – and I could not publish the interview. And I’m not blaming LOTRO people for this. They didn’t give my promise to blog readers, I did.

While it might sound like keeping some small promises is not that important for you, they might be very important to others. If you promise to tell a good word about somebody – but you don’t – then that somebody simply might not want to waste time with you in the future, since you didn’t keep your promise. That’s why it’s important to keep all the promises, even the smallest ones. I personally have made small promises in the past, and while it has taken some time, I will keep those promises the way I can.

I’ve learned that I have to be careful when promising interviews or anything. If I’m not sure, then I might as not give the promise – or tell that what I’ve done. Like in the LOTRO’s case, I could have told that “They’ve accepted my request and I’ve sent the questions. Now we have to wait and see if and when they find time to respond”.

In summary, the first lesson is: think carefully before you promise something.

The second thing I learned was that I cannot rely only on my memory. I simply cannot remember all the tiny promises and words I’ve said. I believe I’ve promised at least few things here on my blog, but might have forgotten them afterwards (notice: if you want to remind me about some promises, now it’s a good time for that). I believe there aren’t many promises like this, but I suppose there might be something that’s simply lost somewhere. I’ve also noticed this when talking to some people. Some people simply promise to do this and that… yet, they fail to keep those promises. They might be like really small things, but small things might have a big impact.

I came up with a simple solution: use of a text file. I have made a text file for my promises. It’s really simple and fast to use. I will put headline, possible date and description for each promise I’ve given. That’s it: write down your promises.

Since I just started using this system, there’s only one promise at the moment:

GAMEPRODUCER.NET – ABOUT EDOIKI GAME
In the future I will tell more about our team, and our team members – so that those who do things actually get the credits.

From that text I can see that I’ve made a promise to GP readers about Edoiki game.

I believe this is an extremely simple and efficient way to keep track on what you promise, when you promised and to whom you’ve promised. Certainly beats just relying on my memory.

Bottom line: Think carefully before you promise something. Write down your promises: what, to whom, when, with a brief description.