Someone must take responsibility for the game's overall direction. If there are multiple programmers, someone needs to set up some technical standards and practices, handle decisions like what libraries and tools to use, and so on. Artists, sound engineers, musicians, and even managers themselves face similar challenges.
So how do we know who to put in charge of a team? There's a few different options. Today I'm going to look specifically at technical/programming leads, because it's been on my mind a lot lately. (Plus, as a bonus, that's the area I'm most familiar with - meaning I have a better chance of sounding competent.)
First, let's introduce the players in today's little drama.
Leadership by Seniority
This is a fairly easy choice: the programmer who has been around the longest gets the job. The unspoken assumption is that this person will have the most experience and therefore the greatest pool of wisdom to draw upon when making decisions.
Leadership by Inertia
A common place to see this is in dying, overly bureaucratic companies where the culture places a huge emphasis on things like status, org charts, and so on. Essentially, someone got made a tech lead once for some reason, and that became his title. With that, he's been a tech lead ever since. Shuffling the org chart to give him a more appropriate position is too much of a pain, so he stays in the position, usually regardless of ability or genuine qualification.
Leadership by Committee
Dangerous dragons lurk here - in this variant, there isn't actually a team lead; everyone pitches in their opinions and votes on decisions. Although the democratic veneer may be appealing, this is rarely a good idea, for reasons we will explore shortly.
Leadership by Cabal
This is a lot like leadership by committee, except the people making all the decisions aren't officially in any position of power. They just sort of form a de facto cabinet that runs the kingdom. It is common for this form to arise when the official tech lead is especially incompetent.
Leadership by Qualification
This is the gold standard, the one we all wish we could see, but hardly ever do. This is like winning the career lottery - lots of people try, very few succeed. In short, leadership by qualification is when you get a tech lead who is a really brilliant manager, and handles his people exceedingly well.
Wait a minute... did you say good manager?
Now for the punch line: a good tech lead's technical skills are a distant secondary concern.
Yes, he's going to be working with programmers. Yes, he needs to know how to evaluate libraries, toolkits, and so on. Yes, he needs to understand the architecture of the game and even possibly build parts of it himself.
But when it comes to picking a great tech lead, you don't want to pick the best programmer in the house. It's tempting and may seem obvious, but it's a mistake.
First of all, you want your best programmers doing what they do best - programming. Managing a team takes time and effort, and that time and energy is limited - it can't be spent on programming and management simultaneously.
Secondly, being a brilliant programmer has no bearing whatsoever on one's management skills.
The Shootout: How to pick your tech lead
Leadership by seniority is a bad option: it ignores the important point that programming is not management. I personally have 16 years of programming experience, and zero years of management experience. If I were to enter a shop where everyone else had, say, 10 or fewer years of programming experience, that in no way means I'm the best candidate for technical lead. I'd rather work for a tech lead with 5 years of programming and 10 years of management than vice versa.
Inertia is also a bad option, for hopefully obvious reasons. If your place of employ has a track record of leaving people in poorly fitting positions for long periods of time, it's time for you to change your organization or change your organization.
So we've knocked down two options... what about a committee? That way, we can get input from all the management-experienced people, and all of the programmers at the same time! Perfect!
Well, except for all the flaws. Committees mean meetings, and having a meeting every time a decision needs to be made is wasteful. Secondly, it introduces complex dependency chains - every time work needs to be done, people must go through the "tech decision committee". It will inevitably take longer to get a decision from a group of people than from a single point of authority, which slows down your entire production process.
Committees also have a tendency to settle towards least-common-denominator results. If everyone is on equal footing when discussing a decision, then it can be hard if not impossible to push for improved practices or decisions.
Consider a poor schmuck named Joe who is a really great software designer. Joe is stuck on a team with no single lead - all decisions are made by a committee made up of Joe himself and four other programmers. Now Joe is passionate about his work - he reads constantly, does outside projects to improve his skills, and is always concerned about producing maximum-quality work. His coworkers, on the other hand, are just there to punch the clock and cash the paycheck.
Suppose Joe wants to change from waterfall to a more agile development approach. He has four other voices to overcome on the committee. Who do you think is going to win that discussion? Joe's the new guy - he can't convince the old-timers that there is a better way. Even if he gets one or two, they're likely to compromise with the unconvinced committee members, just to get the decision made faster.
So committees aren't really a good choice.
Cabal leadership isn't any good, either. By nature, tech lead cabals are not formed by official sanction; insead, they arise out of necessity in a dysfunctional environment. A good way to recognize the existence of a tech lead cabal is to observe the difference between what the official lead says and what actually gets done.
If the real results are worse, there's no cabal - just incompetence all around. If the results are even par, the cabal is either wasting their time with inflated egos, or doesn't exist; more than likely everyone is just toeing the line and secretly wishing they had a cabal. However, if your tech lead is making specs and decisions which are quietly overturned for better options, you can bet you have a good infestation of cabal leadership going on.
It can be hard to fight the tendency to form cabals, especially if you're a member. Well, Bob the tech lead isn't going to give in anyways, so let's say screw it and just go do our own thing. Every month or so we'll straighten up for a while, just to keep Bob content, and never push him over the edge to where he makes us stop.
However, this is a toxic way to work. Anyone on the team who isn't aware of the cabal, or doesn't follow their leadership, is going to introduce complications. Some code will be good, other bits poor. Standards will be broken and conventions applied inconsistently. Decisions will be haphazard and lacking a unified focus.
Worse, cabals tend to engender bitterness and resentment. Ironically, some of the most bitter people can be found at the top of the cabal's hierarchy, where people are under the greatest pressure to both try and keep the project afloat, and not step on the toes of the "official" leadership.
Last Man Standing
So we've had our shootout and pretty much decided that all forms of management suck. Now, don't break out your Anarchy bumper stickers just yet - there's one method left that works pretty well: let the most qualified guy be the technical lead.
You would think this would be an obvious choice, but it rarely is. For one thing, defining who is most qualified can be a serious challenge in and of itself. Then there's the matter of displacing someone in favor of the new candidate; this can easily spell disaster if not handled carefully and with great consideration for the opinions and feelings of everyone concerned.
There's a billion articles written already about what makes a good technical manager, but here's my personal checklist:
- Up to date on technology and industry best practices
- Competent enough with programming to know how to resolve disagreements over how to implement things
- Familiar with every aspect of the code base
- Capable of getting people to do what he wants, like adhere to standards and practices
- Strong communication skills - nobody can be a great lead without talking to people, constantly and in depth
- Attention to detail
- Uncompromisingly dedicated to quality - never willing to let "little things" slide if they undermine code quality and/or maintainability
- Highly organized - can keep track of all the details that arise in any nontrivial development project
- Cares about the success of the team
Push for the best leadership you can get. You owe it to yourself and the rest of your team. Just be gentle - leadership roles are (unfortunately) often tangled up with egos. Be sure you approach the matter from the perspective of what is best for the team as a whole. Anyone who prizes his own ego or status above the success of the team probably needs a pink slip anyways.
If you don't already have a single, nominated leader, gather up a meeting of your entire technical staff and nominate someone. If you have a tech lead above you, make sure you kindly suggest things for them to do to help their leadership style. Never go over anyone's head if you can avoid it; don't go up two layers on the org chart and complain about your boss.
Lastly, if you're in a position to have a tech lead below you, arrange a meeting with the lead himself and all of the staff he supervises. Encourage everyone to air their concerns and suggestions.
Then be sure to act on them.
Change is not a four letter word
The final idea I'd like to leave you with here is that change is not a bad thing. Changing your tech lead's habits for the better is always a good thing. Even changing the person filling the role can be beneficial.
Never fear pushing for change, even if you're on the bottom of the hierarchy. So long as you can argue successfully that your suggestions are for the greater good, you will be fine. If you get fired for trying to improve your workplace, then chances are you're better off some place else.
For those higher up on the chart, remember that your job is to keep the lower levels of the team hierarchy working smoothly. Getting overly set in your ways is dangerous, especially in a business that moves as fast as game technology. Be open to fresh new ideas - being open just means willing to listen and act, not necessarily that you have to take on every single suggestion hurled your way.
The biggest problem that businesses can have is adapting too slowly. The rest of the universe is changing, with or without you. If you don't change along with it, you'd better be ready for extinction.
