Category Archives: Leadership

Management is doing things right; leadership is doing the right things. Leadership is also interaction with the team members and problem solving.

Pretty Simple Way to Have Incredibly Effective Meetings

How come there’s so many project leaders who tend to have these huge meetings where everybody needs to participate and where there’s 700 topics in the agenda. No wonder the meetings are long, boring, and accomplish very little.

Here’s a simple secret: have only one objective for the meeting.

It might sound a bad idea, since there’s so much things that you need to accomplish. Well, I think it’s better to at least have one successful meeting -rather than a series of failures. If there’s so many things you need to accomplish, then the problem isn’t necessary the meeting. It’s something else. It’s something that lead your team to a situation where your meetings are huge, and accomplish very little or nothing. If that’s the situation, then taking a step towards to a method where meetings are simple and something is decided in an effective manner doesn’t sound so bad to me.

Give it a go. If it doesn’t work, then you can always revert back. Instead of creating agenda with loads of topics and many things to decide, have a meeting where there’s only one objective. After that objective is accomplished, the meeting is over. If you need to decide about technology tools, then have a meeting about that. Don’t even try to bring holidays, bonuses, gameplay design, business deals nor other ideas in the meeting.

Keep it short. Keep it simple.

Keep it focused.

Don’t Be Part of the Problem, Be Part of the Solution

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.

The problem
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.

The solution
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…

How to Be a Stupid Producer And Waste Everybody’s Time

I’m sure you know many people who master the art of being stupid. Here’s one additional way to act like an idiot. This article is based on an almost true story.

I heard about this guy who always said that everybody should schedule a meeting with him, not use email to contact him. Perhaps his inbox was so full of emails that he couldn’t find time to reply to them. Anyway, the bottom line was: he always wanted people to find time for a meeting instead of asking stuff via email.

Well, I’m sure in some situations that might work well if emails require replying and re-replying all the time, instead of just taking time to sit down and have conversation where plans are agreed.

But this was not the case here.

In fact, the guy was so busy that he was always in some meetings. People ended up emailing him to agree about a meeting time (but couldn’t ask their questions via email since the guy insisted that meeting time would need to be agreed), and then he would reply back saying “that’s not good for me, how about this time?”. Then the other person got his reply and saw that the suggested time was bad, and sent another suggestion. This continued for some time until it was seen that there were good time available after 2 weeks. Too bad the situation needed to be resolved this week, so that kind of didn’t work.

Also, the other person only wanted to know “if the producer has faxed the signed copy of contract” (or something like that) so that the other guy could continue his work. The producer didn’t want to get bothered via email (nor phone I suppose – or at least he was being so busy that he couldn’t answer anyway), but insisted of scheduling a meeting (yet he agreed to schedule meetings via email!)

Perhaps he needs a secretary or something, but “scheduling a face-to-face meeting” (via email) instead of “dealing with some issues via email” won’t save his time. And I really don’t know why he keeps doing this.

Havin Team Democracy Is Not Top Priority

The objective of a game development team is to produce results. Having democracy and “hearing everybody” shouldn’t be top priority in every decision making. There are some reasons for this.

Democratic votes are time consuming
That’s the main reason why there should be leader in the team who is willing to make decisions when necessary. If you use “democratic voting” – hear what everybody has to say – every time you try to make a decision, it will be darn slow. Sometimes you should just cut corners and decide stuff on your own.

It might slip into being fake democracy
If people are just heard (but nobody is really listening), then you are just faking democracy. You are asking what people say, but then do whatever you already decided. That means wasted time (and basically is pretty annoying).

Democracy might indicate that you are a clueless leader
This is bit of an exaggeration, but think about it. If you are the leader, and you are always asking “what are you guys thinking about this” and “what are you guys thinking about that”… then people might get the impression that you don’t want to make decisions.

Leaders should bring vision and goals – people want leader to lead.

A word of warning. Being tyrant is equally bad (or worse). You have to keep the team motivated and ask their opinions now and then. Balance is necessary.

The point I want to make here that “having democratic team” over “having team that produces results” is not such a good idea – since the goal is to actually produce something, not make sure everybody gets heard always.

How to Minimize the Pain When Firing People

Firing people might be of the toughest things game producers may face. Luckily I haven’t faced that situation for some time, but the recent discussion regarding how to deal with a slacker got me thinking about the firing.

Strangely, I believe one of the most important elements in the process is this: if you need fire somebody, don’t delay the firing. Postponing the decision and hoping to things to work out is not always the best solution. In fact, not firing somebody can have several nasty effects:

  • The guy who should be fired (and is not) will cost money (his salary needs to be paid).
  • The guy might slow down the project (if he is not suitable person for the project) as he still needs management.
  • The guy might harm the working environment (if he has negative attitude it can be bad for the morale)

Sometimes people still want to avoid firing, and reason this by saying “that they want to minimize the pain”. There’s just one problem with this approach: firing won’t get any easier in the future.

My reasoning is that people shouldn’t hire and fire people without good reasons. I believe that postponing the “inevitable” is not a good strategy. If you need to do something, then just do it. If you need to fire somebody, then fire him. Minimize the pain by not postponing the firing process.

Do You Set Limits?

The new game producer forums have been online for about a month and the membership count is now close to 300. There’s 20 banned users already. We are taking the rules seriously, and want to keep things civil. If somebody tries to just register to spam something (without reading rules – nor using common sense) he will be banned, and that’s it.

So far the strategy has worked fine and the discussion has been civil. I want to ensure that the forums are place for great discussion. I want quality over quantity.

And that’s why we have set limits. The rules are quite simple and rely on one major guideline: use your common sense. That goes far away. There’s alternative for whining. Instead of blaming for everybody, suggest a solution. master complainers are kept away.

We set limits in the very beginning. I know from experience that if you don’t set some limits right from the beginning, it will be much more difficult later. Anyone who has trained dogs (or has children) knows how difficult it can be to get the dog (or a child for that matter) to stop doing something he could have done earlier. If you allow dog to sleep on the sofa for two years, you’ll face lots of resistance if you try to change that rule when the dog is 3 years old. If you allow child to decide what he eats when he is 2 years old, rest assured you’ll face lots of resistance if you try to change that habit when the child is 6 years old.

See in the future, and set the limits according to what you want.

What a Running Cat Just Taught Me About Leadership

A few ago I was at the parking lot (very good places to learn something I must say) with our dog when suddenly a cat run to a nearby bush. Naturally our vicous bloodhound (picture on that page) immediately run after the cat.

In less than a second I said “No!” and our nice dog stopped and came back. She shouldn’t run towards cat like that.

Then I continued to lock my car and went back to our apartment.

After the incident I realized how I just had made mistake. I was saying “no” when the dog was doing bad things (chasing the cat) which was okay, but where was the reward after the dog did well (stopped when told, and came back by my side)? Nowhere.

It’s easy to blame and think about the things others shouldn’t do, but the real focus should be on the things that were done right and well – and reward them.

When was the last time you told people about work done poorly?

And when was the last time you pointed out something good?

7 Ways to Inspire Team Members

Motivating yourself is important, but equally important is to inspire and motivate your team members. Here are 7 ideas that you might want to try.

#1 – Show progress
Quite obvious one, but can be easily forgotten. Make sure you show progress and tell openly where your project is going. Even if programmers don’t know how to rig or animate, it will inspire them to see artists doing their magic. Keeping project visible and showing progress helps everybody.

#2 – Bring good news
This is a great motivator for everybody in the team. The fact that today I found an animator (finally) and announced it to other guys in the team will certainly be inspiring for them. Bring good news – it’s good for morale.

#3 – Show success stories
Successful people are hungry for success stories. Tell about other teams who have done a good job making and selling games and it will motivate your team members to do a good job. Tip: check out game sales statistics for detailed information about how much different games have sold and share them with your team.

#4 – Cash rewards
Pretty simple, yet efficient way to motivate. If you have a tight budget, you can still sometimes give additional bonuses and rewards for the whole team when a milestone is reached or a job well done.

#5 – Give credit
Give credit for those who deserve it: everybody likes to be famous and see their names in public. Make sure to let your team members share the fame. (I have promised to share more about our team members and will do that “soon”).

#6 – Use their design ideas
One of the most motivating things is to see your own work in the actual game. Not only code or art assets, but to see design ideas. (Be careful with this though: somebody might suggest pigs to be included in the game – see #10 point on that blog post).

#7 – Share your inspiration
If you are inspired to work, make sure it shows. Talk in inspiring and motivating way and it will be catched by others.

Your inspiration can spread like a virus.

Do You Make This Mistake When Emailing People?

Lately I’ve been getting some emails that have started with an apologize. I’ve got emails where the first sentence has been something like these: “Sorry for mass emailing you…” or “Sorry to email you again, but…”

Sorry for emailing me something I wanted?

I really think that newsletter sending should NOT start by saying sorry. Not even if you send couple of emails in a row. Not sure if I’ve apologized sending several emails it in the past, but I’ll (hopefully) don’t do that in the future.

Basically, the reason why this kind phrase in emails is not good boils down to these two points:

  • If your newsletter (or email) has something valuable for the reader – why should you apologize it? If you bring me value – why should you feel sorry about that?
  • On the other hand, if your email is useless and doesn’t give me any value – then why the heck are you sending it?

Make sure your email has value, and send it. If you have nothing useful to say – then trash the email.

There’s no need to apologize when you provide valuable content.

7 Deadly Management Sins

#1 – Dictatorship
“You are wrong, I’m right” attitude (or “it’s my way, or the highway”) is a deadly management sin. The guy who “leads” the team by dictatorship will soon be left alone with nobody to manage. Game producers and managers need to be ready to make tough decisions and tell how things will be done – but not always. Stubborn attitude leads to getting stuck – and nobody follows a dictator forever.

#2 – Lack of focus in production
Aimless game production or project work is another deadly sin: it leads to clueless work, that results to nothing. If there are huge number of open issues and possibilities then it might mean slowed progress as no decisions are being made. If the team is focussed on making progress through certain path, then it’s much more likely to get the project finished. Lacking clear focus and objectives are killing mistakes in game production.

#3 – Forgetting your team members when they’ve done a good job
Here’s a simple test for any manager out there. Simply answer yes or no in the following two questions.

Question number one:

“Have you noticed some poor work by your team members and required it to be re-done in your current project?”

Question number two:

“Have you given praise to your team members for some good work done within this month?”

If you answered “Yes” to both of the following questions, then you are in the right path. If you answered “Yes” only the first question – then you seriously should think about your current management style. Other combinations are possible, but the bottom line is: you have to make sure you keep certain level of quality, and make darn sure that you let your team members know when they’ve done a good job.

#4 – Not focusing on the outcome
Focus on results. That’s a simple piece of advice that’s so easy to forget. Sometimes there might be team members who like to do things on their way, and “not by the book”. As long as these team members produce the necessary results and don’t harm the team work, there’s no reason to require them to “work like everybody else”.

Some people insist that there must be certain working hours, but if somebody wants to take 1 hour nap during the day – that shouldn’t be a problem. If somebody would spend half day meditating, yet achieving twice as much as the rest of the team: there shouldn’t be any problem with this guy’s habits. As long as they are ethical, legal (you have to think your company), are align with the company values and vision (for example: there might be certain requirements for company image) then it shouldn’t be a problem.

I try to follow the guideline to let team members do almost whatever they want (notice the word “almost”) – as long as they get the job done. When I’m outsourcing some tasks, I really don’t care if they use voodoo dolls and prayers when they are coding: as long as the code is done as it was agreed, and as long as they produce good results – I couldn’t care less how it was done.

If focusing results works in outsourcing, why shouldn’t it work also work done in-house?

#5 – Getting nice people, instead of right people in the team
Another deadly sin: getting nice people instead of right people. I don’t put much focus on whether the team members should be friends or not (for the reason that was mentioned in the previous chapter), but I can assure you that “being nice” alone cannot be the factor when deciding who gets in the team.

Some project teams are almost build like that: everybody gets to join and the guideline is “we just have fun making games”. While that is a noble idea… I really don’t think it will be such a good long-term solution. Taking everybody who is “nice and interested about the project” doesn’t guarantee that you get the rights persons to do the right job.

Instead of “nice persons”, pick “nice persons who have the necessary skills to produce the results you want”.

#6 – Asking recommendations, and then ignoring them
I’ve mentioned this earlier, but I have to say this again as this is one sure-way methods to kill the team spirit. If you ask recommendations from your team members: then make 100% sure that you actually check out those recommendations and consider them.

If you’ve already decided what you are going to do – then there’s no point pretending anything else. Team members will be much more grateful for a leader who tells them what to do than for a leader who asks recommendations and then does whatever he had already decided.

#7 – Not taking into account team members’ personal life
There are situations in every people’s lives that might affect to the work. Sometimes these can be very sensitive issues, and if you don’t notice what’s going on in team members’ personal lives – then you might end up seeing somebody’s work performance going down, or somebody even leaving the team for no apparent reason. It’s a deadly sin to forget that there’s life outside work.