Don’t Let Others Puke On Your Business

Those who enjoyed the pizza story might like this story as well. This is a shorty story about how bad customers can ruin business with other potential customers.

Couple of summers ago I saw a nice looking ice cream place near a lake. It was nice weather and the place looked clean. A perfect time and place to eat some ice cream. I was just about to enter to this place when some guy puked on the outdoor terrace floor. The smelly and gross looking vomit changed everything – and I didn’t get ice cream that day.

And I never ever will – from that place.

Whenever I walk past that place, it activates this bad memory in me and I simply cannot go to that place anymore. Even if I wanted I would still remember the vomit. Believe me, eating ice cream and thinking vomit same time is not exactly what I call a delicious treat. There are plenty of other places to go for some ice cream, so I have no plans to force myself to go that place.

Same can happen in your business – or even in your team. Some of your customers – or team members – might “puke” on your business. Some team member might be really negative oriented and kill the motivation or fun from other team members. Or maybe some customer is giving a really bad image (like what happened in my case) that stops you getting more customers.

Your job is to make sure this won’t happen.

Set Example

Yesterday I got a reminder about what it means to set an example. I’ve previously told our team members to “check forums & post & comment other posts”. When I’ve been working on some piece of code and needed testing, I’ve hurried up other team members to comment and do work. Yesterday I checked some concept art and agreed them via Messenger. I didn’t put a single comment in the forum (where the artist had put the concept art).

Thankfully he gently reminded me to “post some comments to forums”, and so I did – after he had said this. Funny how easy it is to require others do something, and then “forget” to do the same for your part.

After this small incident I started thinking how easy it is to lose focus when setting an example. It’s easy to ask others to work hard when you can have 100% focus on the main task. When you are getting really busy (or chose to be busy to be exact) – like I was yesterday – it’s easy to forget the small things you require from others.

If you require something from others, be darn sure to set an example on how things should be done. If you aren’t willing to do what you require from others, how you can expect others to do what you require from them?

If You Like Coffee Then Also Others Must Like Coffee, Right?

People might have tendency to believe that whatever they generally think is true, is true also for other people. Some people for example like drinking coffee and might think that preparing coffee for meetings is important as “most people will drink coffee”. It just might happen that they are faced with Chinese people who might prefer tea over coffee, but that didn’t occur to them.

If you drink coffee, that doesn’t mean everybody else likes to drink coffee too.

Some days ago I wrote an usability tip and received feedback telling me “best post in weeks”. I was quite surprised. While I think that tip was good I personally liked more posts “what’s good in this situation” and 3rd Party Tools Always Cause Minor Problems. These posts received only one comment in total. This shows how people are different: different people like different things.

It’s same in games (and many other issues as well): whatever you think to be “typical” might not be for everybody or even for “most of the people” as you think. I like playing – and making – online multiplayer games but I must accept the fact that most people on Earth won’t be playing those games. Majority of people like to play single player games. I also generally like working via the Internet and not face-to-face or phone (well, most of the time as I find it more convenient) but that doesn’t mean everybody would be like that. Some people will definitely want to have face-to-face meetings when deciding about some important things.

If you like the art to be drawn in certain way or that your website graphics are done in certain style that means you are preparing the art for you – and cannot really know if others will like that too. If you are making “a game that you like” it doesn’t guarantee that others will like it too. Not before you get people do some marketing research and test your game prototype with other gamers. If you focus on making a game that you think is best it’s like offering only certain type of coffee, with a certain amount of sugar or milk, drinking it from a certain type of cup and believing that everybody else wants their coffee that way. That simple won’t work.

Whether you drink coffee or not doesn’t mean that others would follow your habit. Whatever you think is best for games might not be best for everybody – or even for most people.

Getting Rid of Stress

Many people in IT area experience stress. Many game producers and programmers have stress. Those who do might blame external issues. They might think that other people, work, cars, Christmas etc. cause stress, but that’s not true. Stress is internally developed and while external issues will have an impact – the one who controls stress is you. You are in charge whether you experience stress or not.

It’s okay to have stress – there’s nothing wrong with that – and it’s not always easy to be stress-free in every situation. But even then, you are in control. You decide whether to have stress or not.

Here are some ways to reduce your stress level: exercise (decent load of sports will give you something else to think about), get rid of workload (I’m sure there’s unnecessary workload that you could delegate to somebody else), meditate (haven’t tried, but so they recommend), reduce the amount of uncertainty (for example, if you are worrying about whether you can find a fire exit in case of emergency, a good way to reduce stress is simply go and check out where the fire exits are)

Dalai Lama has said:

“when something is troubling us we tend to blame other people for the problem. Instead of reacting instantly, we should examine the problem with a cooler head. The first step is to see if there is a solution. If the problem can be solved, there is no need to worry about it. But if the problem cannot be overcome, worrying about it will do no good.”

I think that’s a great quote to remember.

3 Practical Tips For Better Leadership

Be fair. I believe every game producer and team leader out there should be fair towards every team member. This means that everybody is treated the same way. If you let some people behave the way the want, you need to give this privilege to everybody in the team. If one guy can be late from meetings, then everybody can be late from meetings. If nobody is allowed to be late – that means nobody. If you require lots of work from team members, be sure that you don’t require more than you are willing to do. Being fair includes you and everybody else.

Show leadership using stick and carrot. Even though I really haven’t met one, I’ve heard that there are bosses that are concentrating on the stick part, and forgetting carrot: they only “punish” and never reward. Then there might be leaders who use only carrot – rewards – and never use any ways to punish people. They say that “stick is demotivating” or say that “using carrot is the best way to act”.

While I agree that rewards are the things that motivate, but that doesn’t mean there wouldn’t be consequences for critical parts in the project. For example, if some team member constantly mocks everybody else and disagrees with everything (just for sake of disagreeing) I would seriously consider dropping that team member out. Naturally every situation must be acted fairly, take into account what’s important and what damage this team member does and discuss things openly with him before taking any action – but leaving somebody out is sometimes the right thing to do.

Other forms of “punishment” could be that “those who are late from meetings buy donuts to whole team”. If some guy has been late several times, you might be surprised how miracleously there’s no more reasons like “traffic jams”, “alarm clock didn’t work” or “had to take children to school” – even the “laziest” guys get to meetings on time when they know they will get consequences. And it’s extremely important to be consistent with this: if you put the late-donut-policy in action, you must be 100% sure that this policy is followed – it’s your job to make that happen, every time.

Say what you think, honestly and intelligently. It’s good to express your thoughts and say what you really think. Some people go into extent that they bash anything that comes to their mouth and validate their actions by saying “it’s good to say honestly what you think”. I agree that it’s good to say honestly what you think, but there’s no reason to bash others. If somebody has done a poor job, it’s right – and producer’s responsibility – to say that. The way you say it is what matters. If you say “You did a shitty job, fix it” it has a quite different attitude that expressing “Your work has always been great quality, but this time I think this work could need some improvement. Overall the job is well done, but requires some improvement here and here – what do you think?”. I don’t mean that you should say “you’ve always done great job” if the guy really isn’t. There’s no need to lie about the work, but if the guy’s work has good parts you can mention that you like about those, and then you can express what needs improvement.

Being fair, use of rewards and consequences and communicating well are tools that can help you leading your team.

How to Deal With Angry People

One word answer: patience.

I’ve noticed that the best way to deal with people who are angry at you – furious about your writings, mad at you because they didn’t receive a registration key or whatever – is to listen carefully what the other have to say, and then deal with the issue. Thank them for their time and think how you can deal the issue. Think if their commens contain anything useful or have a valuable lesson to learn.

Why thank them?
There’s at least two big reasons why you should thank angry people:

  • First of all: they just gave you an opportunity to teach calmness for yourself. That’s definitely something worth thanking.
  • Secondly: Many people might not say anything and never deal with you again. Complainers give you an opportunity to improve.

Why listen to them at all?
I’ve said it many times before that bad feedback is good. Complaints give you a chance to learn something valuable. Of course you are free to reject any comment you receive, but at least you’ve got a chance to improve your offering.

7 Golden Guidelines For Having Meetings

Meetings are part of the business: even indie game producers have to get out of the box and stop staring the computer screen all the time. For team leaders it’s natural to arrange meetings. Here’s 7 guidelines for arranging better meetings.

Guideline #1 – Don’t have a meeting just a sake of meeting
Unnecessary meetings are just that: not necessary. There’s plenty of managers who think that because office rules says “weekly meeting must be arranged” then weekly meeting must be arranged. Even agile game developers might arrange useless weekly meetings and call them “proven method for productivity”. I’m not saying that weekly meetings are wrong to do, I’m just saying that weekly meetings that are done just for the sake of having a weekly meeting hardly brings much value. The agile developers who use weekly meetings “properly” don’t spend 2 hours just for sake of chatting. If there’s nothing to chat, the meeting lasts only 5 minutes.

Guideline #2 – Start on time
Very important. Suppose you have a team of 6 people. Every time meeting starts 7 minutes late that’s 42 minutes (possibly) wasted time. Suppose 40 weeks – and every week somebody is 7 minutes late – means 1680 minutes wasted. That’s 28 hours wasted – almost one work week, just for the reason that somebody is late.

Guideline #3 – Finish on time
I don’t suggest that every meeting should be stopped when the clock ticks, but I think it’s important to deal with the agenda in timely manner. If the first issues get too much time, then the last issue will be dealt very badly – or not at all. I really think the meetings should not slip from the end. Instead – arrange enough time to deal with the issues rather than always saying “1 hour meeting” that in reality lasts 2 hours.

Guideline #4 – One leads the discussion
Linked to the point #3: somebody should lead the discussion and move to the next issues if necessary. If nobody controls the meeting… then it can easily lead to situation where people discuss many, many things not related to the meeting.

Guideline #5 – No too many issues in agenda
Don’t take too many topics in one meeting. It’s better to focus on few things rather than chase many rabbits. Overbooked agenda can easily lead to too long meetings or bad results.

Guideline #6 – Avoid ‘Will be agreed on the next meeting’ agreements
This is one of the trickies pitfalls to avoid, but I really recommend making decisions when they are needed. Postponing anything to “next meeting” means piling up everything until it all comes a big pile of unfinished issues. Avoid this type of agreements whenever possible.

Guideline #7 – No talk about TV in meetings
It’s easy to get sidetracked and start talking about television shows, latest news, games, business, and pretty much everything else but meeting. I really recommend leaving this type of talk to some other time (like right after the meeting when you are short on coffee…). Any time somebody starts talk about “good movies” it means your meeting is about to lose the value.

What You See Is Not What You Get

Here’s a small test for you. Below you can see two black balls. What I want you to do is the following: Cover your left eye with your hand, and look at the left ball using your right eye. Try moving closer to monitor and check what happens to the right side ball – while keeping your focus on the left ball.

The right ball vanishes. This is no magic trick, it’s a simple optical test to check where your eye’s blind spot is. But nevertheless – it’s interesting. When you focus your right eye on the left ball (and cover your left eye), the right ball vanishes. You could swear that it’s not there.

Isn’t this same issue with game production or in many discussions? It’s easy to focus so much on what we see… that we actually get blind for other people’s opinions. It’s easy to come in one perspective and tell that “this is the truth, as here are that facts – and I’ve got experience to prove that”. Like perhaps some people has got bad experiences with negotiation with companies and used the rule of “other party must ALWAYS make the first offer”. That might lead into a situation where they get blind on any other options. Perhaps in some cases the deal is completely lost because the guy got so focused on not making the first offer – instead of seeking the win-win solution. It’s easy to cover our eyes – so to speak – and focus on “facts”, “truths” and “the right ways” when in reality we should ask ourselves: “Do we need to be right? Or do we need to make a deal that benefits us both?”

Open your both eyes. Listen openly to what people have to say. You don’t need – and shouldn’t – accept everything, but at least you don’t block away potential opportunities just because your focus was somewhere else.

Why Everybody Else But You Does a Poor Job in The Team?

I have heard game producers, project managers and other team leaders telling and pondering how “everybody else in the team does a poor job, even when I’ve told them what to do”.

Days and weeks pass and some people just not seem to get anything done.

The first obvious choice might be blaming those people and thinking about monitoring the team members or give more guidelines on what needs done. Some might even use threats or remind these guys as often as possible (using cell phone, emails, instant messaging, and other methods ranging from smoke signals to car horns).

More months pass and nothing might happen – besides that you’ve now buried yourself into a pile of endless reports – and the tension might grow even more.

The other option for monitoring, guidelines and reports could be asking. First ask yourself: “Have I’ve done everything well? Is there absolutely nothing in my actions or behaviour I couldn’t improve?” Sometimes by merely asking yourself what you could do better might help. You might realize that you’ve been silent when the team member has asked for help. Because you were too busy in the past – why should he listen to you in the future?

Before blaming or accusing you might also ask the team member: “I know you are a hard worked and have done a great job in the past, but recently you seem to need much more time to finish your tasks and the quality is below what you usually do. Is there anything I or we both could do to make things better?” Perhaps he has been too busy with handling other tasks or helping his co-workers. Perhaps he would like to take more part in the planning and design phase instead of simply acting like a computer that gets input and prints output. Perhaps he would like to get more responsibility. Perhaps he has just been too busy or lacked motivation and needs a break.

There are lots of reasons that might explain his behaviour. Say clearly what you expect and simply ask how you could improve the situation. It might be all that you need.

Time Tables

I use time tables in quite a flexible way: I use milestones (like the ones we missed couple of weeks ago…) to tell about the “bigger picture”. Having information about the big steps makes it clearer for everybody involved in the production – team members will have idea about where you are going.

People (expecially indies) either work hard or not and make their own time tables or not. In the past I worked with a guy who repeated mentioning the hours he spends on development, he said he was doing 10 or 14 hour days. Yet, I didn’t see almost any results and eventually the guy just vanished after I asked for he to give me the work he had done. That’s the last time I heard about him. On the other hand, I worked with a very skilled programmer who worked really hard. In both cases the time tables were handled in similar manner – milestones to give a bigger picture, and then some sort of task list to see what needs to be done next.

Better to have some sort of plan, and work hard on in rather than to have very detailed and big plans that never get done.