These transcripts were captured live by a captioner. As such, there may be small errors. If you spot any, please feel free to submit a pull request with amendments.

So, I've pretty much always considered myself a gamer. I think I was about six years old when I played my first video game at a friend's house, and I remember being so, so jealous that they got this awesome device that they could play whenever they wanted.

And a year later, I got one of these. The Donkey Con gamer watch. The controls were straightforward. There was a button on the right to jump up and down. And there was a pad on the left to go left and right. You controlled Mario from Super Mario Brothers, and you had to avoid the barrels that monkey was throwing at you.

There wasn't much to learn about the game. It took a while to master, and to score an actual high score, but the rules of the game were fairly simple.

Throughout my life, I've played a lot of games, and as technologies have evolved and graphics have gotten better, the games have become more and more complex. There are so many games out there right now that require you to actually put time and effort into fully mastering the game.

My favourite example of this is Horizon Zero Dawn. You need to hunt robot animals. It starts with small creatures that you can kill with a single arrow shot. As the game goes on, the creatures become larger, and meaner, and much trickier to kill. And it actually takes a lot of time before you are able to take down the biggest robots. It is a game where you really need to master the different weapons, and understand the different qualities of the robots that you're hunting.

So as games have gotten more complex, game designers put way more time into creating environments where players are happy, engaged, and willing to put the time and effort into learning and mastering all these skills. And I realised it is not unlike the work that I do in creating a environments for developers where they're happy, engaged, and willing to learn and master the skills that they want to.

As I mentioned in the intro, I'm an engineering manager at FutureLearn. We're a social learning platform offering online courses, programmes, and degrees. So our company really cares about learning, and it should not be a surprise that that is reflected internally as well. I've been at this company for six and a half years now, and I joined the company as an engineer, but I've seen our tech team grow from a tiny team of six engineers to the 36 that we are today. And as a tech team, part of our strategy is to grow our own software engineers. So, since our entire company is about learning, we believe that we should invest in our people. So, when possible, when we have the capacity, we should try to hire less experienced people rather than hiring only the most senior software engineers.

It needs, though, we need to make sure that our team is constantly capable of levelling up, and having those processes and structures in place that enable people to do that. So the way I see it is that, as a manager, I'm responsible for the internal developer experience. So from when the time the person applies to a job with us, to their onboarding and their time at the company, all the way to when they decide to leave, we need to make sure that people have the best experience that they can have. And I've been full-time-focused on this for two and a half to three years now.

The more I do this, the more I realise this is just another variation of user experience. So it's all about understanding the motivations, emotions and behaviours of people, and providing the best experience that you can for them. So I wanted here to specifically focus on game user experience because it's a similar type of environment we're trying to create, so an environment where people are engaged and focused on learning and mastering specific skills. So, that is pretty much what this talk is about.

We will be looking at eight lessons we can learn from game design and how we can apply them to teams. So one thing to note here is I'm not talking about gamification here. This isn't about making a time and a company more like a game where you score points, and there's a leaderboard for most kick-ass developer. It's not about anything like that. It's about how we can gamify work, it's about using analogies from game-user experience to better understand how we can make the developer experience better.

So to structure this talk a bit more, I will look at three different areas of game design, and within those areas, I will highlight different game examples, what lessons we can learn from them, and how to apply those lessons in a team with some practical examples of what my team does.

So the first area is starting a game. So I mentioned an example earlier of the Donkey Kong game where the goals are left, right, and jump. Nowadays, games are much more complex than that. This is an overview of the game controls of Uncharted, and even though I've played this game, kind of overwhelmed by the amount of things that you can actually do. But most games won't just drop you into the game, go, right, off you go, figure it out, almost every game nowadays has a phased introduction of the various game mechanics.

So in Uncharted, each of the controls get introduced one at a time. So, in Uncharted 4, one of the first encounters is with this random guy on the right where you learn how to punch. You get this little message telling you to hit square to hit him. Later on, you get another scene where you learn how to interact with an object by pressing try an he will, and in similar ways, you get to learn how to dodge, climb, and shoot a gun until you're able to do the base actions. In this game, it's done fairly quickly.

Within the first half an hour, you've pretty much learned the core mechanics, but it's still staged in such a way that you focus on one skill at a time. Lesson number one is don't overload new starters. So when someone new joins, they've got a lot to learn. New people, new ways of working, new codebase, new terminology, new abbreviations, so come up with a way to stage your onboarding, and actually plan it out more deliberately.

So the main thing that we have is an onboarding checklist that we create for each starter. So we have an onboarding template in Trello which we regularly update, and the week before a new starter starts, we create a copy and customise it. So it's all about allowing a new starter to have one starting point where they can find all the info that they need to get started.

So going back to video games, another thing to note when starting a new game is who is responsible for teaching the new skills? So, a lot of the early games will come with a manual that exactly explained what each button did, and how the game worked, how you win the game, and I remember playing games where I just kind of skimmed the manual, threw it away when, "I can do this, I'm start." And only discovered that a certain move was possible like months and months later after actually talking to a friend who will also played it.

So at the time, the onus was very much on the player to figure it out. Most games now embed that onboarding aspect into the game. The game is the responsible for teaching the new thing. So going back to Uncharted, it's just a simple hovering message, but it is a hovering message that won't disappear until you've actually hit that button. So the aim itself goes, right, now it's time to learn something. We're not going to let you go on until you've actually done that.

So lesson number 2 is support and guide new starters. So it is all well and good to have an onboarding plan and checklist, but you don't want your new starter to go at it completely alone. So, whenever someone new starts, we pair them up with a mentor, and the mentor is on their same team and sits close by to them. They're there to help support and guide the new starter during the first few months, so they don't necessarily have to pair directly on the work together, but the mentor is supposed to make sure that the new starter has something to work on and is around for any questions they might have, and just generally should be the first point of contact that the new starter can go to.

We make sure that they regularly catch up, and to come up with a plan for anything that additionally needs to go into that onboarding checklist. So the second area that we are going to look at is how games help with learning new skills. So one of the most important aspects of learning something new is understanding whether or not what you're doing is the right or wrong way of doing it.

So typically, games are pretty good at providing feedback in some way, and I struggled, actually, with coming up with an example of a game that did it really badly. Going back to Uncharted again, it's quite low-key in this case. Once you've pressed the square button, that message just disappears. And a lot of the other type of feedback in the game is the same type of feedback that you would expect in real life, so, if you misjudge a jump and miss a ledge, you basically fall to your death and die. Kind of like real life! Not kind of, actually real life! Don't jump like that. If you shoot at an enemy, he bleeds and then dies. We might not really think of it as feedback, but the game is actively telling you that an action that you did had an actual immediate effect.

So lesson number three is give people direct and timely feedback. When possible, we want to encourage our team members to give direct and immediate feedback, especially if it is constructive feedback. It needs to be delivered in a timely manner, and with specific examples.

As part of my role as a manager to facilitate that this happens, so one of the things that I tend to do is just making myself available for whenever someone wants to prepare for a conversation with someone else, or wants to role-play to trial out how to actually face that. Because it's hard, this type of stuff. And there are two books I found that really help with getting people to think about feedback.

So the first is Difficult Conversations which is all about approaching conversations and structuring them better so the point that you're trying to make just has a better impact. And it's not just a useful book for difficult conversations, any conversations or communications that you have will benefit from this. So think about the dialogue that you're having with someone when you're pairing, and explicitly thinking about what impact your words have on the other person.

So the second book is from the same writer, and it's called Thanks for the Feedback. It's written for from the point of view of being able to hear and take in feed back, and understand what the various triggers are that you might have making you react to feedback. So I thought I was quite open and understanding about receiving feed back, but when I read this book, I did that right before I was getting my annual review, and I noticed myself reacting and missing some of the things that people had said in the way the book said I would. So it is a really useful book to get better at this type of stuff.

Going back to Uncharted, at this stage of the game, you normally also can't die. That guy on the right will just stand there waiting for you to actually punch him. And you can't die from the punches that he gives you back. Anyway, so, until you learn, the game is set up to ease you into kind of learning and applying these types of skills. So another example is Mass Effect where you can go to a shooting range to try out different weapons and powers without dealing with any actual enemies shooting back at you. Again, you can't die, and it allows you to trial out and learn how to master specific skills.

So lesson number four is provide opportunities to apply new skills. So at FutureLearn, every person has a training budget, which isn't uncommon, but we really try to get people thinking about how to use their budget in a way that works for them. While I love conferences, I know not everyone find them as useful. I also suspect we encourage people to use their budget on conferences because it's kind of the easy thing to do. And it's up to me as a manager to help identify what other types of training are out there. Things like improv workshops, writing, or public speaking courses, getting a trainer in for a day, finding a mentor. We need to be the ones to find and offer the opportunities that people can use their budget on.

Beyond that, we also make it explicit that people get personal development time, and during their normal work hours. We make it a default that everyone on the team should be spending half a day on learning and developing themselves. So some people require more time, other people less time, but having that default explicit means that we are setting the expectation that people should be learning and growing.

So one of the things that people can spend their time on are different learning events, so these are regular internal events that are mostly self-organised for people to get together and learn something in different ways, and that's just a bunch of the ones that we do, and, if you're interested in this, come and find me during the break.

Then finally, we also have book clubs and course clubs, so for people who want to read a book for take an online course. They are made up - they meet up regularly to discuss the progress they're making and how to apply what they've learned to their work. The final area we are looking at is the actual levelling up of the character.

Now, not all games allow you to do this, but there are a lot of role-playing, action, and even racing games nowadays that have some form of levelling. The different ways that games have implemented this ability to level up, so, in this section, I really wanted to look at some of the variations, and the effect that they have on the player.

So, the basic concept of levelling-up is this: your character starts at a specific level. You gain experience by doing things in the game, like battling enemies, finding treasure, stuff like that. So some games will call these experience points, skill points, action points. Each game comes up with their own random thing to call it, but they all mean the same thing: it's a way to increase your level.

Now, up until this stage, I think most games are quite consistent. There are some exceptions, but the majority of games, levelling-up will follow this type of pattern. Where they're different is with what happens when you reach that next level. So the simplest version is where you reach the next level, your character becomes stronger in some predefined set way.

So, for instance, in Kingdom Hearts, which is a game where you meet various Disney characters, and Goofy and Donald Duck are your side kicks, each level-up is associated with a specific increase or availability. The picture on the top right shows that Goofy is now level 3 and therefore his defence has increased. With level 4, his strength will increase, level 5, he unlocks a special ability. No matter where you are, who you're playing, every person will get these increases. So in this type of levelling, with each level up, you get a specific increase that the game has preset, but it's a way to celebrate your character getting stronger and progressing through the game.

So lesson number five is acknowledge people's growth. So I'm always surprised to hear that there are companies out there where they only give salary increases if a person asks and lobbies for it themselves. In my opinion, you should start off with the assumption that your engineers will learn and grow, and you should be always taking the time to review and adjust their salaries accordingly.

So we do salary reviews for every person every year. Most of the time we will at least to give an inflationary increase, and fending on the person and the progress they've made, they will get a small, medium, or large increase. With each review, we also compare the salaries of the people in the team with comparable skills and experience. So to make it sure that we are always being fair and consistent across the entire team, so none of this is dependent on how well someone is able to advocate for themselves.

Back to games, and the next type of levelling up all allowed the player a choice two what happens when they level. The first variation of this, the player gets to choose themselves which stats or attributes to increase. One example of this is Dark Souls, which is pictured. So the values here in blue are the attributes that the player can choose to invest in and increase. And these games, it's really, really important to know what each attribute means, how it affects you, and how you can apply it in the game.

So, lesson six is expose basic competencies and what they're used for. So we've got several sets of competencies based on what role you have, so we started with the ones for software engineers which are curiosity, communication, technical skills, teamwork skills, and initiative. And we use tease whenever we are hiring and interviewing to make sure that we always are taking all of those areas into account, and that we're again consistent and fair in how we are discussing people.

And then we also have more advanced competencies for the more experienced roles in the team, and, again, we can use these in conversations about career progression during salary reviews, or when providing feedback. Having those competencies means that we are framing those discussions with the attributes that we value and care about, plus we have a common agreed-on language to discuss these type of things. So the next way a character can level up is by choosing a special ability rather than a stat to increase.

This is where skill trees and pathways appear on games. So this is Horizon Zero Dawn again. At the start of the game, you have the skills that are in that first row. Each time you level up, you gain skill points, and you can exchange those points to unlock whatever skill you want. You are bound to the order of the ones that are connected, so you can't unlock something in the third row if you haven't unlocked things in front of it.

In the end, though, all the players end up with unlocking everything in this tree. It's very much up to you decide which order you unlock them, but you always end up with everything if you stick with the game. So a similar example of this is the latest Tomb Raider.

A different way of visualising it, but the same thing applies. You can only invest in the skills adjacent to the ones you already have, and you end up with all of the skills at the end of the game. Another approach is where it's much more modular. So this is Mass Effect Andromeda, and, in here, you never are expected to unlock all these skills. There's just not enough points for it. You can only invest in a certain number of them, and it's up to you to decide what type of character you want to create. It very much depends on your style of playing what the right decisions for you are.

A similar version of this is the latest Assassin's Creed. This I find really funny because both me and my husband play this, and we have different playing styles and end up with very different skills to unlock. He wouldn't be able to play with my character, and I wouldn't be able to play with his character, because it's very much dependent on our own gameplay.

So lesson number seven is allow people to choose their own path. And what I mean by that is allowing people to generalise or specialise whichever way they want. So we used to have front-end and back-end engineers, but a few years back, we got rid of that title and turned it into just software engineers.

We noticed that having those labels were creating unnecessary barriers, and we didn't really acknowledge the different types of skills that people had that weren't covered by those two areas. So now we expect everyone to be full stack, or that everyone fits nicely in a back-end or front-end box, we are giving people the opportunity to choose what skills to invest if in.

We've introduced a spreadsheet where people can say how comfortable they are in specific areas. We use this for figuring out the make-up of teams in ensuring we balance the skills the right way, and we use it for people to fin out on the team they should they should ask for help for when dealing with something. It's a way to visualise all the different types of experience that we actually have. Finally, what all these games do are visualising and explaining how to progress in the game. They are quite different styles, and it's quite a lot of complexity in each of them. But all of these are getting the player familiar with what is possible and allowing them to compare and understand what might be right for them.

So a final lesson is visualise what progression looks like. So we introduced a career development framework last year, career progression framework, I mean. It's gone through various iterations. So the first one we had was very linear. So similar to the first games that we looked at where everyone was expected to progress in a similar way just one level at a time, and eventually unlocking everything. We realised, though, that didn't really work for us, and decided to go for a much more modular approach. Plus we realised we really wanted a - we wanted to link the entire thing to our competencies and our different roles. So this is an overview of our framework.

There's a lot going on in there which I won't go into right now, but again, if you're interested in this, come and find me during the break. The idea of the progression framework is that it really used to -ee use it as a tool to have those discussions about career progression with people.

And for people to plan and figure out what they next should focus on in the same way that video games allow people to see where they are, and what is possible for them. So, those are eight lessons of game design that we can apply to building cultures where people are engaged and motivated to learn to level up.

So, to recap: don't overload new starters. Support and guide new starters. Give people direct and timely feedback. Provide opportunities to apply new skills. Acknowledge people's growth. Ex pose basic competencies and how to use. Allow people to choose their own path. Visualise what progression looks like. So, as a manager, my main focus is in creating the developer experiences. So I think in the busyness and what developers do, it's easy to lose the way that our developers are our stakeholders, and we should be the ones creating experiences for them that allow them to grow, progress, and level up.

So, if you're a manager, try to do this type of stuff. If you're not, it's not unreasonable to ask your manager whether they can provide some of this stuff. So creating better developer experiences are the way we can make not only our companies better, but also the people that are in our teams trying to grow, learn, and progress. So that's it. Thank you for listening. [Applause].