The pros and cons of Blizzard’s development process

I’ll step outside the internet for a moment and talk briefly about my real life. Until about a year ago, I held a position in which I was responsible for managing and maintaining between 2 to 6 large projects and up to 30 employees. One of my core responsibilities dealt with project planning and controlling the scope of my various projects. As an outsourced vendor, our project commitments were to our clients and if we missed a commitment (or timeline) we were contractually at risk of losing out financially. If my team failed to meet project objectives and I failed to anticipate risks or respond to threats then I was held personally accountable. While I managed at most upwards of 30 employees, my teams all rolled up as part of a collective whole that included about 400 employees. I point this out only to illustrate the fact that I understand how to keep projects on task and how to use foresight and planning to anticipate problems.

It is from this perspective that I am constantly amazed by the things I hear from Blizzard developers. I’ve made no secret that I think Blizzard lacks foresight and planning, so I will freely admit that I have been looking for an interview like this one to cite some specific examples of why I think this is true.

When a Blizzard executive or developer gives an interview I am always struck by how free wheeling and unstructured the process sounds. Until now, I never had a lot of specifics to point out, just my overall impressions that things feel disorganized based on the interview comments. The example I gave the other day was that when a Blizzard dev gives an interview, I get the mental picture that they are all sitting around in a room smoking pot saying, “oh dude, wouldn’t it be cool if we had…”

Rob Pardo finally gave me the insight I needed to understand why this is the case. As with anything, people and process problems always start at the top. While I am being critical of Blizzard in particular, it’s not a stretch to say that these observations likely hold true across many (if not all) game companies.

---

Rob Pardo: We have an organic model for game development.

Organic is one of those corporate buzz words used to describe something that freely grows with little constraint. In this context, the idea is that there is a purposeful lack of definition in order to achieve a greater amount of flexibility. By contrast, something that is very structured and defined is by it’s very nature more rigid and restrictive. The upside of an “organic” model is that it allows for an unfettered creative process to continue through the entire development cycle. The whole idea of organic organization is just that -- we plant things and see what grows out of it. Organizationally, things are much flatter than a traditional company that has you, then your boss and then your boss’s boss and so on. Instead, decisions are made by consensus amongst peers rather through some military chain of command. The downside is that it lacks a cohesive vision, planning and foresight.

Rob Pardo: Everyone on the team has the power to veto. It's the team that's approving the game. If I veto something or approve something by myself it's only if the team allows it to happen.

While this process is certainly free-flowing and consensus building, it also lacks cohesive vision and direction. In Rob’s scenario, the overall direction of the project is spread out amongst the entire team, so the vision or direction of the project is diluted and shared rather than singular (or monolithic). Why is this problematic? Well, imagine that you and four co-workers are trying to make a collective decision about where to go for lunch. All of you share the same overall vision of eating, but each of you might be thinking of different places to go eat. Two of you really enjoy seafood, one of you hates it, and the other two seemingly have no preference or want something entirely different. Eventually, you’ll reach some kind of consensus, but will it be the best choice or just something that no one objected to?

A cohesive vision by contrast, brings everyone together in a singular direction. This helps people understand what they need to do and what needs to be accomplished. Instead of creating unnecessary tangents or distractions, they can work on fleshing out the vision placed before them. It’s the difference between lots of disparate unconnected ideas and a unified goal and direction. An unconnected idea may remain unfinished or appear out of place. A connected idea will flesh out the overall vision and bring more meaning and life to the overall project.

It also strikes me that consensus building through peers as Rob describes would favor a more evolutionary rather than revolutionary design process. Any idea that is dramatically different than the accepted norm is going to receive peer resistance regardless of whether or not the idea is good or great. Whereas, a single influencer or approver may see the bigger picture of such a change and be willing to take a chance on revolutionary design. In others words, it’s always much easier to convince a group of people to do it the way you have always done it than to accept a brand new idea.

Rob Pardo: On one of my games, I had one of my designers kept coming to me to approve stuff. I had to say, "Yeah, I like it, but you should talk to person a, b, and c, to see if they like it." He replied "But you like it, can't I just put it in the game?" I said "you can, but it's at your own peril, because if they don't like it, we'll go back and change it."

I really appreciate Rob providing this example because it pretty clearly illustrates what is good and bad about the organic model. It’s good because it’s consensus building. One person has an idea, but he needs to vet out that idea amongst his peers to see if that idea really fits with what everyone else is trying to accomplish. It’s also free flowing in that the process is not so constrained that they don’t have room for new ideas. However, such free form comes at a great cost and it explains why expansions take so long to develop and create issues like mudflation.

First, Rob’s indecisiveness costs the entire team time. Instead of simply making a decision, he delegates the decision to three other people. Now the designer has to meet with and convince three other people that his design idea is a good one. From a time management perspective, this costs not only the designer valuable time but takes away time from each of the three people he needs to convince. Alternately, he can work on it separately “at his own peril” as it may be changed back if they didn’t like it. Either result is far more wasteful from a time and planning perspective than if Rob had simply made a Yes or No decision or alternately delegated such responsibility to a single person responsible for that area.

Secondly, how do you plan for the future? By the very virtue of the organic model, even today’s plans are not really concrete or set in stone. You may have “ideas” about the future, but it’s not possible to execute any type of actual planning because you don’t really have a clear vision of where you are going. If what exists today is not even properly defined, how can you possibly plan for what you will do tomorrow? It’s impossible to think forward without a clear understanding of how things will progress over the foreseeable future.

sid67’s final thoughts
To be clear, I’m not against free form ideas or being creative. I’m critical of WHEN they are making these design decisions. There is a time and place for being creative and it’s in the planning stage. That’s why they call it a planning stage – because you paint a picture of what the end goal will become. It’s not important to fill in all the details, but it’s important to establish a cohesive vision of the end result. Once you establish this vision, then you can begin fleshing it out. You don’t just figure it out as you go along during the development phase. I would compare the process to how Pixar and Dreamworks animators storyboard a motion picture like Shrek or Finding Nemo. They certainly follow a creative process, but eventually they reach a point where the animators understand what story they are telling and how it should be told. THEN, and only THEN, do they start animating the story and see what works out.

It’s OK to be flexible. In fact, most would argue that the planning stage never really ends. However, once the vision has been painted then you need to start implementing process to control scope. On big projects, that means aligning people to specific areas of control or tasks. It’s just as wasteful to have every single design change need Rob’s approval as it is to need every single person’s approval or opinion. Accountability and empowerment are the pillars to successful management. Make people accountable to the collective vision, but empowered to do what is best for the game. It also means thinking about how a change is going to impact the rest of the vision and the timeline you set forth in your project plan. Game designers need to adhere to the critical path which is the earliest and latest that each activity can start and finish without making the overall project longer.

The other challenge with the more free flowing model is what happens when people quit? Many ideas often only live in the heads of those that are passionate about them. However, with proper planning, the vision and ideas don’t simply die when a person leaves the team. Instead, they live on and give the next guy a place to begin without losing much forward progress.

Without doubt, Blizzard made a great game in the original WoW. It took a long time and it mostly involved perfecting the ideas of others, but they did create something wonderful. However, while this organic model worked wonders for them as they developed the original game, I also believe that the same process hinders their ability to put out quality expansions in a timely fashion and creates a lack of foresight and planning that causes unforeseen issues like mudflation.

Before you release a product, your potential customers have little experience or expectations about your product. If you chose to change a fundamental design element, it sets you back time – but any change is transparent to your customer since they never even knew it existed any other way. If you have a broken mechanic, you just fix it. But once a product releases, well – now your product exists in the mind of your consumer and as the NGE taught the developers of Star Wars Galaxies, changes to your design post-release aren’t always well received. Moreover, your customers also begin to have expectations about new content and a six-month delay is a much bigger deal when your customer are paying a monthly fee.