Using independent teams to scale a small company: A look at how games company Wooga works

Jesper Richter-Reichhelm is Head of Engineering at social games company Wooga. Here he gives an insight into the firm’s internal organization.

At the end of last year, a document was published that described how Spotify works using a decentralized approach of tribes and squads. Since then, the article stuck with me. It made me realize we were not alone in this approach of fostering independent teams and with this article I want to contribute to the discussion and challenge a few conceptions.

I also want to explain that it is possible to have a truly agile work environment based on small, autonomous teams. It’s no small feat though, it takes effort everyday to keep this structure working smoothly. The following is a work in progress summary of how keeping teams independent can help scale a company, using my experience at Wooga as an example.

Wooga – now and then

Wooga was founded 2009 with a vision that by 2020, everyone will be playing games. Four years ago we had around 20 employees and now there are more than 250 employees from 40 nations all working in our Berlin office.

While that employee growth is a byproduct of economic success, in the process of growing it was a big challenge to not lose the company culture we had built. In the early days everyone in the company worked closely together and were not slowed down having to wait for approvals. Normally as a company grows this changes as management layers are added, and work simply becomes less efficient.

How did we hold onto that culture? The answer: centering everything around independent game teams. We had doubts about this approach, but we believed it would be worth the effort to at least try.

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

Teams are at the heart of how Wooga is organized. 70% 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.

Knowledge sharing

An important point is that even though teams are independent and compare KPIs, 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. It’s a good way to spread knowledge and start discussion throughout the company and increase networking. We have specialized meetups for backend development, frontend development, game design, business analytics and art.

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.

The brown bags are held in our auditorium area where our weekly company meeting takes place every Monday morning. It’s a 15-minute meeting where new hires get a warm welcome, company strategy is presented and announcements like game releases are made. It’s an important start to the week, and helps to keep everyone in the company connected and informed.

Cooperation

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.

Instead, private and public repositories emerge on github when engineers want to reuse code, but they also have the option to start from scratch. This is a conscious trade-off: we sometimes reinvent the wheel and repeat mistakes, but the company as a whole is much more flexible and innovative. Existing teams are not slowed down when new teams start and the overall communication overhead remains small.

Those who have heard the theory behind Dunbar’s number will know that group coherence will start to dissolve when it grows beyond 150 members. At Wooga we rely heavily on team members proactively reaching out to other game teams to learn from their experiences and be aware of what those other teams have learned in the past. To assist communication we grouped together teams into studios. This is a work in progress strategy but so far it looks good.

Being agile

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.

There are some constraints though:

• Teams work in weekly iterations and present progress and learnings in weekly meetings to the rest of the company.
• Small prototyping teams need to get a green light to develop a full game. A lot of prototypes do not pass this stage which allows us to play test many new game ideas in a short time. “Failure” at this stage is part of the process. Lessons learned from cancelled games are shared within the company.
•  All source code is available to everyone in the company.
• All KPIs and metrics are available to everyone in the company.

• We expect people to think and decide on their own using common sense. We try to avoid formalizing processes as the resulting rule book wouldn’t be flexible enough. There are some common principles to guide individual decisions and sometimes reminders are necessary but overall it works well.

Conclusion

I joined Wooga when we were just 10 employees in 2009. Over time the founders attitude to work lead to an organic evolution of the company based on everyone being responsible for their own work, their own team and ultimately their own company. Being independent and working autonomously are the common threads in every approach we take at Wooga.

This had lead to a culture where taking ownership is emphasized and expected. People are trusted to make the right decisions and they do make the right decisions most of the time. Of course sometimes people do make mistakes but since they don’t try to hide them it’s actually quite easy to fix things.

Header image: Carsten Koall/Getty Images