As a people operations manager at King Digital Entertainment, my mission is to allow the company to become the leading star of agile software development. I drive continuous improvement of HR-related processes and topics, ensuring that all engineers and teams have the support they need. One thing I do is to coach development managers so that they can help developers to grow and develop within or outside their areas of expertise. I also train them in agile leadership. Another thing I do is to show senior managers how self-organization and empowerment drives engagement and motivation.
King’s successes include Candy Crush Saga and the sister game Candy Crush Soda Saga, and the company needs to foster a creative and innovative culture with engaged and motivated people to create fun games that delight our users.
An environment with lots of freedom and trust – with space for experiments, exploration, and learning – makes people happy. Happy people are more likely to be open to new ideas, more cooperative, and more creative. This is crucial for a company like King.
It’s important to experiment, to be open, and to pay attention to your user’s needs when developing games. Experiments and exploration are also important when it comes to leadership and organizations, to give the people ownership of and responsibility for their environment. Don’t try for a perfect performance-management process or organizational design. Don’t manage people, manage the system and always recognize local needs – try small and scale out!
At King, I find a couple of experiments that support a creative and innovative environment good enough and safe enough to try – and worth sharing below. These experiments and lessons primarily come from the engineering organization at our location in Stockholm, and we have introduced some of them in other locations as well.
Development managers
King’s engineering organization in Stockholm is organized as a matrix with cross-functional game teams in the vertical and functions in the horizontal. We do not have fulltime first-line managers. A developer in each game team fills the role of primary line manager (we call them development managers) with a manager add-on that focuses on coaching. We aim for a split in which you focus on software development 80% of your time and on coaching during the other 20%. This is not set in stone but is a guideline.
A development manager leads three to eight developers, but we find that seven is the ideal number. Most teams have a producer to prioritize the backlog and to decide what to develop while the development manager focuses on personal growth and competence development.
Figure 1
The development managers are responsible for holding regular one-on-one coaching talks. Each has a team that is spread over different game teams in different studios (see figure 1). The development managers remain developers and typically their team members share a similar skill set so that the development manager understands the domain in which their team works.
Although spread out in the organization, development managers work as a community. All of them come together weekly to discuss what’s happening in different parts of the company, which allows them to identify issues and address them quickly. They have quarterly off-sites to discuss how they can support the business in the long term. With this setup, we shorten the paths of communication and support developers in the organization in the best way.
To support the development managers, we’ve developed tools and guidelines to make it easier both for them and developers to support an environment of freedom and trust:
- Ambition and Personal Plan;
- Team Awesomeness questionnaire; and
- Role Expectations Cheat Sheet.
Ambition and Personal Plan
Figure 2
Using annual goals as a way to motivate people and make them grow is extremely hard when the environment and the conditions are constantly changing. In addition, it's hard to identify issues and support developers continuously if you have annual goal settings. Fortunately, it’s possible to make the setting of goals and obtaining feedback more agile.
Within the engineering group at King in Stockholm, we use what we call the “Ambition and Personal Plan”. It all starts with identifying a personal guiding principle symbolized by a star.
We use Jurgen Appelo’s moving motivators to discover each person’s drives and intrinsic motivation. It’s easier to find your guiding star if you know what carries you toward it. It’s easier for development managers to give support when they know a developer’s drives and motivation.
When the developer finds a star to steer by, he or she then defines one to three ambitions for the first quarter that will lead towards the star. Then the developer decides upon actions necessary to reach these ambitions. Every second week, the developer follows up on the actions as part of the one-on-one conversations with his or her development manager, who gives support and guidance when needed. At the end of the quarter, the developer and development manager do a retrospective on the ambitions and define one to three new ambitions for the next quarter. This approach ensures good feedback loops and short iterations, which lead to clarity and no surprises in the developer’s personal development, and it’s easy to change when needed.
A developer owns his or her personal growth, with the assist and support of the development manager if needed. With ownership, a developer is more likely to be motivated and engaged to reach his or her ambitions and aim for your personal vision, the leading star.
The Ambition and Personal Plan format is inspired by Mike Rother’s improvement kata, in which the guiding star is the vision, quarterly ambition is the next target condition, and actions together with bi-weekly one-on-ones are the PDCA cycle. Finally, the moving motivators to find a developer’s drives are the current conditions.
To document the Ambition and Personal Plan we use a Google Docs document and an A3 format. The developer who shares it with the development manager owns the document. The graph in the A3 is there for the developer to mark his or her gut feelings about how the ambitions are progressing.
Here is a suggestion to structure the different conversations.
Guidelines for the follow up on the one-to-one (bi-weekly)
- How are your ambitions progressing?
- Have any conditions changed or is any hindrance preventing you from achieving your ambitions?
- Do you need any support or guidance?
Guidelines for the retrospective and planning meeting (every quarter)
- What do you think was your greatest achievement?
- What do you think was your biggest mistake?
- What do you think you need to change (or continuing doing) to stay motivated and perform?
- How do you think you have progressed towards your ambitions?
- What could I, as manager, have done to support you better?
- What are your ambitions for the next period?
We at King believe that if a developer has full ownership of and responsibility for personal development while the company supports your drives and intrinsic motivation, you will become more engaged. Engaged and motivated people are more likely to be creative and innovative in all they do – which, for King, is creating games.
Team Awesomeness questionnaire
As we give people ownership of their personal growth, we will also give teams the opportunity to take ownership of their performance.
A common goal for our teams is to strive to be a high-performance team that communicates and collaborates well both within and outside the team. In that spirit, we are testing a concept that I call “Team Awesomeness”. Generally, it’s a lightweight questionnaire, which the team answers together as an extension to the retrospective.
The team fills out a questionnaire with 25 questions divided in five different areas: contribution to King, contribution to the team, innovation, communication, and quality. The team members read each question out loud and then do “fist of five” voting. Those members with the highest and lowest votes should explain their choice. The whole team listens and discusses, then votes again, as in planning poker.
The team tries to reach a consensus on a score, makes notes, and then moves to the next question. After going through all the questions, the team should clearly see in which areas it needs to improve.
The first Team Awesomeness exercise takes approximately two hours. The exercise offers good input for an improvement theme. The team can also easily measure progress. Make sure the results are transparent for the whole team, and put the score on your Scrum/kanban board.
We don’t tell a team which methods or processes it needs to put in place to strengthen its weak areas; if a team, for example, finds that they need to improve quality, the company doesn’t tell them to fix more bugs or start with TDD. The team must find a solution that works for its members, so that they feel they own the quality – and as a result become more creative and innovative.
Here’s a real example. One team went through the Team Awesomeness questionnaire and found weaknesses in quality and communication. The members concluded that if they could improve how they communicate within and outside the team, the quality would most likely increase as well. They were right: the quality of the services the team provided to its users improved. Quality does not only arise from minimizing the number of bugs or broad test coverage. It also is about understanding a user’s needs and having the right expectations for the service or product that you provide – and this team showed that.
Role Expectations Cheat Sheet
At King, we want all developers to know what the organization expects from them, so we work with behaviors and expectations rather than role descriptions. It’s a more personal approach. We aim to provide clear expectations to each developer at a specific level, aligned across all King locations. The Role Expectations Cheat Sheet is a tool for discussing career and personal development. We also engage teams in the discussions around role expectations.
Figure 3
Role expectations provide a broader picture and make clear that developers are expected to do more than code; it is also about how a developer influences colleagues and contributes to the team and to King as a whole. The Role Expectations Cheat Sheet covers each level within engineering: junior developer, senior developer, and principal engineer. It describes each level within the following sections:
Overview: This is the overall expectation of the level.
In your role: This explains what is expected of you in your role, typically in your daily tasks.
Innovation: This explores how you contribute with new ideas or find new ways of working. It’s not only related to features, but also ways of working, improving efficiency, tools etc.
Team contribution: This looks at how much you contribute to the team/project goals and how you cooperate within your team.
King contribution: This explains how much you contribute to King’s improvements in general, e.g. helping other teams or other departments.
Personal development: This covers how you take responsibility for your own personal development and career planning.
Each level includes all expectations from the level below, but those have been left out of the document for brevity. “You write awesome code” is not listed on the Role Expectations Cheat Sheet for senior developers, since it's already on the sheet for junior developers.
Not all items are strictly mandatory for all employees. The intention of the checklist is not to determine if you qualify for the next level. Instead, the purpose of these explanations is to serve as a tool for discussing and clarifying what is expected of an individual developer at different levels. These discussions may be related to performance or career leveling and progress. Employees will have different strengths, but all may still qualify for the same level – e.g. some developers are super in game design while others are exceptional at server-side programming.
The intent is not to limit anyone from performing tasks meant for higher levels, but to make clear what is expected of you. For example, a junior developer is encouraged to coach and mentor other developers (which is something you'll also find at the senior level) but is not expected to consistently do so. As a developer works to progress to a higher career level, he or she is expected to increasingly perform at that higher level even before the promotion. A developer needs to show senior behavior before becoming a senior developer.
Having this list allows team members to more openly discuss their expectations for each other, and allows development managers and developers to agree on what needs to improve.
To maintain the role expectations as a living document, we need to continuously revisit the expectations and update them as needed. We encourage all developers and teams to discuss how to refine the expectations so that they remain relevant. The role expectations are for developers by developers.
To make sure the review of expectations happens and is owned by the developers, we have developers’ representatives or DevReps. The DevReps have their ears to the ground, so to speak. They gather feedback and thoughts on the expectations from the developers. This prevents the Role Expectations Cheat Sheet from becoming outdated and keeps it relevant to the developers.
It is, as in all we do, about the trust, ownership, and responsibility that create engagement and motivation, which leads to creativity and innovation.
The way forward
The experiments that we have done and that have succeeded support the initial hypothesis that “an environment with lots of freedom and trust – with space for experiments, exploration, and learning – makes people happy. Happy people are more likely to be open to new ideas, more cooperative, and more creative.” And that’s crucial to King’s position as the leading interactive-entertainment company for the mobile world.
We continuously need to improve and learn from our experiments. For example, having development managers spread out over several studios has some shortcomings. Sometimes a development manager is too far from the developers that he or she should support and coach and can’t see first-hand how the developers do in their team and so have to rely on second-hand information. Another thing that we see is that developers are sometimes confused about whether their development manager or producer is their manager. We are considering having development managers that support and coach developers within the same studio where they would work closely with the local producers and ScrumMasters, similar to the Potlac structure Spotify uses.
As King CEO Riccardo Zacconi says, “Failure is part of our business model.” Not all games will be great successes but we will always learn something from its development to improve the next game and it’s the same with organizations. Experiments will fail but if you can accept that and learn from them, you will grow as whole. We will always experiment, explore, and learn. That’s why we are a successful business.
About the Author
Matti Klasson is people operations manager at King. He has 17 years experience in computer engineering and has worked in agile environments for the last seven years. Matti’s role falls somewhere between HR and leadership in the engineering organization at King. He focuses on coaching development managers and taking an agile approach to HR-related topics such as performance management and goal setting. Matti is a Management 3.0 facilitator and find inspiration in complexity theory and system thinking. You can find Matti on Twitter at @mattiklasson.