The Missing Ingredient: Personal Investment

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.

graph2

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:

graph1

(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.

Advertisements

4 thoughts on “The Missing Ingredient: Personal Investment

  1. I’ve never worked in a game development company, but from my software development experience, management layers are always trouble like you’ve noticed. It just means people are wasting time thinking about organizational structure, instead of thinking about how they can make the game better (or faster if that’s the preference). It definitely won’t solve every issue, but it will mean people can focus on fixing the issues instead of worrying about job titles and reporting lines.

  2. While there are certainly differences in game and software development, it’s been my experience that a best practice is a best practice, regardless of the end product.

    Management layers can be effective, leadership is definitely important, but the overall structure of what you are doing needs to support this. I find it gets troublesome when a larger company starts to think in terms of internal structure and departments, as opposed to a more product specific approach. Anything that doesn’t actually support you launching a successful product tends to be waste, and even worse can stifle the productivity of key contributors.

    • You’re right, leadership is essential! And leadership comes from those who care about the product and the people, not from those who are thinking about power and to control people. Management that supports the people doing the work is fine but management that tries to control them will just, as you identified, stifle creativity and slow everything down.

      • Excellently put! Management for the sake of management does little. Management that is not attached to the product, yet manages people that are can very often lack the insight and understanding to be truly supportive.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s