Level Up: Developing Developers

Okay, hello everyone.

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 jealous that they got this awesome device to play games on.

And a year later, I got one of these, the Donkey Kong Game & Watch.

And I think I'm dating myself in that sense.

So the controls were fairly straightforward.

Simple button on the left to go left and right, and a button on the right to jump.

And you controlled Mario from Super Mario Brothers and had to avoid the barrels that Donkey Kong, this giant monkey, were throwing at you.

There wasn't much to learn about the game.

It took a while to master and to score a high score.

But the rules of the game were fairly simple.

So throughout my life, I've played a lot of different 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 that require you to actually put time and effort into fully mastering a game.

My favorite example is this game, Horizon Zero Dawn.

In a game, you need to battle and hunt robot animals.

And it starts off with these reasonably small creatures that you can kill with a single arrow shot.

But as the game goes on, the creatures become larger, and meaner, and trickier to kill.

And it actually takes a lot of time before you're able to take down the biggest robots.

It's a game where you need to make sure that you understand the different weapons.

You need to understand the different qualities of the robots that you're hunting.

And 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 mastering these skills.

And I realize it's not unlike the work that I've done to create environments for developers, where they're happy, engaged, and willing to put the time and effort into learning and mastering the skills that they want.

So I run my own company now called LearnBuildShare, where I help engineering teams with their communication leadership and collaboration skills.

So I do coaching, as Dave said earlier, and training, and consulting.

And I'm really fascinated by how we can create better internal engineering cultures.

So I used to be an engineer and an engineering manager at companies like FutureLearn and the Wikimedia Foundation.

And part of my past roles has been to make sure that our engineers were constantly leveling up and learning, that we had processes and structures in place that enabled them to do that.

And as a manager, I really saw it as my role as being responsible for the internal engineering culture.

And that's what I help companies nowadays with as well.

So from the time when a person applies for a job to their onboarding and their time at the company, all the way to when they decide to leave, you need to ensure that people have the best experience that they can have.

So I've been looking at this for quite a couple of years now.

And the more that I do this, the more that I realize that it's just another variation of user experience.

It's all about understanding the motivations, emotions, and behaviors of people, and providing the best experience that you can for them.

And I wanted to specifically focus here on game user experience, because I think it's a very similar type of environment that we want to create.

It's an environment where people are engaged and focused on learning and mastering new skills.

So that's what this talk is about.

I'll be looking at 10 lessons that we can learn from game design and how we can apply them to teams.

Now if you're having a bit of deja vu, and this sounds familiar, I did actually give this talk at State of the Browser about five years ago.

So during those years, I've changed roles a couple of times, and I've applied the lessons to different teams.

And they're still as relevant today as they were then, which is why I love bringing this talk back.

So I'll be talking about a lot of these lessons from the viewpoint of being a manager or a leader on a team, because that was my own experience.

But many of these things can be led or advocated for by anyone on a team.

So if your team is not doing these things yet, you can lead that change.

Now one thing to note is that I'm not talking about gamification here.

This isn't about making your team, it's not about making your time at a company like a game where you score points and there's a leaderboard for most kick-ass developer.

This isn't about how we can gamify work.

It's about using analogies from game design to better understand how we can make the developer culture better.

So to structure this talk a little bit more, I'll look at three different areas of game design.

And within those areas, I'll highlight different game examples, what lessons we can learn from them, and how to apply these lessons in your team with some practical examples.

So our first area is starting a new game.

So I mentioned the example earlier of this Donkey Kong game where the controls were purely left, right, and jump.

Nowadays games are more complex than that.

So this is an overview of the game controls of Uncharted, and even though I've played this game, I'm kind of overwhelmed by the amount of things that you're able to do.

But most games, they won't just drop you into the game and go, "Right, off you go."

Fear it out.

Almost every game nowadays has a phased introduction of the various game controls.

In Uncharted, each of these controls get introduced one at a time.

So in Uncharted 4, one of the first encounters is with this guy where you learn how to punch.

Come on, clicker, you can do it.

You get this little message here telling you to hit square to attack the enemy.

And later on, you get another scene where you learn how to interact with an object by pressing triangle.

And eventually in similar ways, you learn how to dodge, jump, climb, shoot a gun until you're able to do all the base actions that the game requires.

So in this game, it's done fairly quickly.

Within the first half an hour, you've pretty much learned all the core mechanics, but it's still staged in such a way that you focus on a single skill at a time.

So lesson number one, don't overload new starters.

When someone new joins, they've got a lot to learn.

New people, new ways of working, a new code base, new terminology.

It's a come up with a way to stage your onboarding and actually plan it out more deliberately.

So the main thing that you can do is to create a checklist and guide for the new starter.

So I've done this now at multiple companies for different roles.

And it will include what tasks to complete during the new starters first day, their first week and their first month.

It will include a breakdown of all the people on their team and a list of folks that they should meet during that first week.

And sometimes I also pre-schedule these meetings for them already.

It includes their job description, what we expect from them during the first few weeks, and just reassurance that it's okay to ask questions because things will be overwhelming on that very first day.

It's all about allowing a new starter to have one single point of reference where they can find all the info that they need to get started.

So I've created this type of onboarding documentation in Trello, in Wikis, in Jira, in Confluence, in Google Docs.

The main thing is build it in a tool that your new starter is expected to use day to day.

It's a way to onboard them into the tools that they're using regularly as well, as well as into the role.

Part of this onboarding process is also to create a checklist for the manager and the team.

We have tasks to do before the new starter joins and things to do during their first day and their first week.

So for the manager, it includes things like send out a welcome to the email address before they start, send a starter's gift with some nice company swag, sort out the meetings and work to prepare for that first week.

It means that you can plan out a consistent and well-formed out process that you can replicate with every new starter.

So going back to video games, another thing to note when starting a new game is who is responsible for teaching these new skills.

Now a lot of the early games would come with a manual, an actual paper manual that exactly explained what each button did and how the game works.

And I remember playing games as a kid where I kind of skimmed the manual for like, I've got this, I've played games before.

And I only discovered a certain move was possible a month after playing when a friend pointed it out to me.

And I realized I was making the game actually more difficult for myself.

So at the time, the onus was on the player to figure it out themselves.

Most games now though, embed that onboarding aspects into the game.

The game is the one responsible for teaching this new thing.

So going back to Uncharted, it's just a simple hovering message over there.

But it's a hovering message that won't disappear until you have actually clicked on the button.

So the game itself goes, right, now it's time to learn something.

So lesson two, support and guide new starters.

So well and good to have an onboarding guide and checklist, but you don't want your new starter to go at it completely alone.

So whenever someone new starts, pair them up with an onboarding buddy.

The onboarding buddy should be on the same team and is there to help support and guide the new starter during the first few weeks.

They don't necessarily have to pair directly and work together that entire time.

But the buddy is supposed to make sure that the new starter has something to work on, is around for any questions that they have.

And generally, it should just be the first point of reference that the new starter can go to.

So we ensure that they regularly catch up and come up with a plan for anything else that needs to be done during that onboarding phase.

It's about making it easier for the new starter to know who to go to.

So final thing when you start a new game is understanding what your current goal is.

So once a player knows how to play the game, they still need to be able to figure out and choose what missions or quests to focus on, and then how to achieve them.

So this is an example from Horizon Zero Dawn.

On the left there, you have multiple quests, which you can choose from.

Whichever one you have selected shows a breakdown of all the different things that you need to do to achieve that mission.

Similarly, once you've got a mission selected, it will appear as this to do list on the left of your screen with what you still need to do to achieve your goal.

Again, a lot of the older video games didn't do helpful things like this.

I've played games where I accepted a quest and I was told, "You need to go to this village called something generic like Happy Water or Greenfield or Boring by the Sea."

And then I left the game a few weeks and came back to it not remembering what the name of that bloody village was.

And the game provided no other clues anywhere as to what to do next or where to go.

And this was around the time when we didn't really have like online guides or tutorials to find the stuff up.

I actually had to buy a physical book with tips and tricks on what to do and figure out exactly where it was that it was supposed to be going.

So lesson number three, make it clear what people should focus on.

So I always encourage the people on my team to set personal development goals and to reflect and review them on a regular basis.

I don't want people to set goals once a year and then forget to look at them and make progress on them.

As a manager, I'm the one that should be regularly checking in with people and making sure that they're continually working on their goals.

So it's also why I want people to write them down and record what they've done.

Even if they haven't achieved the goal that they set out to do, in most of those cases, it's because they've learned something else instead.

And they should be recording and writing down what that something else was so that they can see their own progression.

And they should also tie in with the bigger picture career goals that the person has.

So I like doing career brainstorming sessions with my team to help them think beyond just the immediate future.

It means they can start dreaming and imagining what they'd like to explore next and how we can coordinate their current day to day with where they actually want to grow.

And once people have set goals, I encourage them to look for opportunities to share those goals with team members.

Mainly because having them visible means that someone else might be able to help out with them.

For instance, pairing on specific problems or encouraging someone to lead on specific work or projects.

This is about creating cultures where everyone is learning together.

So the second area that we're going to look at is how games help with learning new skills.

Now 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.

Typically, games are pretty good at providing feedback in this way.

I actually struggled with coming up with an example of a game that did it badly.

So if someone has one, come find me.

So going back to the Uncharted example, it's quite low key.

But once you press the square button, the message just disappears.

And a lot of the feedback in that game is the type of feedback that you'd expect in real life.

If you misjudge a jump and misallege, you fall to your death and die.

If you shoot an enemy, he bleeds and the enemy dies.

We might not think of it as feedback, but the game is actively telling us whether an action that we did had an actual immediate effect.

So lesson number four, give people immediate feedback.

When possible, we want to encourage our team members to give each other direct and timely feedback.

And especially when it's constructive feedback, it needs to be delivered in a timely manner.

And it's part of my role as a manager to facilitate that.

One thing that I used to do is make myself available whenever someone wanted to prepare for a conversation with someone else.

Or if they wanted a roleplay to trial out what they were going to say.

It was something to help them be more comfortable with giving feedback.

And there are two books I found that really help with getting people to think about feedback that I recommend everyone reads.

So the first is Difficult Conversations, which is all about approaching conversations and structuring them better so the points that you're making have a better impact.

It's not just a useful book for difficult conversations.

Actually any conversations or communications benefit from this.

So think about the dialogue that you have when you're pairing with someone, explicitly thinking about what impact your words have on the other person.

The second book is from the same writers and it's called Thanks for the Feedback.

And it's written more from the point of view of being able to hear and take in feedback and understand what the various triggers are that might make you react to feedback.

Now I thought I was quite open and understanding about receiving feedback.

But at the time when I read this book, so I read this book right before getting some feedback.

And when I got the feedback I noticed myself reacting and dismissing some things exactly in the way the book said I would.

So it was a really useful way to learn more about myself and how I should react when I'm listening to some nice words that other people have to say about me.

So going back to games again, sometimes feedback doesn't happen immediately.

But rather the game allows you to review and look back at something that you did.

For instance in Overwatch when you're playing a match against other players, if you get killed the game waits a couple of seconds before you get back into the fight.

And rather than do nothing here, the game shows you how you died and uses it as an opportunity to learn from.

So lesson number five, provide space to reflect and learn from the past.

So I try to encourage people to do more self-reflection and really get a sense of how they've done things recently.

Now a lot of teams do retrospectives for their teams, but people rarely do this activity on their own for themselves.

And I think lots of people can benefit from just taking that time to stop and review and think about what did I do this week that maybe I could do just a little differently, just a bit better.

Beyond self-reflection though, the other best resource to learn from feedback is feedback from others in a more recurring regular structure.

So I encourage teams to set up 360 feedback cycles where people can nominate peers and feedback is given by those peers, the manager and the person themselves.

And there are tools out there that make this process easier, but even when I've set up something super lightweight, the feedback will be super valuable to people.

So going back to Uncharted, at this stage of the game you normally also can't die yet.

The guy will keep on punching you without you being able to die until you actually learn and remember you need to hit the square button.

It's quite amusing if you just keep it all in the background and have them standing there.

But the game is set up to ease you into learning and applying the skills that you need.

Another example is Mass Effect where you can go to the shooting range to train and try out your different weapons and powers without dealing with actual enemies.

You again can't die yet at this point and it allows you to just trial out and learn how to use specific skills and figure out what your playing style is.

So lesson number six is provide opportunities to apply new skills.

So in most companies people will have a training budget, but the majority of people don't actually know what to use their budgets on.

To help identify what types of training are actually out there.

If you come across an interesting conference like State of the Browser or a workshop, share it with your team.

But also think of things that are not that typical.

Things like improv workshops or writing courses or getting a trainer in for a day.

It's basically up to you to help find and offer the opportunities that people can use their budgets on.

Share with each other what you find interesting.

And maybe something isn't that interesting for you personally because you have those skills already, but get other people to look at it and do it and get them on that same journey.

Beyond that though, make it explicit that people get personal development time during their normal work hours.

So I've tried to make it a default that everyone on my PaaS team should be spending about half a day per sprint on learning and developing themselves.

And some people might require more time, others less.

But making that default explicit means that we're setting the expectation that people should be taking this time.

And then set up and organize internal learning events.

So things like book clubs, lunch and learns, lightning talks or demo hours.

Give people the opportunity to share the new skills that they're learning and help teach others on the team.

Now the final area that we're looking at is the actual leveling up of a 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 leveling up.

And there are a lot of different ways that games have implemented this ability to level up.

So in this section I really want to look at some of the variations and the effect that they have on the player.

So the basic concept of leveling up is this.

Your character starts at a specific level.

You gain experience by doing things in the game like battling enemies or finding treasure.

And some games call these experience points other skill points or action points, but they all mean the same thing.

A way to increase your level.

Now up until this stage, I think most games are quite consistent.

There are exceptions, but the majority of games with leveling up will follow this pattern.

Where they differ is with what happens when you reach that next level.

So the simplest version is where when 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 sidekicks, each level up is associated with a specific increase or ability.

So this picture in the top right shows a message that Goofy is now level 3 and therefore his defense has increased.

With level 4, his strength increases.

With level 5, he unlocks a special ability.

So in this type of leveling, 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 7, acknowledge people's growth.

Now I'm always surprised to hear that there are companies out there that will only give salary increases if a person asks and really lobbies for it themselves.

In my opinion, you should start off with the assumption that your engineering team will learn and grow and you should always be taking the time to review and adjust salaries accordingly.

So do regular salary reviews for every person every year.

Now I know this current market makes this trickier and that it will very much depend on the company's situation, but I still think that this is good practice.

Most of the time, the least the company should do is give an inflationary increase, especially with the cost of living each time increasing.

And then depending on the person and the progress that they're making that year, give an appropriate increase.

And with each review, it's also about comparing the salaries of the people on the team with comparable skills and experience to really make sure that we're being fair and consistent across the team.

Now back to games.

The next type of leveling up is to allow the player a choice in what happens when they level up.

Now in the first variation of this, the player gets to choose themselves what stats or attributes to increase.

So one example of that is Dark Souls.

So those values in blue are all the attributes that the player can choose to invest in and increase.

In these games, it's really important to know what each attribute means, how it affects you and how you can apply it in the game.

So lesson number eight, expose basic competencies and what they're used for.

So I try to ensure that there are competencies for the different roles on my team.

I use these whenever we were hiring and doing interviews to make sure that we always take all of these areas into account and that we're consistent and fair in how we're reviewing people.

So when I managed engineers, we had competencies like technical ability, but also curiosity and collaboration.

While when I was managing developer advocates, we also prioritized technical writing and community building.

Having those competencies meant that we were framing discussions with the attributes that we value and care about and that we were also explicit and transparent with people that these were the values that we cared about.

Plus we had a common agreed on language to discuss these things.

The next way a character can level up is by choosing a special ability rather than a stat to increase.

And this is where skill trees and pathways appear in games.

So this is Horizon Zero Dawn again.

And at the start of the game, you have the skills in that entire first row.

Each time you level up, you gain skill points and you can exchange those skill points to unlock with whichever skill you want.

You are bound though to the order of the ones that are connected.

So you can't unlock something in the third row if you don't have the second row, the thing above unlocked.

In the end though, all the players end up unlocking everything in the stream.

It's very much up to you though to decide in which order you do it.

But you always end up with everything if you stick playing the game.

A similar example of this is in one of the past Tomb Raiders.

It's a different way of visualizing it, but here is a similar setup.

You can only invest in the skills adjacent to the ones that you already have.

Another approach is where it's much more modular.

So this is Mass Effect Andromeda, the worst of the Mass Effect games.

And in here you're never expected to unlock all of these skills.

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 also depends on your style of playing and what the right decisions are for you.

A variation of this is Assassin's Creed Odyssey.

Here you have three different areas and it's again up to you to choose what abilities work for you.

So you never gain enough points to unlock everything in here.

And you need to be quite strategic in choosing what works for you.

For instance, if you rarely use your bow, which is the hunter section on the left, it doesn't make sense investing points in that area because all the stuff there will affect only the bow.

So both me and my husband played this game and it was always fascinating in seeing the different skills that we unlocked because we have very, very different playing styles.

So lesson number nine, allow people to choose their own path.

What I mean with that is allowing people to generalize or specialize whichever way they want.

So back when I was working at FutureLearn, we originally used to have front end and back end engineers.

But we noticed that having those labels, it was creating unnecessary barriers and we didn't really acknowledge the different types of skills people had that weren't quite covered by those two areas.

So we got rid of the titles and turned it into just software engineers.

At the time, rather than expect everyone to be fully full stack or that everyone fits nicely in a front end or back end bucket, we gave people the opportunity to choose which skills they wanted to invest in.

And that allowed for more flexibility across the team.

It meant we actually covered more skills in total rather than have everyone do exactly the same thing.

Finally, what all these games do is visualizing and explaining how to progress in a game.

They're all quite different styles and there's quite a lot of complexity in it.

But all of these accomplish getting the player familiar with what is possible and allowing them to compare and understand what might be right for them.

So final lesson, visualize what progression looks like.

So look at creating a career progression framework for your team and allowing your team to plan out and figure out how they want to grow in their roles.

It depends on your team and the size of company, what type of framework you want to implement here.

So over the past few years, I've seen lightweight frameworks that can be used across the entire company so that all roles have a similar understanding of how to grow.

But I've also seen ones that are much more engineering specific and really focused on very key specific skills.

And if you need inspiration, you can check out progression.fy.

They have a good collection of frameworks and career ladders from a range of companies.

So rather than starting completely from scratch, you can check out what they have there.

Also, if your company doesn't have a framework and doesn't have a plan in rolling out one, you can use one of these for yourself.

It helps to explore what types of roles and levels are actually out there for you to understand what skills you might like to focus on in the same way that a video game will allow you to see where you are and figure out what is possible for you.

So those are 10 lessons of game design that we can apply to building cultures where people are engaged and motivated to learn, progress and level up.

So to recap, don't overload new starters, support and guide new starters, make it clear what people should focus on, give people direct and timely feedback, provide space to reflect and learn from the past, provide opportunities to apply new skills, acknowledge people's growth, expose basic competencies and how they're used, allow people to choose their own path and visualize what progression looks like.

And these aren't just the only lessons that you can take from video game design.

These are the ones that jumped out to me.

So the next time that you play a game, I want you to stop and think, is there something in here that I can learn from and apply to what I do?

So as a manager, my main focus was to develop engineering cultures.

I think in the business and hecticness of what most managers do, it's very easy to lose sight that in a way engineers are our stakeholders and we are the ones that should be creating experiences for them that allow them to grow, progress and level up.

So if you are a manager or a team lead, 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 these different things.

Creating better internal cultures are the way that we can make not only our companies better, but also the people that are in our teams who are trying to grow, learn and progress.

So thank you all for listening.

Thank you.