Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Changing the project leads midway through the development is always traumatic for the team. But could we find the safest way to deal with it?
The scene goes along these lines: The whole team is gathered at the biggest meeting room, and the company owner or equivalent says “We're here to announce we'll be making changes on the team structure. Effective today Mr. Smithee and Mr. Doe will be reassigned to other tasks, and a new leadership group will take over. We believe a new approach will be beneficial for the remaining months of development. We want to sincerely thank the efforts of the former leads and bla bla bla...”
If you've been in the industry long enough, chances are you've seen this happen more than once. In the best case, Mr. Smithee and Mr. Doe will have another assignment in the company. But they can also end up sitting in a dark corner, sending resumes while they observe from a distance how their baby is being raised by others
The reasons for upper management making this decission can be multiple: Team's lack of focus, changes in upper management itself, down-to-up communication problems, successful back-stabbers... you name it. Let's not get into that too much. It just happens
However, that decision comes with a cost. Changing the keepers of the game vision will surely bring design or methodology changes at a critical time, increasing risks. Internal dynamics within the team will have to be rebuilt. Promises made by the former leads will be ignored and the confidence of the team in the company will seriously drop. Some members may consider to look for another job
If you weren´t aware of that, a jelled team is probably the most precious element you can have in game development. (If you didn´t already, I recommend to read DeMarco & Lister’s Peopleware.) External intrusions have all the potential to destroy that chemistry. In any case, these are traumatic situations that put valuable employees on the verge.
However, it is unquestionable that sometimes course correction is needed. We all know about projects that went beyond their money/time budget, weird game visions that needed a reality check, or simply the market changed during the development. In most situations, upper management HAS to act for the good of the project/company, or the consequences will be worse.
So the question is: Would it be possible to allow stakeholders to make such course-correction while not affecting the team's stability? Actually it is. It’s sort of happening in the industry already.
There are some companies that offer consulting services to game projects, making evaluations of the product, recommendations to make it better and even offering fairly accurate Metacritic score predictions.
Although it does provide a non-biased report and a course of action, those consultant services are optional after all. There is always the temptation of discarding their recommendations based on any excuse you find handy. And those companies don't work for free, of course
Now let’s take a look to an already established Ubisoft procedure. The company uses the role of “project closers,” fairly frequently on Assassin’s Creed developments in particular
What does a “closer” do? His involvement is either planned or expected, and he jumps onto the project in the last milestones. A closer overrides the authority of any existing lead of the project, can cut features, reduce scope and veto bugs. His ultimate goal is to finish the project no matter the cost
Mind that detail: The closer involvement has always been sort of expected. This is important for what is coming. Also, he/she is not a permanent member of the team, and the former leadership doesn´t necessarily have to feel aggravated by his involvement. It´s just part of the process and as such, not traumatic.
This approach looks promising but still sounds to me like an amputation-like solution. Something like: Dammit! Everything else failed! Well, no other solution than butchering out the affected leg before the infection expands to the rest. It’d be better to find a solution earlier
So, at this point the question is: Could we establish a development process that allows upper management to make leadership adjustments minimizing the impact on the team? Maybe we could. Let´s talk about “The Red Team”.
In “The Newsroom” series (Episode “One step too many”, Season 2) a group of journalists if chasing up a potential story related to the US army using sarin gas in Pakistan. They are completely sure of the autenticity of the material, but the risk of going live with it is too high. After all you´ll be accusing the United States of using weapons of mass destruction on allied territory.
Planning ahead, a group of the most senior members of the team have been deliberately left aside of this investigation so they can later become “the red team”. That way, they examine the facts found by the original team, and make an external veredict about if the story can be aired or not
So, here goes my proposal: What if we do something similar in the videogame industry? It could work like this:
A leadership team is assigned to project Alpha
This team receives a clear and understandable list of requirements for the game from upper management, and agrees upon it
A small group of senior workers are left aside of Alpha, most likely working on other projects
However, whenever it’s needed, they can be summoned to invest some of their time as the Red Team of project Alpha specifically
Alpha’s leadership can actually be the Red Team of other projects as well (Blue Team?)
The ideal number would be between 3-5 members. I would keep it as an odd number to avoid ties when voting
Also, the more interdisciplinary the Red Team can be, the better
In any case, it´s critical they are not involved in the project they´re supposed to assess at all. They need to feel perfectly detached from it. If in any sense they feel the project as their “baby” the whole process will be invalidated
Another key element is the qualification of the red team components. They have to be among the most experienced the company has. If they´re not, the team affected won´t respect their recommendations when they are formulated.
Finally, they need to be empowered by upper management to make any decision they feel it`s appropriate
Now, in which situations this Red Team could be helpful? I believe it could be these two:
Semi-external consultant - On each of the major project deadlines (end of concept phase, alpha, beta...) they will re-evaluate the stakeholders' requirements, see how the game is adjusting to them and make recommendations. This is not totally different from the elder council some companies have to evaluate their projects. Only more systemic.
Course-correction tool - The most extreme case, the Red Team takes over the leadership if upper management is seriously displeased with the results. Similar to Ubisoft´s closers anyway, but with a twist:
On each of the project´s major gateways, Alpha project is reviewed by upper management, and on each they can decide the Red Team to take over
Alpha leadership knows about this from the very beginning, and they´ve done their best to achieve the highest quality possible
It is entirely possible that Alpha progresses well and the Red Team is never requested to take over the project
Still, at any of those milestones upper management can decide course correction is needed
In that case, Red Team substitutes the former Alpha leadership
The former leads of the project become now eligible for being the Red team of another project, and so on
This Red Team idea is not a new concept, you know. You can check its entry on wikipedia and take a look at how it has been applied to other fields such as the military and even computer hacking. Still, I haven´t seen anything not remotely similar to this working in game development. So feel free to take it with a grain of salt, since it borders into what I call “management porn”
What would be the advantages of establishing this process?
As mentioned, being expected makes it less dramatic, and thus the frustration on the substituted leads and the rest of team members should be reduced. After all, although they`re not involved in the every day decisions, the Red Team is a planned part of the process and of the project nevertheless
The certainty of being “Red teamed” today but “Red team” others tomorrow also limits the disappointment
Upper management can use this process whenever they consider it appropriate, affecting dev teams in a less dramatic fashion than banishing formerly trusted employees
And on top of this, it could be a “Damocles sword” effect on teams that should foster constant improvement and quality
Now, what are the problems/risks? So far, I can mention:
Initially, such procedure sounds only possible for big companies running several projects in parallel. It´s also difficult for small companies to have a number of their best employees completely detached from one project
Depending on how often this process is applied, it can de-motivate project leads (“why should I put my heart on this if I´ll be replaced anyway?”)
Most of the validity of this proposal is based on the assumption that upper management has provided a clear and well-communicated list of high level requirements to the team. That way, such list can be followed up by any leads group. However, it is true that in most of the companies that I´ve been I never had such list and/or too many things were open to interpretation
And finally: Would there be a company with such confidence in their employees to know that sometimes things don´t work out but still trust them?
Looking forward to know your opinions
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
