Wooga Effectively Utilizes Teams When Creating Game Apps

Wooga Effectively Utilizes Teams When Creating Game Apps

Wooga is a collection of many small, independent teams. Each team is responsible for making and running a single game and is expected to make their own decisions while being cross-functional and autonomous. They should freely share learnings and don't compete with each other, meaning they effectively act like small, independent start-ups within a larger framework.

It's completely up to them if they want to listen or ignore outside advice—even if it's from one of the founders. This is only possible by having great people. So, hiring the right people is the single most important thing we do at Wooga. We believe in the mantra, “If in doubt, don't hire.” That works very well. Teams are at the heart of how Wooga is organized. Seventy percent of employees are working in a game team. There are departmental heads, such as the Head of Engineering, of which we have two, who take care of different parts of that field, and others that look after their respective departments.

The rest are providing central services like marketing, customer care, and localization (20%) or others like HR, PR, Finance, Business Analytics, and teams that maintain simple services for persistence of games. “Service” is the key word here—those teams serve the game teams and not the other way around. For example, there are no artificial budget processes and game teams can decide release dates themselves.

Each game team is led by a product lead that has the final decision for the team. This ensures a fast decision is always possible and the company can scale without top management becoming a bottleneck. In essence this is a delegation of power from central management to the teams. This starts with the type of game a product lead wants to make and ends with the way the teams organize themselves internally.

Teams start small with 1–3 people, with the first always being the future lead and providing the initial concept of the game. They develop a prototype that can be reviewed and, most importantly, play tested. If it's not good enough, the team starts afresh. If it looks promising, the team is ramped up slowly, keeping it below 10 people for as long as possible.

After going live, the team size can remain stable or be increased. Further feature development does not slow down the development process, but as extra information is derived from live metrics, a/b testing becomes possible and the whole game needs to be operated. An important point is that even though teams are independent and compare KPIs [key performance indicators], they do not compete with each other. There is a constant exchange of knowledge and lessons learned between them. This is how we leverage the innovations made by individual teams (and compensate risks individual teams take).

On one level this is done by each team being asked to provide a 5 –10 minute weekly meeting where they report their progress to the rest of the company and explain their learnings, which could be from something like previous a/b tests or new feature announcements. There are no limits or off areas regarding which information can be shared, as long as others can benefit from the information. Also, these meeting are open for every employee to attend. This way we can try out new things in one game, and when they work, that knowledge is spread to other teams. This works quite organically.

Another level of knowledge exchange is between members of the same discipline. We organize monthly internal lightning talk rounds called “5 minutes of fame” where anyone in the company can give a short talk regarding something they want to share, and everyone can attend these talks. Whenever a topic is too complex to handle it in a lightning talk, we do brown bag talks. This is a lunchtime talk, where participants get a free lunch after the 25-minute talk. Half of the company usually attends these talks, of which we have about one per month.

Since teams are cross-functional, there is a wide range of skills to utilize, and good teams organize themselves with members working closely together. Again, the idea is not to have a single person knowing and deciding everything but making it the responsibility of every team member to push the game forward.

Teams themselves are autonomous and do not depend on other teams to create and run their game. As a result, teams do their own analytics while using a shared service provided by the Business Analytics service team and a few standardized KPIs. Similarly, there is no operation/admin team to operate the servers or other parts of infrastructure. Those who write the software operate it themselves. Engineers are not forced to share or reuse code, so there is no central framework that everyone must use.

We think agile development is not about applying a specific methodology, it is about following the correct principles and to constantly reflect on whether you are aligned correctly and to correct things when necessary. As a result, there is no unified process on how teams should develop their software. Teams decide on their own how to do things, although they usually blend in elements of Scrum and/or Kanban. That means stand-ups in the morning are the standard, although variations do exist.

The company also has a unique view of using monetary performance bonuses. Co-founder and CEO Jens Begemann told Fast Company that monetary performance bonuses promote internal competition. He believes that this would in turn undermine the collaboration among team members and across teams that is needed to generate great products. Instead, the company uses shares of stock as incentives to motivate employees to care about the greater good of the company. This seems to be working because the company has experienced tremendous growth in the last few years and there is very little employee turnover .

Questions:

1. Are the product development teams at Wooga more of a group or a team? Explain your rationale.

2. What does Wooga do to promote cooperation and cohesiveness among their product development teams?

3. To what extent are Wooga's teams subject to groupthink? Does the company do anything to prevent groupthink among its development teams?

4. What is your opinion about the company's view of not paying performance bonuses? What are the pros and cons?