This article will be the first in a series on the topic of effectively leading a group of people towards a common goal. Each article will discuss a different tool, or arrow, for your metaphorical leadership quiver. Like that? I just made it up.
The Problem
Groups of people who get together for a common purpose, public companies, mod teams, etc., all share one thing in common. They frequently fail. There are many reasons for a group venture to fail, but I’ll group them into two categories; market failures, and leadership failures. Market failures are when, for whatever reason, the venture itself is not sound. The game you are making is not fun, the product does not serve a rational purpose, or not enough people understand what you are trying to do. For whatever reason, you end up not having enough cash to continue working. Your company goes bankrupt, and you end up spending the rest of your life saying “Would you like fries with that?” Let’s ignore these types of failure, as there are many books that cover the subject broadly, and good advice would need to given in the context of that companies specific situation. Instead, we will focus on leadership failures. That is, when the company has a good product, good talent, and enough cash on hand, but due to poor leadership just cannot seem to get the job done.
The Catch
Here is the catch about tools that can help you solve leadership problems. They all seem so blindingly obvious. The trick is, while many people state that the solution is “blindingly obvious”, very few people actually use these tools. Why? I’ll quote good old Thomas Edison on this one. “Opportunity is missed by most people because it is dressed in overalls and looks like work.” I know I sure hate overalls. Similarly, people avoiding taking steps toward being a good leader because it is “dressed in overalls and looks like work.” So let’s get something straight. Nothing I state in these articles is going to be amazingly new. In fact, all of these articles will be covering leadership techniques that have been proven in the field, time and time again. I’m simply going to rehash some of the more powerful ones here so that you don’t have to go buy a few dozen leadership books before you can start making progress on becoming a better leader. The first tool I will be talking about is one of the most powerful– goal setting.
Goal Setting
For you, as a team leader, proper goal setting is a powerful motivational tool, is a vessel for sharing project vision, provides opportunities to communicate with team members, and sets benchmarks by which you can judge performance. Goals are flexible. They can vary in size, from long term project goals, to moderately sized intermediate goals, all the way down to weekly and daily goals. Goals can be subsets of other goals, and so on. You get the picture. If you don’t, read that paragraph over again, because it was perfect. The point I’m trying to get across is that without goals, people will not have anything specific to move towards, and will flounder in their work. Let’s talk about how to set up a proper goal.
SMART Goals
In order to set up successful goals as a leader, you cannot simply tell your team “This is generally what we are shooting for, GO!”. Instead, you will want to set SMART goals. SMART stands for Specific, Measurable, Agreed Upon, Realistic, and Time based. The definitions actually vary depending on who you talk to, but the basics are all the same.
Goals must be Specific. It must be clear, in writing, exactly what needs to be done in order for a goal to be considered achieved. If nobody can understand what a completed goal looks like, it is not specific enough.
Example of a GOOD, specific goal:
Complete code that allows units to navigate around obstacles on a path between two points.
Example of a BAD, unspecific goal:
Complete basic unit path finding.
- (path finding is too broad a term, and it is unclear exactly what functionality is desired. Duh.)
Goals must be Measurable. As a leader, you need to be able to measure the outcome based on the goal as written. This will allow your employee to measure their progress towards the goal and provide you with that estimate on how much time remains before completion. It lets everyone know when the goal will be complete. It will also allow you to provide better feedback based on the employees progress towards their goals completion. I find that often the Measurable attribute overlaps with the Specific attribute, because often a function either works, or it doesn’t; there is no linear trajectory upon which you can measure progress, merely estimates given by the developers. As such, in some situations having a specific goal which outlines what it means to be complete, is the same as having a measurable goal.
Example of a GOOD, measurable goal:
A game mechanic that will cause the players camera to move in the direction it is facing when the W key is pressed on the keyboard, left when the A key is pressed, right when the D key is pressed, and backwards when the S key is pressed.
Example of a BAD, un-measurable goal:
A game mechanic that allows the player to move around.
– (Bad because it does not SPECIFICALLY outline what needs to be done, and because of that you cannot MEASURE how close the developer is towards meeting that goal).
Goals must be Agreed Upon. If, as a leader, you simply dictate what must be done, and when it must be done by, you are going to get a lot of negative feedback from your developers. People need to feel involved in the process, even if you are guiding them towards a foregone conclusion. Most importantly though, your developers typically have more technical competence than you will in their specific field, and are going to be very useful in helping you ensure your goal is a SMART goal. As a leader you might decide that in this release, the team needs to finish the player’s movement functions. Your developers will help you figure out exactly what that means, and what it will look like when it’s done right.
Goals must be Realistic. If you set goals that are impossible to accomplish, nobody is going to take them seriously. This overlaps with the previous attribute, that goals must be Agreed Upon. If you take the time to form goals with your developers, instead of simply dictating them, it will be much easier to avoid making unrealistic goals, as your developers will help prevent you from making commitments that you do not have the time, resources, or collective will to accomplish.
Goals must be Time Based. You must make sure to allow enough time for the task to be completed, without giving the developer too much time. Remember in college how you would have three months to complete a paper that, at maximum, would take you five days to complete, and yet you would still wait until a few days before it was due to write the paper? Well, I didn’t, because I’m awesome, but I knew a lot of people who did that. That behavior doesn’t go away in the professional world. People will take as much time as you give them to complete a task, even if that severely impacts productivity. So make sure that while your employees are given enough time to complete their goals, you don’t give them too much time.
Sweet. So now you’ve learned that goals are important because they give your followers something to work towards, and provide them a clear indication of what the job will look like when it is done. They clear up communication so there are fewer misunderstandings, and provide you with a way of measuring progress. And finally, you have learned what SMART goals are, why they are important, and how to construct them. This will be the first arrow in your quiver of leadership. Remember to practice setting smart goals, not just for your developers, but also for yourself. The more you practice, the better you will get, and eventually all the goals you set will instinctively be SMART.
I hope you have enjoyed this article. Make sure to check back in next week for our next article update. And as always, have a Kung Fuey Day (You know, without kicking small children or what not).