In games and application development, there is a never ending struggle between cost and quality. Every company and every team has analyzed what the best formula is to propel a product forward. Some companies will waffle between the two extremes: push for top notch quality above all else, and then after some internal change, push for the lowest possible cost with less regard for top quality. I think that there is a lot to be learned from smaller companies in this regard, as they typically have fewer resources to play with, and tend to have less interference from executives that do not have ground level knowledge of what needs to be done.
In a larger company, a configuration like the following (very simplified, and quickly put together I might add) is often seen.
Like I said, this is simplified, but can give a basic understanding as to how a product is made in a big company environment. Very little direct interaction on each level with one another, dotted line reports to the person ultimately running the project, and pools of resources that likely have little stake in the product itself. In fact, when we get to the bottom layer, these are often people that are cycled from project to project on an ongoing basis, may not be based in the same region as the Product Owner, and ultimately do not have any real “stake” in the success of the product. This is especially true in the case of the QA Testers who are often young, getting paid little more than minimum wage, and are increasingly being based in a low cost location to keep cost down. This can also add additional layers (such as a Project Lead between the Test Lead and QA Manager) which muddies the waters even more.
(Also note that this simplified chart does not bring into play additional branches like publication, certification/standards, marketing, etc…)
In my experience, every product is best served if thought of as a living, breathing entity. It is best served by a dedicated team of people that work closely with one another, with everyone, from the Product Manager to the QA Tester, all having a shared stake in the success of the project. Instead of treating each team member as something of an outsourced individual, by making each person dedicated to the team and the product, you get a considerably stronger level of involvement, a higher level of overall dedication and quality of work, and a greater level of personal satisfaction. By reducing redundancy and keeping your team together in one location (whether we are talking in a single office, or across the world), you can ensure much better communication, coupled with a more direct method of addressing issues and potential pitfalls.
Now, imagine a team built more like what is more commonly seen in smaller companies. Something like:
(Again, forgive the simplistic flow chart. By the way, it was made using Google Docs, which is actually kind of cool).
It gives you a smaller team, with less management overhead, people communicating far better with one another, and has all the principal contributors reporting back into the product owner, as well as each other. It also keeps the team dedicated, instead of sourcing from a large pool, giving each person a greater level of experience with the product as a whole, as well as much higher level of personal involvement.
Naturally, none of this is new. None of this is my idea. None of this is radical. The difference we have right now is that big companies struggle to work this way. Instead of making the product the central piece of the work environment, there is a tendency to silo talent and keep them separate. This usually has something to do with internal configurations as well as departments.
This is really just my first forray into this line of thought. I’m not saying that this is the answer to every issue that game teams encounter, or that this is the right fit for every company. This is just some food for thought based on my experiences. This doesn’t even touch on development methodology or approach costs and cost savings, but I think is an approach that warrants a look in the big company environment. By keeping your team focussed on your product, by employing experts rather than random resources, and by ensuring that the team works together rather than as separate wings, I think you will see a quality improvement. I want to look into this a bit more in the future, not only this particular piece, but the idea that big companies need to look at some of the better practices of their smaller counterparts. I think there is much to be gained from examining those that have fewer layers, and seeing how some of those day to day operational ideas can be adapted.