 |

|
 |

| |
Opinion: Key Principles For Coping With Game Team Meltdown
by Brenda Brathwaite [PC, Console/PC, Columns]
|
|
| |
|
December 29, 2008
|
| |
[In a new Gamasutra opinion piece, Wizardry and Jagged Alliance veteran and game design professor Brenda Brathwaite analyzes how you can stop the rot by "talking up" when game development teams have relationship or management problems.]
Games are intensely personal processes, even if they involve a hundred people. You can’t spend eight hours a day with a work of art and not get connected to it.
That connection is born of intensity, and that intensity can lead to people getting upset with one thing or another. Sometimes, it can lead to team meltdown. Here’s a couple moments from my memory:
- An art team mutinied -- they didn’t show up for work for a few days (it may have been longer, but it definitely wasn’t shorter).
- A team walked out -- the whole team left the office and refused to work until the crunch hours were addressed.
- A lead dished all his issues with the company to those on his team effectively creating a group of angry programmers.
- Two executive producers worked to sack an incompetent VP.
These are extreme examples, of course. Usually, it’s pockets of discontent, but these pockets can completely wreck productivity and make unhappy people out of otherwise content developers. It makes people hate a project, hate their part in the project or, at best, feel indifferent.
For those involved in the trash talking -- and maybe unbeknownst to them -- it follows them throughout their career in several potential ways:
- Teams suffering meltdown don’t make great projects. If they somehow manage to get a good one out, the project is not as good as it would have been if the team had been working well. That game stays on your resume. It lives with you through mobygames.com. Eternity is gamerankings.com and a bad game.
- Bad relationships are built, and bad relationships have a long, long shelf life in the game industry. They stop you from getting jobs. They keep closed doors.
- Patterns are made and history tends to repeat itself.
Clearly, everyone’s not always going to be happy, though. So, you have to figure out a way to deal with it. I was a lead for a long time, and this is the kind of situational training you never get. You pick it up on the job. If you’re a "bridge builder" now, if you get along with everyone, if you can genuinely see a way forward in even difficult situations, be grateful. You will use it dozens of times in your career.
On these issues, a couple things have worked for me:
Do not "disbelieve."
Acknowledge that problems will exist in the future, and develop a plan to deal with these things before they strike. Encourage people to talk with their leads, and encourage leads to listen and not criticize or immediately fix it to death. Sometimes people need to vent.
Talk up, and tell people on your team to do it.
If you have an issue with something, take it to your lead. Don’t trash the waters around you. Give people a chance to adjust things, including your perspective. I recently talked with someone who thought he was getting the run around because his boss wouldn’t level with him about an upcoming contract. “I just want to know if we’re going to make the game or not.” My feeling was that his boss genuinely didn’t know. No deal is done until the money’s in your bank account.
If you have a problem with someone, their work or the way they work, talk to them directly, if that seems at all possible to do. Sometimes, it’s a matter of misunderstanding or needing to clear the air.
If that’s not possible or if there’s a company issue that’s driving you insane, talk to the the person immediately above you (unless it is the person immediately above you). Also, remember that it’s probably about 50 percent less dramatic than you feel it might be, but only time will give you that perspective.
At the time, though, just accept that some part of how you’re feeling is reaction, not reality. If you are the person above another person, remember the "drama modifier," but listen and let them vent it all out without interruption. Venting is a valid and important part of the development process, and a good lead learns how to receive it and handle it well.
So why this emphasis on talking up? If you have a problem with someone and talk laterally or down, you are literally trash talking your own team and killing your own project. I’ve seen it happen one too many times as noted above.
The team quickly loses respect for the chain of command and nothing ever gets fixed since no one in a position to fix it was ever actually contacted. People continue to complain about the lead above them, but the lead - blissfully unaware of anything - keeps right on going. Meanwhile, the team falls apart, morale plummets, productivity drops and the quality of work suffers dramatically. Ultimately, your project sucks, and if it’s a professional project, it’ll follow you around for years.
So, don’t trash your lead to the people below you. Don’t trash fellow leads to other leads. If you have an issue with someone, take it to them directly or take it to the person above you, and do it professionally and without drama.
Ultimately, this is about principles, not personalities. When irritated by someone, ask yourself if it’s their work or them. This is game development, not a reality television show. You don’t have to like everyone. You don’t need to play Rock Band on the weekends. You merely need to work with them well and for the betterment of the project. Develop professional discipline to do this now, and it will go a long way for you.
[Brenda Brathwaite is a contract game designer and professor of game design at the Savannah College of Art and Design. She has been in the game industry since 1981 and has shipped 22 commercial titles. An an avid player of games, she currently spends an absurd amount of time studying them.]
|
| |
|
|
Your opinion piece is a well-stated course on communication 101 that should receive plenty of appreciation.
You can only lead a horse to water, however, and it is up to your target audience to decide if they need to or want to follow your course assignments to their healthy-and-logical end.
You are addressing an industry that has largely been able to survive and even succeed without the requirement of communication etiquette.
Maybe you will consider a follow-up opinion piece, entitled "How to Enhance the Performance of Your Industry Even if You Think It Ain't Broke and You Don't Wanna' Fix It," where, inevitably, you provide in-depth, tangible examples of where your thinking has succeeded, within your own company or within other well-known industry entities.
And, if you do write a follow-up, consider that everyone in your audience is from Missouri, the "Show Me" state. In this day and age, time is money, and communication-and-sensitivity training has been left on the side of the road.
In this vein, in a sincere attempt to attract more attention to the subject, I have two articles to offer up that accurately and collectively address much of what you have touched upon here.
"B3 Is Key: Better Training, Better Products, And Better Returns"
http://www.emscharf.com/genuinearticle/genuinearticle_2008/genuinearticle_2008_0
4.htm
"Transforming the Games Industry into a Well-Oiled Machine"
http://www.emscharf.com/genuinearticle/genuinearticle_2008/genuinearticle_2008_0
5_01.htm
Thanks, again, Brenda, for writing on this subject.
I've been having many such talks with my superiors. Sadly, there's no way for me to know for sure, whether or not I've been fair with them. But I do believe I've always given them initial credit of trust, and I've been always taking precautions against destructive criticism (such as, I try to formulate my complaints as predictions: "if we keep doing this, then this and this is going to happen", and then I see if the stuff actually happens). And I believe I have a decent right-to-wrong ratio. I can translate some of those predictions into potential savings, and these seem to be way above my salary.
And I'm unemployed right now, because out of four full time jobs I've had to date (one magazine and three game development studios), three ended with me being fired for complaining, and one ended with me basically firing myself, because I took the situation within the team too personally.
Only some 5% of those talks resulted in the merit of complaint being considered (with varying outcomes, naturally). Obviously, there's something I'm doing wrong.
So how do you deal with a person whose only reply to any complaint or doubt is "I'm the boss, so shut up" or "you're stupid, so shut up", or "I've been doing this for twenty years, so shut up"?
How do you deal with people who perceive any complaint as an attempt to undermine their social position within the company?
How do you deal with a lead whose standard reply to any complaint is "I'm just doing my job, so stop giving me trouble"?
How do you deal with a lead whose standard reply is: "you're right, but the project lead will never agree to this, so why bother"?
How do you deal with people who refuse to consider any issue, because they are convinced someone will sabotage their efforts eventually?
How do you deal with people who oppose anything that would force them to change their habits? For instance, I used to have a lead, who insisted on having everything discussed face to face but kept forgetting his own conversations, including the decisions he had made. In spite of this, he refused when asked to send his requests and decisions via e-mail, on the grounds that it would be "unnecessary bureaucracy".
How do you deal with people who acknowledge the problem, but reject the proposed solution without considering it, and then fail to provide any solution of their own?
How do you deal with people who refuse to consider an issue, because either "we haven't gone bankrupt yet, so we must be doing it right", or "we're not doing very well right now, so it's not a good time for changes"?
How do you deal with coworkers who refuse to talk about their issues, because they think it will get them fired? What do you do when those fears are well founded, because the company has a history of firing people for talking about their issues?
How do you deal with people who simply don't care?
The answer to all your questions is "Find a new job."
You think I am kidding? If you have a problem with management who does not listen nor wants to listen or change, that company is doomed to failure. If you are working in a place that would rather fire someone than listen to a complaint, that company is doomed for failure. If the atmosphere is so bad that people are literally afraid to voice their opinion, that company is doomed for failure.
The scenarios you describe are not anything that anyone should be working in.
This article describes basic office communication that should be present in any company. All the places I have worked outside the games industry have had this as an integral part of the employee handbook. It is common management sense. If your company does not have it, you need to leave.
Honestly it will look better for you if you quit now rather than get fired later. Most people don't ask questions when you quit, but they will if you were fired.
Well, quitting and getting fired is exactly what I've been doing for the last several years. I've gotten to the point where I'm starting to look unreliable in my potential new employers' eyes. In fact, I'm starting to look unrealiable to myself.
Even worse, I'm running out of potential employers. There are three game development companies of note in my hometown right now. I had already been employed by two of them. The only other studio of note, located in a different town, has such a bad reputation that even some of my friends from outside the industry have heard about it.
In short, quitting is no longer an option, unless you have a few million euros and a willingness to found a new game development studio in a middle-sized country on the eastern fringe of the European Union. All I know is I can't afford to go indie, let alone create a full-sized team.
Some issues I mentioned are extreme, and there's probably little you can do about a boss who just wants everyone to shut up. But others aren't that serious and I refuse to believe they cannot be solved constructively. I just don't know how to do that.
Communicative values are set by the leaders of the projects. If they aren't on board, the barriers are much more difficult to break. But if the precedent has been set early on in the project, these hurdles are much easier to overcome. I truly believe in daily vertical and horizontal communication between team members and more importantly between teams. The moment the programmers feel that they are being dragged down by the 3d artists, or vice versa, and they only talk about amongst each other around the water cooler, that energy festers and multiplies until you get said meltdown. Most of the negative energy comes from a misunderstanding or just complete ignorance to the other side. But if the project is a collective effort, communication is open, and leads are perpetuating the art of communication, the machine becomes well oiled.
That being said, there will still be the inevitable problems, arguments, and bad air, but these will be quickly brushed aside with an open forum. This is where producers show their true worth as mediators to the many disagreements and sacrifices each team harbors during the project. There will also always be a lead, or a higher up that just doesn’t get it, or is too focused on their own problems/career to care. These are types that need to be included in the open discussions so they can see – because many times they are unaware or in denial of where some team members are mindset-wise. I know that I’m diving all over the place here but this is a subject I feel that is understated and sometimes completely overlooked in today’s landscape. I take pride in leadership and communication and feel that if a producer hones in on those two aspects, the project moves much more smoothly.
This industry lacks people have a natural ability to lead positively.
Perhaps my advice was a little harsh, but it is often the best and only solution. I do understand the position you are in. Limited Job potential is a hard thing to deal with.
But the problem most likely lies with the lead end of the communication here. I am making the assumption that you have been trying to voice your complaints without any kind of negative or belittling tone. That your concerns are being conveyed with all sincerity. But you are being stone walled in your efforts.
Some of your scenarios sound like the management wants to run things their way and no one else's. That is extremely bad. One of the traits of a great leader is the ability to accept criticism and change. Without it, they are driving their company/team to ruin.
Other situations you describe sound like you have a sympathetic ear with the lead, but lead is being stone walled by his superiors. Same situation.
The situation with the manager who insists on face to face contact is probably the most damaging of all your scenarios. He is purposely avoiding a paper trail so that he can play dumb when things go south. The purpose of a paper trail is so that you can show that they were aware of a situation but let it continue. He does not want to be held accountable for his actions.
I want to avoid giving career damaging advice. It really is not my place to tell you how to approach your bosses without any knowledge other than what you have said.
If your really feel that something is important and needs addressed with a superior, either get it in writing or have a witness present. If they refuse t oput anything in writing at least you will have someone else who can vouch for you.
As for the lead who didn't want to write e-mails, I think this particular person was genuinely convinced that written communication is evil. However, I've encountered many instances of "playing dumb" on part of more than one superior of mine, and I agree it creates huge problems.
There is plenty of advice for prospective leaders. Communicate with your coworkers in such and such way. Approach problem employees by doing this and this. This method works better than that one. There are no universal solutions, because there never are ones when living people are involved, but there are best practices.
The problem is that most people aren't leaders, and there doesn't seem to be much theory on the topic of "how to be a good employee". This results in people doing things mentioned in the beginning of the article. I've seen something like this happen, once. A whole team declared it wasn't possible for their project to be completed before the deadline they were given. The project was cancelled soon affterwards.
This is bad! We don't want projects to be cancelled. We don't want companies to go bankrupt. We don't want bad games to be created. We want everything to go smoothly. But most people simply don't know what to do when they're facing a difficult situation involving their leader. So they endure leader's failures until either the company falls apart or they loose patience.
There are ways to handle an underperforming programmer, or a designer who's doing a bad job, but how do you handle a clueless leader? We can assume that you don't, but since we've already established this dooms the team to failure, I'd call it a prohibitively costly solution.
Also, props to Ephriam. I agree with your advice entirely.
Jacek,
The suggestion to find a new job is a good one but it is of course the last resort. When you simply cannot handle the insanity that comes with working under people who are (presumably) less skilled or talented or have less ability than you do, or continually make bad decisions, then sometimes its best to move on for your own mental health.
Unfortunately, all the issues mentioned in your post are realities in some capacity within most creative industries if not everywhere. At the end of the day you are getting paid to do what the boss tells you. Yes, they may have hired you for your skills or experience, but not for your opinion. At the end of the day the employer pays the bills. If they want to ruin a project, or run the company into the ground then that is their business. As long as you are getting paid and not getting abused in some way, take a deep breath and do your work. In a creative work environment you will constantly find yourself at odds with those giving the orders because most of us feel we know what is best.
Here are two points to keep in mind:
1. Suck it up--especially if you are early in your career. You need jobs on your resume. Do your best with what you are given. Chances are that if a project or company fails, other potential employers will have heard about it and not fault you personally. As mentioned in Brenda’s article, word will get around if you are a pain to work with as the people you dislike may have a lot of friends in the industry who actually like them. I have a friend whose experiences sound a lot like yours and he is suffering for it.
2. If you just can’t take it then you had better start formulating a plan to work for yourself. After four jobs where it seems that those running the show did not know what they were doing, it sounds like you might know enough to be the boss yourself :-)
Thom
It depends on what you mean by negativity. Negativity in a narrow sense of always assuming everything is being done the wrong way is essentially one's failure to meet one of basic requirements of any job based on teamwork. It's harmful, it's dangerous, and should not be tolerated.
Negativity in a broad sense of being sceptical, or critical, or even cynical, or simply worried, is practically the only countermeasure against developer hubris. Hubris is the more dangerous of the two, because it's not mitigated by general goodwill.
The need to be polite and considerate is universal. Whatever you're doing, it's always better to do it gently, possibly with the exception of trying to shoot someone.
I don't mean to say I disagree with the article. Quite countrary, I couldn't agree more. I do agree with the main point, which seems to be that you should report your issues to your leads. One particular situation when this seems especially valid is inter-team tension (as in programmers having problems with artists). Resolving this kind of issues usually involves delicate mediation, and is best done by someone "in between" rather than a member of one of the teams involved. Producers, project managers, and project leads are naturally suited for this, because they are involved with all teams, and at the same time they belong to none of them. And they have the authority to execute the solution rather than just propose it.
The problem I see with all this is heavy reliance on leadership. As soon as someone turns out to be a poor leader, everything starts to fall apart. I've seen teams heal by themselves, without formal leader's involvement, but the way it happened was that someone stepped in as a de facto leader. This is project hijacking and no sane person will accept it as a standard course of action.
The issue of poor leadership cannot be simply discarded as a pathology, because formal leaders are often chosen according to different criteria than leadership skill. How this happens is a very broad topic, so let's just say many people perceive becoming a lead as a step on their personal career path. They see it as a privilege reather than responsibility.
This is one of reasons why I'm a big fan of distributed decision structures, such as feature teams. Not only do they help against control freaks of all flavours, but they also force people to talk to people unlike themselves. When you complain to your close teammate, they will just smile and nod, because their point of view is the same as yours. Talking to someone of different specialty is often an eye-opening experience. Do it on a regular basis and empathy levels will shoot through the roof.
Only now have I realised that I haven't made one important thing clear. I don't want my leads to agree with me. I want them to listen to me. Then they can disagree all they want. In fact, I would be happiest if they proved me wrong every single time, because whenever they do that, it means they've taught me something new.
But how do I make them listen in the first place?
Besides, creative control is one thing, but there's also technical supervision. When someone wants you to build a kitchy house for them, you suck it up and build it. But when someone wants you to build it upside down, it's your professional obligation to know better and tell them so. That's what you're for.
one option in your situation, besides of leaving the job, is to talk/write to your superior's superior. If the situation you have described is true, it has to be seriously damaging the performance of the team. Then you need to talk to someone who is concerned about this and has a direct responsibility - most likely to someone who is directly economically hit by this (sometimes this can be a top manager, sometimes perhaps even a company owner, board member or a shareholders). Once a person in such position feels the concern, it can act on it - the action may be trying to change the manager's behaviour, or even to change the manager (such things happen).
Of course, if no one at such responsible position shares your concern, it means a dead end and if the situation is unbearable to you, there is little you can do but quit the job, which I understand can be very hard, as in your situation it can mean either to quit the gaming industry, or to move to a different country.
Thanks for all the advice, I really appreciate it, but let's keep it in a perspective. I gave you examples from personal experience, because it seemed like a better idea than trying to make something up. It just so happens that I've encountered a set of rather extreme cases. One company I used to work for did indeed have all these issues combined together, but it's currently in the process of falling apart, just like you suspected. They have lost some 30 people this year, and another 15 or so in 2007.
Most studios aren't that bad, far from it. You can expect to encounter one or two issues from the list, but not all of them at the same time. Typically, you won't be inclined to quit, if only because it would be unreasonable to expect any job to be perfect. It would be far more productive to try and do something about the issue, preferably in such a way that nobody gets fired, nobody gets angry, there's no unnecessary fuss, everyone lives happily ever after, and so on.
So imagine you're a programmer, for example. And you've gotten this job in a great studio where everybody is very nice and competent, and the First Person Shooter you're developing looks very promising, the concept behind it is just groundbreaking, and the salary is good, and they haven't had a crunch for three years straight. But! As far as you can tell, the game's concept is such that it could really use advanced AI. Maybe you could even apply one of those fancy adaptive algorithms. But the engine you're using only supports scripted events and a small set of basic actions. It won't do. Or at least that's what you suspect.
So you go to your lead, an industry veteran who can code with his feet while blindfolded, makes really funny jokes all the time, and has already shown you a few neat programming tricks you weren't aware of. But he's old fashioned. He's been developing first person shooters for fifteen years and he's always been making do with scripted events. You can't get him to talk about AI, because he just doesn't believe in the concept. He didn't need it for the last fifteen years, so why would he need it now?
And you can't take it to your lead's lead, because that guy is primarily a graphic artist and he can't tell AI from I/O. Whenever he has a programming related problem, he just leaves it to your own lead, the old fashioned veteran.
You probably don't want to quit, bacause it's your dream job, but to the best of your knowledge the great concept behing this game is going to fail without new AI.
How do you resolve this issue?
Thanks for the detailed scenario. That is a good example. Also, I was trying to keep things hypothetical before, but did not want to sound like I was giving too much career advice.
Before I go on, I would like to point you to this website: www.thedailywtf.com This website has a lot of stories similar to yours and often the comments have some great advice for dealing with those kinds of bosses.
But back to your scenario; So you want to improve the AI and the lead wants to keep it the same. You tried to talk to your boss about it, but he won't listen and his superior doesn't have the technical background to fully comprehend your proposal. I hope that sums it up all right.
Here are some questions to ask yourself in this situation:
Did you explain the pros and cons of both his AI solution and your AI solution?
Did you provide examples of other games and their sales performance for each game AI system?
Are the people you talked to the actual designers for the game?
Is there possible time, budget or other external constraints that would prevent your AI solution from being implemented?
These are just a few possible questions. The goal is to come prepared with every possible question or concern already answered and ready to be shared. There is no point to making a suggestion or raising a concern without fully understanding the situation. It is also important to avoid a sales pitch or presentation with these sort of requests. You don't want to come off as pushy either
But if come prepared and make an actual discussion of it and he still does not accept your solution/proposal, then it just won't happen. But at least you planted a seed for the next project. If on the other hand and he is as you say just set in his way and will not budge even a millimeter, Well not as rosy of an outcome.
Jacek - Your candidness is rather refreshing. :) The only thing I would say in response to your question about the scripted events versus adaptive algorithms is this. As a 'manager' I have to admit that I would go with the lead because a successful track record is one of the most important things in this business. The credibility that comes with a successful track record is extremely hard to ignore and imho should not be ignored. Personally, I see technology as a means to an end (I learnt this the hard way from programmers who were far more experienced & they turned out to be right).
If I were you I would probably work on a small demo that effectively acts as a proof of concept for my ideas & then show it to my lead. Nearly every programmer I have worked with or managed is always interested in knowing how things work and learning something new. I would code this demo in my free time without letting it affect the work assigned to me in my job. If my demo works as expected then I will have earned the respect of my lead & this will also have a highly beneficial effect on my future professional career. If not I would have learnt something new.
I know this calls for a time commitment beyond the call of duty but this (imho) is one of the better resolutions for this situation.
"overtime" being built into a schedule. Frustration truly comes in when someone, most likely not dealing with overwhelming hours makes the decision for X number of people. If there was an actual cash or monetary direct link to each decision perhaps the decision would be more carefully considered and analyzed. Just my 2 cents.
Generally, the goal is to get to the point where the matter at hand is being considered in a factual manner. The exact form of discussion depends on the topic being discussed. In case of a programming issue, some kind of software engineering practice would probably be in order (such as a requirement analysis). Schedules, budgets and sales predictions should also be taken into account at this point - obviously, this is a vital part of "considering" any major development decision.
Let's assume this is an ideal scenario in which everyone is doing what they do best: programmers do the programming, artists make art, designers design etc. I've seen teams in which design (or a poor excuse thereof) was being done by people incapable of thinking in terms of interactivity, but that's one hell of a headache in itself, and probably a subject for a whole book.
So, no, the lead programmer isn't doing any game design per se, only the technical design of the underlying software.
1. What if the project leader is also the lead designer, actively participating in day to day design work. Since he's primarily an artist, he thinks in terms of things he wants to see happening on the screen. He doesn't understand how these things are being implemented. The lead programmer is going to try and implement project leader's ideas with scripted events, even if it means three times as much work for everybody, because he strongly believes that's the way to go. Would you rather try insisting on considering procedural AI, and risk looking pushy, or would you rather wait for the old method to fail? When this happens, do you wait for the lead programmer to draw his own conclusions, or do you remind him of the procedural AI? How do you make sure it doesn't sound like a case of "see, I told you so"?
Note how this dilemma involves balancing an actual loss of money. If you consider the new AI thoroughly before starting to use the old one, it will probably take a week or so, but you will be fairly confident about your final choice afterwards. If you wait until something breaks, it may never happen at all, but if it does, you will have lost a month, or three, or six, or a whole year. I've seen two instances of something like this happening on a larger scale, and the loss of effort was 90 and 300 man-months, respectively.
2. What if the project leader is only responsible for the vision and general principles of gameplay, while the bulk of day to day work is being done by a team of junior designers. They are expert users of their content creation tools, and they understand how game design interacts with technical features of the engine. Do you muster their support in order to prove to the lead programmer, that the proposed AI suits designers' needs better than the old one? Or do you wait for designers to start complaining about inadequacy of their tools? Note that you're a programmer in this example. It's not your job to specify what features the game needs to have, and you can't pretend to be a designer yourself.
Sachin,
I see your point, and I'm not surprised you would go with the lead. However, I think this contributes to the problem, although it's by no means your fault. A manager, or the project leader from my example, cannot be expected to have good understanding of every specialty. That's just too much knowledge for a single person. In the result, the higher in the hierachy you are, the less you can do about issues with technical background. "Talking up" ceases to work at this point, because you're unable to consider an issue if it has a technical component. And most issues do. You have no choice but to take someone's word for it, even if that person is actually wrong.
Going with the person who has better track record is much better than choosing randomly, but it's only efficient as long as the problem is purely technical. And most "sensitive" issues aren't. In my example, the lead programmer is a great specialist, but his personality interferes when one particular technology is being brought up. As a manager, you stand very little chance of knowing about that. He won't tell you "oh, I just don't like procedural AI, because my dad forced me to build finite state machines when I was a kid". Instead, he will tell you "AI is a waste of time, and that guy just reads too much science fiction".
Another problem is that there's only so much you can do after hours. I don't think it's reasonable to ask anyone for a proof of concept that takes more than 20 hours to create. Anything above that, and you're essentially starting to ignore your coworkers who have a life beyond work: small children, education, some pet project, a time-consuming hobby, etc.
Creating an AI system from the ground up is no simple task. In some cases it could take 20 weeks. And that's just a simple case of a problem that only involves a single branch of your team. As a designer, I've often been in situations in which trying to prove something required me to ask a programmer or an artist for help. Obviously, I cannot ask a coworker for 20 hours of their time. I can only ask for 20 minutes.
Its extremely difficult to precisely understand & predict human behavior / choices, this is one of the great difficulties in any predominantly human enterprise, not just software/game development. Getting to know the team, their strengths, weaknesses, personality traits & biases usually takes some time; not just for the manager but for every team member. Again each individual comes with their own bias or perspective so it is "their" assessment (which is bound to be somewhat subjective) & this makes things very complicated.
Its very difficult for me to say exactly how I would deal with ths issue because I wasnt managing that team or that particular lead programmer. What I can say is that I would have reacted very differently if there were
1. Other programmers who had expressed similar views on this issue or some other technical issues in the past
2. I had heard about / personally experienced situations in which this lead programmer had been shooting down other people's ideas / suggestions without giving them sufficient consideration or explanation in the past
3. The potential impact of this technical choice on the project schedule & perceived risks were not very high (for example procedural approaches 'may' result in some degree of unpredictability, increased debugging time & require a lot more testing). Are we talking days, weeks or months? Do we have that kind of time in the schedule?
4. Work involved getting either approach to a 'usable' stage - Say there already is a scripting language with strong debugging capabilities that has been used in past shipped titles and designers are very comfortable with this scripting language. Or maybe there is a game editor where events can be set up easily. Game systems like AI usually need to be reasonably flexible & easy to use so that designers can build good gameplay using them, hence there are several considerations beyond just implementing the system. Better tools & more iteration usually lead to better games
So if I were you in the same situation I would try to garner support from other team members (fellow programmers maybe?) & then talk to both the manager & lead programmer together. I think most project managers love innovation on their projects (its a potential differentiator, can be creatively rewarding & offers opportunities for 'chest thumping' :)) but 'innovation' & 'risk' are usually two sides of the same coin, hence they tend to be careful.
My basic point is that if you believe in something you do your best to make your point; and dont give up if you arent heard the first few times because people eventually will start listening if you prove to be right.
I fully understand that creating an AI system from scratch is not a trivial undertaking. Maybe you could focus on what seems to be the biggest technical hurdle in using that particular approach & come up with a solution for that (rather than build an entire system). Treat it as an intellectual challenge & solve it. :) If that doesnt get you the trust & respect of the lead programmer then clearly the lead programmer is not a very good leader (though he may still be a very good programmer). Then let the management decide whether they want a good leader or programmer (or ideally both).
Obviously, I dont know if what I am proposing is practical since I dont know the situation or people firsthand but I am only trying to offer some possible solutions.
Casillas, your comment is right on.
For the situation the article's dealing with, the advice works.
It's not so effective for someone actually in the trenches, and as someone else mentioned, you have to have credibility before you can genuinely make a difference.
Besides, all these articles are always addressed to lower and middle management. Nobody ever bothers to have some good advice to the "general staff". Treat it as my pet peeve, if you like, but I've seen huge amounts of money being lost because of "general staff" being treated - and feeling - like interchangeable parts of some industrial machine.
As for credibility, it's something you earn the moment you pass your job interview. Someone first decides you know your trade well enough to be given a job, and then *assumes* you don't know how to do your job. So why did they hire you in the first place?
Another example - In business would you invest money in a company that has an exceptional track record of growth & proftability built over several years OR a startup that shows potential if they are both offering the SAME returns?
Experience, "Paying your dues"..whatever you choose to call it brings its own perspective & "value"...Those who choose to overlook the value of experience may not be wrong but I am pretty sure that in 10 years time they would agree with one thing..."More experience leads to higher credibility".