Psychochild's Blog

A developer's musings on game development and writing.

6 June, 2016

Should leaders do hands-on work?
Filed under: — Psychochild @ 9:23 PM

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.

Divided loyalties

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.

Disconnection

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.

My thoughts

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


« Previous Post:





3 Comments »

  1. This is one of those things that has been an issue my whole career. The Silicon Valley startup ethos expects everybody in eng/dev from the founder on down to be a hands on, technical contributor first. That works in a small group, but over a certain size, having nobody focused on running the circus leads to chaos. I am one of those people who tries to fix chaos (I get agitated and start organizing things), which tends to land me in some sort of leadership role, which in years past has tended to put me in charge or meetings, bug reviews, schedules, on top of what one might consider my “day job.”

    At one job that actually led to me ending up in middle management, in part because nobody wanted the job, and in part because there were the only two career paths upwards, the company lacking any sort of broad technical advancement track. You could become a manager (one per group) or an designer/architect (one per VP run division) and that was it. The company was acquired by an out of state company and I ended up high enough that being a direct technical contributor was no longer in my job description.

    And then I got laid off with my whole division, from VP on down, and tried to find another job in Silicon Valley, where I quickly found having spent just two years in a non-technical role made me “just a manager” and of no value in the valley. Fortunately I had just enough contacts left who actually had jobs to find another individual contributor position. It took a couple years there before anybody would look at my resume.

    But when I was up there and vying for a director title (I was doing the work, I just wanted the recognition, but then came the layoff) there was no way I could have run projects, listened to my teams, kept them happy, fought their battles, got them the tools they needed, protected them from really stupid plans, AND been an individual contributor. I was staying late every night just doing the manager stuff. But I know from friends and jobs listings that managers are often expected to be contributors first and managers second.

    Of course, there is a flip side to that. I have worked with any number of managers, directors, and VPs who have become so divorced from the day to day technical aspect of the group, who haven’t written a line of code in so long, that they have lost any feel for what any given technical task requires and whose only contribution to projects seems to be bad news, unrealistic deadlines, and saying things like “work smarter, not harder” as they leave at 5pm while we’re all still working away in our cubes.

    Comment by Wilhelm Arcturus — 7 June, 2016 @ 9:49 AM

  2. I don’t think there’s a clear “yes” or “no” answer to the question. Ideally, a leader should understand what his team are doing, which in a technical field may well mean coming from, a technical background. He needs to avoid micro-managing, which is really tempting if you think you know how best to do the task, and needs to avoid getting stuck into the detail at the expense of watching the bigger picture. He’s probably being paid more as a leader than he would be as a hands-on programmer, which implies that doing the leadership thing is more valuable to the employer than being just another programmer.
    On the flip side – the leader should be a part of the team, and sometimes everybody needs to pitch in to get an urgent task completed. Sitting back and not helping because “I’m a manager now and that’s not in my job description” won’t get you very far in a corporate environment, let alone a start-up. On the GRIPPING hand… most of the time, you can actually do more to help the team by going to bat for more resources or a change in scope or deadlines, rather than pitching in as one more code monkey.
    So I guess the answer is – leaders can do hands-on work, but not at the expense of actually leading. It’s good for morale for the team to see the leader pitch in and help, as long as he actually IS helping, and breaks down ‘us vs them’ mentalities. But it shouldn’t be at the expense of them carrying out their primary responsibility as a leader, which is to take a wider view and direct and support the team’s efforts to best effect.

    Comment by Tremayne — 7 June, 2016 @ 12:18 PM

  3. As with so many complex human problems there isn’t a right answer. There are so many variables that change outcomes enormously. There’s also a lot of fog – someone may simply be a bad manager.

    It very much scales. To look at the extreme if you have a 1 person company and that person spends all his time “managing” and not creating then you have 0 productivity. If a manager in a large company neglects a decision that affects the productivity of thousands of other people to do some hands on that’s clearly an error.

    Some of the problems you mention can be solved by good time management practices. Eg “I’m available from 8-9, from 9-12 don’t bother me unless the building’s on fire, I’m available from 12-1.” Getting people used to emailing problems rather than rushing in in person also helps. But then again there may be contexts where that doesn’t work well, if the manager is perceived as unapproachable anyway then having a closed door approach makes that even worse.

    Regarding career choice I think it’s very interesting what Wilhelm said – that moving out of a technical role caused him seen as “useless.”

    If a programmer or game designer does decide to take a management position it’s probably best looked at as a career change. If you swapped careers to architect you’d figure out how to design buildings, maybe do some courses. Same with management.

    Handling these transitions is itself an element of management and if you’ve seen it done badly in the past ask yourself who managed those processes and what was their background?

    Comment by Stabs — 8 June, 2016 @ 3:40 AM

Leave a comment

I value your comment and think the discussions are the best part of this blog. However, there's this scourge called comment spam, so I choose to moderate comments rather than giving filthy spammers any advantage.

If this is your first comment, it will be held for moderation and therefore will not show up immediately. I will approve your comment when I can, usually within a day. Comments should eventually be approved if not spam. If your comment doesn't show up and it wasn't spam, send me an email as the spam catchers might have caught it by accident.

Line and paragraph breaks automatic, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Email Subscription

Get posts by email:


Recent Comments

Categories

Search the Blog

Calendar

December 2017
S M T W T F S
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Meta

Archives

Standard Disclaimer

I speak only for myself, not for any company.

My Book





Information

Around the Internet

Game and Online Developers

Game News Sites

Game Ranters and Discussion

Help for Businesses

Other Fun Stuff

Quiet (aka Dead) Sites

Posts Copyright Brian Green, aka Psychochild. Comments belong to their authors.

Support me and my work on