6 June, 2016
I’m currently reading Team Leadership in the Game Industry by Seth Spaulding II. This isn’t a full review, but I read something that got me thinking: in the book he advocates that leaders should not do work tasks in addition to leadership tasks. In other words, lead programmers shouldn’t be doing programming, rather they should be leading: working out schedules, assigning tasks, and so forth.
I thought this was interesting, so let me share some of my thoughts on this.
The leadership curse
In the book, the author mentions that most leaders get promoted because they’re very good at their job (as a programmer, artist, or designer). So, for example, a brilliant programmer gets promoted to lead regardless of if he or she even has any leadership ability. This isn’t to say that a lead programmer doesn’t need to understand programming. Hardly! Understanding programming is vital to being able to do some of the leadership tasks such as scheduling, giving feedback, identifying problems and how to resolve them, making technology decisions, etc. But, the industry tends to value that understanding more than they value someone able to actually perform the tasks required of a leader.
But, the problem is that if you promote your best people and your leaders don’t do direct work, then you’re diminishing your pool of talent able to do work. I saw a similar thing happen at my first job at 3DO, where the best QA people were doing a great job and then got promoted out of QA and into “real development”. This deprived us of great QA people in exchange for developers of unmeasured ability.
On the other hand, business is geared toward promoting people for good work. We reward hard workers with more responsibility and leadership positions. Someone who isn’t promoted will start to feel like they are falling behind their peers. Although, some business are starting to address this issue, with positions like “principal engineer” or “distinguished engineer” for people who are really good at programming but have no desire to get into a leadership position.
A leader that does work can also be distracted. Imagine if you went to talk to a programming manager who was busy working on some programming tasks. And, as a programmer, you know that interruptions kill productivity. So, do you interrupt the manager with your problem? You might hesitate, even if the manager could realize the problem is bigger than you understand. Or, even if you do interrupt the manager, you may not get his or her undivided attention if he or she is still chewing on a problem.
I saw this happen at one place I worked at. A programmer was given some leadership and management responsibilities, but felt torn between still having to get work done while still helping others out. Added to the fact that he had young children, so his time was stretched thin on multiple levels. It was a tough place for him to be in, and it goes without saying that he wasn’t helping people do their best work.
So, again, we see a good reason for leaders to not have additional work tasks on top of their leadership responsibilities. But, there are some cases where that’s simply not realistic.
The startup exception
A lot of game companies are small independent companies with few people working together to accomplish a goal. The idea of someone focusing entirely on simply leading others seems silly, as generally startup people should be self-motivated and able to manage themselves. You generally need as many people as possible working to accomplish the company’s the goals. In a startup environment, being able to move fast is an advantage you can’t ignore.
So, having a competent programmer set aside programming tasks to lead the (likely small number of) other programmers doesn’t make sense. Yet, you usually want someone in charge of having the final say in technology decisions. So, you need a leader even if you don’t need someone focused entirely on leadership tasks.
So, it feels like this principle of having leaders not do direct work is more for large companies than independent companies and startups. Since startups are supposed to be small and agile in order to out-compete larger companies, it make sense that if the rules is to have leaders focus on leading, you want an exception for startups. Of course, then the question of when a startup transitions to an established company who needs dedicated leaders becomes important, especially since some larger companies sometimes still cling to the “startup” mantle long past where they should.
One downside is that a leader who isn’t doing work tasks might see their skills fall behind. The hot new art package, language, or design philosophy may be beyond their experience if they focus entirely on leading. Even if they do research on some new element, that is not quite the same as using it in anger to accomplish a task.
If the leader becomes too disconnected from the day-to-day work of the people who report to him or her, then that leader may run the risk of not having the information necessary to make good decisions. Especially in the fast-paced game industry, this may mean the leader relies too heavily on outdated methods he or she is familiar with rather than embracing more proven methods or technologies. Even worse, this can make the people reporting to him or her feel that he or she is out of touch and unable to handle issues that come up. Losing this trust can be deadly.
Another way to look at it is that staying current is the responsibility of a good leader. Even if a programming manager doesn’t do programming tasks at the company, this does not mean he or she cannot do programming work on their own time for their own small projects outside the company. This could be a good way to stay current, and even give something to talk about with the employees. This can also help when interviewing prospective employees, as the leader can ask relevant questions.
Letting leaders lead
As I said in my previous post about persuasion, the fact that authority is one of the principles of persuasion can make it hard for leaders to make decisions that others feel comfortable addressing. A leader who makes a bad decision may not get the vital feedback necessary to improve that decision later, even if they say they want others to give feedback. As Captain Abrashoff said in It’s Your Ship, a leader needs to be aggressive in listening to for good ideas from the people in the trenches. But, if people are too afraid to talk about their ideas, no amount of listening will suffice to get the best ideas.
In a way, a policy of leaders not doing work tasks can be a good way to address this. If the person signing the paychecks isn’t also the person maintaining the vision of the design, for example, it can help keep the design from stagnating as people just do what the boss says. Same with bad technical or art direction decisions made by the leaders of these areas; it takes audacity to criticize your boss’ decisions even if you know they could be better.
I think it really depends on the situation. In startups and very small companies, you can rarely afford to have someone concentrate purely on leadership tasks even if you need a leader. In larger companies, I think it makes a lot more sense to let your designers, programmers, and artists do design, programming, or art work and have leaders focus on vital leadership tasks to get the best work out of people. If someone thinks they are a super developer who can lead people effectively and do work tasks, perhaps they can. However, this has to be a very special person who also makes sure their position as leader doesn’t affect people’s opinions of their work. I think this type of person may be even more mythical than a unicorn, though.
What are your thoughts? Do you think letting leaders focus on leading