Sponsored By

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.

Scrap the titles

Even though the individuals’ job titles seemingly only relates to corporate structures they may have a significant impact on how people communicate and work together.

Samuel Rantaeskola, Blogger

September 30, 2013

5 Min Read

Man in box

In Swedish culture, hierarchy is not as important as in many other places. Having grown up here, my view of organizational structures is of course heavily influenced by that perception. I would like to think that I value opinions equally, no matter title of the person. Or do I?

In a series of posts I would like to discuss some of the problems with mimicking your project structure in your organization chart. This one is going to focus on my view of job titles.

When talking to people outside of your company, it does make sense to have a title that describes what your role is. It makes it a lot easier for people you are talking with to understand who you are, and what kind of decisions you can make. However, that title should disappear as soon as you step inside the doors of the studio. In internal discussions it is not a benefit that a title may add value to your opinions, the only thing that should matter is your skill set.

To understand the problem with titles we need to go back a number of years in game development, to when all game teams were recruiting experts within a single area. And organizations were typically divided into departments according to discipline. Labor within a discipline was funneled through the lead into the departments. In those structures, single area expertise works very well.

With the movement towards cross-functional teams, where team responsibilities are bigger, the single area expertise no longer works well. I am not saying that you do not need the experts, but if everyone is a single area expert it is very difficult to build successful teams. The number of dependencies between the teams will be very high, and one of the goals when building cross functional organizations is to set up groups that have all the tools they need to solve the problems at hand. Each dependency on another team will slow the group down.

Instead of only experts there need to be a lot of people with broader profiles; that are skilled in more than one area. You want people that can model, light scenes, rig characters and so forth. The funny thing is that any small indie developer consists of people like this by nature; they just do not have enough people to cover all the areas of expertise that is needed to build a game. However, when the organization grows this tends to get lost along the way. Why is that?

I think it all starts in the recruitment process. When an imminent need of a skill set is discovered in the team it will be described as a title, and recruitment starts to look for a person that has that specific skill set. When a person is hired he will be given the title in the job ad. Even though the recruiter was clever and actually looked for a person with multiple skills, the title he is given essentially boxes him in into one skill set. This title will now affect how he is perceived in conversations, assigned to teams and also personally affect what kind of work he feels is within his domain.

Projects change over time, so does the responsibilities within them. Do you want to recruit a new person every time a new responsibility is discovered? Perhaps you realize that there is a person within the team that can take on the responsibility. Should you change the title then? Should he be assigned under a new boss?

We once counted the number of titles we had at my previous employer of about 100 people, it was more than 30. There were a lot of people that had multiple talents, but they were all described with one skill set. This caused two major problems for us:

  1. It was virtually impossible to build cross-functional teams as the titles cemented the old departmentalized structure.

  2. People could say: “That is not within my job description.” which is a valid, but it does not add to the greater good of the team.

For me, solving these problems was very important for the team to become better. Unfortunately, we never got anywhere with it. With some perspective on the problem, these are the steps I would have liked to take to attack the problem.

  • Reduce the amount of titles to as few as possible. Can you even take it as far as Game Developer is the only title you have?

  • For people that are working in outward facing roles, titles can still be there, but that’s just for the business card.

  • In large teams, it's good if people have an awareness of the available skill sets. One way of solving that is if everyone on the team list and grade their skills at an internal wiki or similar.

  • When recruiting people, prefer people with multiple skills over single skilled.

  • Job ad titles should describe the main responsibility for the person you are looking for. However, it should be made clear in the recruitment discussion that it’s not the title the person will have in the team.

Doing all the above things might be a step in the right direction, but the single most important thing to do is to explain to everyone why titles should be simplified. What the assumed benefits are and how it will affect everyone. Without the buy-in from the team, it might just be perceived as another management fad, like this one:

Dilbert strip

(this post is also post at http://www.hansoft.com/expertblog/how-to-improve-communication-by-removing-titles/)

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like