Building High Performing Teams

Andrii Dzynia at UXDX Community: Stockholm. Video: https://youtu.be/-oGgi2m_Org

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and the Fiction Factory team

[00:00:14] Right, so I'm going to follow the hydrophone[?] team. I would like to skip the introduction part about our company, because we've talked about the company already, and everyone knows the famous games that the company has built over the past years. What I want to say about myself is that I currently work as an engineering manager, working with many people, and that's the main focus of this talk. It's less about UX, less about the project, and more about how we work as a group of people.

[00:00:52] A quick show of hands. Unfortunately I didn't join you from the beginning, so I don't know your backgrounds or what you work with, but I just want to have a check so I can adjust my talk based on what your interests are. How many of you here are product managers? All right. Developers, engineers, test engineers? UX specialists? All right. Anyone else? You can just say: managers, VPs, directors, like that. How many of you work in a team? Okay. I also work in a team.

[00:01:38] My team is called Fiction Factory. That's an internal name used in King. What we build: we are responsible for the internal game engine. It's the underlying technology that is used to build all the live games at King, and we develop the runtime part of the engine and also the editor for the publication[?]. I can show you a sneak peek of what the product is. Our team is almost 40 people, currently 38, and it changes in size from time to time for different reasons. We are split across three sites. We're in Stockholm, which at the moment is our biggest site, and in Malmö and Barcelona we have a few people, a few engineers.

[00:02:25] At the moment the King game studios are split much more widely around the world, so it's not only those three locations. Our customers, the users who use our technology, are across more than three locations. For us it's five or six, maybe even seven locations in total. That's how we operate.

[00:02:50] The size of our development teams is typically small. We try to keep it to the minimum possible level, because what we've found over time is that it helps to maintain the best kind of glue and cooperation, and it's also easier to manage. If you get a team which is bigger than five or seven people, it's a bit trickier to manage in terms of processes and other aspects. So development teams are two to four people, and we try to avoid people working by themselves. There is no one-man project; we try to avoid that as much as possible.

[00:03:20] We also have a dedicated first-line support team. What we call first-line support is the team which reacts to customer requests. For example, imagine you are an artist or a game developer who works with our product, and you have an issue with how to create an animation, or a workflow, whatever. First of all, you reach out to first-line support. The first-line support team consists of QA, people who can quickly troubleshoot, and it consists of developer relations people, typically called developer advocates or artist advocates. Those are the people who help educate people on how to work with the product: developers, the people using the graphical product to do animations, and sometimes artists. Those artist advocates are experts in how to use the tool, so they can educate people on how to use it properly to solve a problem. And we have a release manager, who helps with releases.

[00:04:20] We have a few more roles that I didn't have enough space to put in. We have a product manager, and we actually have a UX specialist as well, and we try to figure out how to work practically in that area. I won't be talking too much about how we work with UX, because it's not something we can be proud of at the moment; that's something we are going to improve. But what we've been working on is reducing overhead and micromanagement. What we worked on in the management team was building up an environment which fosters continuous improvement, and creating a culture where every voice is heard and every point of view is considered. That's what my talk will be more about.

[00:05:01] The way we manage this process, we think of the classic project management triangle: people, process and product. This is classic project management. What we also think of is wellness. It's one of those parts that is typically missed out when you see a corporate management style. I'll briefly walk through each of those.

The product and managing expectations

[00:05:24] Speaking of product, our product looks like this. This is the graphical part of the product. It's desktop software which you can run on macOS and on Windows, and some people also try to run it on Linux. It has some crashes there and it's at a lower quality level, because not many people use it. This product is only internal, so it's built for people at King who build the games. It's not something exposed outside. I got approval from my senior director to show you how the product looks. I won't be able to show you the entire product, videos and so on, because it's confidential, but the product is something you can think of like Maya[?], if you work with that, or Unity, the tool used to build games. It's very similar. You can think of it as a 3D modeling tool, and it also has the runtime, which is the game engine itself, which helps to run the model you build on the desktop in the mobile apps. When you play Candy Crush, the game is running on it to render all the details of the animations and the different textures. That's the graphical representation of what we work on.

[00:06:42] When we work with this product, we keep in mind two main aspects. One is how we manage expectations from our users, from customers and from our sponsors. By sponsors we mean the people who have a primary interest in making this project a success. We work at King, a big organization. It's 2,000 people overall and has different products, games and so on. The product of my team is a technical product which empowers all the game products to be created, but we also try to think of our tool as a product and try to manage it in a similar way. That's why we go through similar processes.

[00:07:39] We brought in a product framework which helped us manage the expectations of the different parties. We have mission and vision statements, agreed and published, so all users can access them and take a look. We have the product roadmap, which is a list of the features we plan to release and at what point in time. We split the time by quarters, so we can say: this is what's really part of the product now, and this is when that feature will be released. We established certain parts of the process. I won't be able to go into much detail, because it would take a lot of time, but feel free to ask me questions afterwards, and I can share a bit more detail of how each part is practically implemented.

[00:08:28] To connect more closely with the user, we do a customer survey. From UX you might recognize the process. It's a powerful way to keep a health check on how our customers feel about the product at a given moment in time. We might ask the question: how easy is it to work with the Fiction Factory editor? How easy is it to do a certain workflow in the editor? We talk a lot about workflows. When you build a game, there are different types of workflows: you do some animation, you change the texture. There's a list of different workflows you can do, and we try to get the feel of how easy certain functions in our product are.

[00:09:10] We try to encourage as many users as possible to come and join our meetings, for example when we do team planning, where we try to plan ahead what we're going to do next quarter or sometimes next sprint. Sprints are typically two weeks. Different teams have different regularity for sprints; we don't enforce a structure. It's a very open environment.

[00:09:34] We try to get customer validation of our ideas as early as possible. For example, if you have an idea to make certain changes in the graphical part of the modeling tool, say we want to introduce a resource browser to organize the different resources, we make a proposal. Sometimes this graphical interface looks like a really simple mock-up; you can just draw it on a whiteboard, or make it in a mock-up tool. Sometimes it might just be at concept level: we have this idea, we're going to do this, are you okay with it, or are you not sure, or do you want us to do something else? We take it to them very early, because what we know from the past is that if you don't take this into consideration early, you end up with a product which nobody wants to use, and then you have this strange expectations relationship you need to manage. In order to avoid that problematic situation, we try to build the right product.

[00:10:31] Also, when we do the launch, when the feature is done, we never release it at once, even though it's an internal product with around a hundred customers or a hundred users who work with it. We never release it as one big bang. Because what we know from experience is that if you release it as one big release, you might receive so many issues that you need to address right now, because people want to use it. In order to minimize the risk of delivery, we do it gradually. We say: okay, today we work with Candy Crush Soda, for example, and this team is going to use the new version of our engine as the first team. We put the efforts of our first-line support team into dedicated education and bug fixing as it comes, so we can get proof that the new version of our product works as expected. Then we move on to the next team and the next team, until we can roll out to the entire company.

Deep dives, game jams and Fiction Fridays

[00:11:30] As I mentioned before, the game teams are spread across more locations than the three where our team operates. For those locations which are outside Stockholm, Malmö and Barcelona, we do an activity called a deep dive. A deep dive is typically a week[?] where a few of our engineers come on site to the location and do courses, education, support, answering questions, maybe some hacking together, testing ideas. But basically it's to establish a better relationship and better communication, because we work in a cross-located company.

[00:12:04] One of the other things we do that affects the product so much is a game jam. A game jam is a one- or two-day activity where we say: okay, stop everything you've been working on, just forget about it, and build a game using our tool. Sometimes we do it within Fiction Factory, in other teams; sometimes we do it with some other game teams; sometimes we do it on different occasions in Stockholm, Malmö and Barcelona. We try to mix it, to find inspiration and ideas.

[00:12:34] Game jams are one of those things which many game companies are famous for. Some of you who work in a game company might have something similar, because in the community it's very common to have a game jam. When it's a game jam day, don't expect any work to happen unless it's an emergency, or a bug fix that is stopping the release. Typically, if you see a game jam happening, nobody would believe it's a working day. Everyone changes, and we build games. And what we discovered is that in the process, users of the tool open up the product differently. We have this perception that when we build it, it has been tested, but most of the time it's tested on a small scale, in a samples project where we test it. When you try to use the product for, say, a new project, you get an entirely different workload, you get entirely different issues, and those issues help us to un-bias ourselves in a way. Now we understand how our users work much better, and how the people trying to use our tools, not only to maintain but to run them for a few years, work. We discovered most of our issues from this initiative. This initiative is one of the key aspects for us to get feedback on the tool and eat our own dog food. Sometimes we call it a provocation.

[00:13:57] The other activity that we do in the team we call Fiction Friday. It's very similar to what other people might call innovation days. It's 20% time for the entire team, and in practice it's two days every second week[?]. For example, today is Thursday, and today is Fiction Friday in my team. Some people are doing actual work, because they have some deadlines or some pressure, a production issue that needs to be fixed. But if you don't feel constrained by external boundaries, you are expected to work on innovation.

[00:14:40] Innovation means that, in Fiction Factory, using the product, you work on an idea which later can become a full-fledged feature. For example, you might have an idea: okay, I want to add this flag which the users were asking me to add every single day when I talk to them, so now I want to sit down and actually implement it. But it doesn't mean it will be released on the same day, because we need to follow the release process, which we'll talk about a bit later. The process itself helps us create the innovation required for a team to always keep improving. We have a backlog of ideas from these innovation days, these Fiction Fridays. They are discussed internally, go into the product conversations, pass through a few stages and become part of the roadmap, and once they become part of the roadmap, they need to be delivered as planned. So Fiction Friday for us is a funnel of innovation, if you think about it. It's the pocket where we receive ideas, and then we implement those ideas later, when we can prove them and they seem to be worth it.

Process: releases, production meetings and ways of working

[00:15:49] The next part is process. I mentioned to you how we release. In essence, how we think about the release process is that we try to attend to our users' needs as fast as possible. For example, if a user comes with a request, hey, I have this issue, it's crashing, we can make a release quite soon, on the same day if it's stopping production. But typically our release schedule is set in a way that we release the runtime every second week, and we release the editor part of the engine every quarter, one release per three months.

[00:16:31] The reason we did so is because our users were complaining that if we do releases so often, it's hard to keep up with the changes. If you were in a consumer company, you'd want to release as fast as possible, test ideas and keep updated. But in our context it's an internal product. We don't need to release everything all the time, because every time we release, we need to onboard our users in our own way. That's where our developer advocates, who I mentioned before, work on user education. Every time we release a new version of the engine, typically of the editor, it requires us to educate people on how to use it. Imagine Photoshop released a new version of a tool which you use in your daily work. If there were new features every day, you'd probably be happy, but at some point you become overloaded. This amount of information is really hard to keep up with: okay, I've been doing this, and this button was here, and now it's moved. What we found empirically is that this process creates more frustration than good. So we adjusted our release timing appropriately, to make it not too often, and we found somewhere in the middle which seems to work well for everybody for now. But if our customers want it sooner, we'll try to adjust our process later on.

[00:17:49] We also hold regular production meetings. A production meeting is a place where, typically, representatives from the leadership team, the product managers related to the product, and the technical director representing the technical part all sit down together to discuss how our teams are doing, whether there's any support they need, whether there are any dependencies that we need to align on, or whether we need to start a new team or change the composition of a team for different reasons. Because sometimes people don't work well together, and we need to change the composition of the team.

[00:18:27] We also work a lot on ways of working. We have a dedicated opportunity to work on the way we work, and what comes out as a result of that focus on ways of working is a set of team agreements and a set of rituals, what we call team rituals[?]. For example, it might be the team standup, or it might be giving a prize to somebody for great work, getting together and maybe having snacks later on. Those are the things which get baked into the culture.

[00:19:00] And again, this process to define ways of working is not enforced. It could be done from top to bottom, but there's no reason to do that. It's mainly bottom-up: teams come up with their own ways of working, and the job of the agile coach in our case is to help the team come to a conclusion, to connect the decisions together before they make any agreements. Sometimes it's tricky to find consensus, and it takes time for everyone to agree. But in our case we have smaller teams, two to four people as I mentioned before, so it's easier to agree when teams are smaller. Our challenge is to make them work closely across locations, because some of our teams are split between locations as well. Sometimes this requires some support from the agile coach to help people come to a decision.

[00:19:45] And we of course do alignment meetings, where all sites come to one site and the entire team gathers. It's mainly social events, but we try to let people work on some common shared activities. For example, we want to do a shared activity to define our strategy for next year together. Before, it was more like management deciding what we'd be able to work on next year, and we're trying to experiment with making it more open and transparent, for everyone to collaborate.

People: one-to-ones and inclusion

[00:20:15] And the last area is people. This is an area I can talk about for hours, but I'll try to limit myself because I don't have much time. When we talk about the people part, it comes down to a few things. What I found to be the main point of working with people is working with everyone one on one. I do one-on-one meetings regularly, and I typically even ask people to schedule them themselves, whenever they want. That way I don't have to sacrifice my life moving things around in the calendar all the time, because I have 15 people to manage, but it also lets people feel ownership of their personal development, which is what I'm trying to encourage in my team.

[00:21:01] That's also what King does overall as a company. We try to build an environment where everyone feels empowered and listened to. We're focusing on diversity and inclusion at the moment, trying to improve the number of people from underrepresented groups in the company overall. It's one of the significant efforts King puts in as a company in general, and that's also true of the Fiction Factory team.

[00:21:32] In the one-on-ones, it's important for me as a manager to take into account every personality, because in the end I work with people. I don't work with engineers, or creatives, or UX specialists; we are all human beings, and we all have our needs, our aspirations, our motivations, our desires, the different things which drive us to come to work and do meaningful work. The main challenge of mine is to let everyone be happy but still be committed to the project, meaning to the deadlines we have. Sometimes we can't avoid deadlines for various reasons, but we try to avoid making deadlines the project management structure. Managing all the expectations from senior leadership while also giving people what they need can be one of the biggest challenges, but the one-to-one is a tool to mitigate the impact from either side and find the sweet spot. That's what I found works.

Feedback, job rotation and health checks

[00:22:42] The other aspect, when you try to build a culture in a diverse team and make it inclusive, so everyone is included in the group, is that it's very important to have feedback. We as a team put tremendous effort into exchanging feedback, and into educating people on how to deliver feedback in a constructive way. We never talk about negative feedback, because it has a negative connotation. It creates this feeling of: okay, not this talk again. We talk about constructive feedback. It's something that you want to express from your own emotion. For example, you observe a certain situation, you observe a behavior, and you see it impacting yourself; it might be impacting the team as well. That's what you focus on.

[00:23:37] The classic delivery tactic we use is SBI: situation, behavior, impact. When you focus on that structure, it helps you to be detached from the emotion which affects how the message will be received. We do lots of education in King, less about the junior level and more for the people in senior roles: how you communicate your ideas, how you influence others. Sometimes you might be doing presentations, and we try to help each other grow within the process. Feedback comes as one of the most, I would say the most, important aspects in that process of building team cohesion.

[00:24:17] For some people who've been in the team for a long time, no matter how fun it is to work with the product, no matter how many features they launch, it sometimes gets boring, in the sense that: I've been here four years, I want to see something else. To mitigate this, at King we have rotation[?] opportunities. You can think of the process as letting somebody work with another team for a limited time and see how it goes for them. Something they might want to explore: for example, some people want to move into project management, some people want to move into UX, some people want to move into people management. We try to give this opportunity to people as much as we possibly can within the organization, and at the moment it's three months long, so it's safe to try for everyone involved. And of course it puts a bit more pressure on managers to maintain this process and to let people manage their struggles and emotions and fears when it comes to personal growth. But overall the impact is very significant, and as a result people remain happy, and it helps us maintain a highly productive team.

[00:25:38] As a company, we also do an engagement survey[?], a selected, research-based survey. We use an external provider called Link[?], which helps us collect the data from the organizational health perspective. But besides that, we also do a team health check. The team health check is a Fiction Factory team-specific health check, very tailored to our needs. It goes into the specific details of the process and your happiness levels, whereas the organization-wide one is about strategy overall, leadership and some common company matters.

[00:26:16] At King, as far as people work goes, there's also talent planning. Talent planning is an HR activity which is built to help managers maintain a long-term relationship, but also to assess what kind of people, what kind of specialists we will be needing in the future, so we need to start preparing people already, and let people grow into those roles which the company will need in five or ten years from now. It's more like long-term planning for every single employee.

Wellness and team values

[00:26:54] And then the most important part is wellness. Typically, when you're talking about the classic PPP, project, people, process, this part is always forgotten. What I've found in my practice, and what is also backed up by research, and Google led the research, is that in order to have a highly functioning, productive team, it's not enough to be just a great engineer, a great UX specialist or a super great product manager. That is not enough. You need to have a sort of environment which you need to maintain to build a great product and build a great culture.

[00:27:37] Out of that research, we used the Google re:Work[?] research, and we used some other research on a similar topic, and we sat down and composed our own team values. The team values are a list of short statements which all of us in Fiction Factory can relate to. It was a very light exercise, and not everyone agreed to it, because across locations and different aspects it's harder to manage. So we agreed to constantly look at the values of our team and refine them as we see a better fit. But we need to start somewhere, so we started with a simplistic definition. It might sound quirky and awkward, but that's what we agreed to as a team at the current moment in time. What the team values help us with is building an environment we all aspire to be in, where everyone is listened to. We strive for a place where everyone wants to be happy at work.

[00:28:44] This is the last thought I want to leave you with when you think about the talk I've given you for the past few minutes. It's one thing that the team matters. Ethos comes from Greek philosophy, and it can be translated as the team spirit, or your team character. No matter how good you are at your job, it's more about what kind of person you are, and then what kind of team you are as a sum of those individuals. Because, you know, the team overall is greater than the sum of the individuals. I want to leave you with this thought. If you have more questions, feel free to reach out by email and we can have a chat. It took me more time, so sorry for that, but yeah, thank you for listening.