Congratulations! You’re a lead. Now what? In general, whatever skills you’ve demonstrated that got you to this point aren’t the same things you’ll be doing from here on out (or at least not as much.) Not everyone is suited to a lead role or would be happy in one. Trust I believe you have every chance to excel as a lead; Otherwise, you wouldn’t be one.
What follows is a entry-level description of my expectations for a #gamedev lead. There are a lot of things to know and a lot of new skills to master, but my hope is that this will get you going for your first couple of weeks in your new role.
Do not skim. Block out some uninterrupted time to read this guide and make sure you understand my expectations. Take notes for our follow up discussions.
- Is there anything here that you don’t feel is completely clear?
- Is there anything here you disagree with?
- What do you think will be the real challenges with each of these expectations?
- What do you think will be your practical approach to meeting each of these expectations?
- Most importantly: Have a point of view. i.e. I expect you to adopt a position and risk that we disagree rather than simply agreeing or being apathetic about what I’m saying.
There is no one thing that has more of an impact on the quality of the game, the cost of development, the engagement and happiness of the gamedevs and the future of the studio than leadership. A bad leader can do more damage than the rest of the team combined; A good leader can help to make every individual gamedev on their team twice as effective as they would be on their own.
I asked some gamedevs recently to list the most common reasons why gamedev sucks:
- Studio closures
- Canceled projects
- Bad projects
- Unhappy gamedevs
- Overworking gamedevs
- Unrealistic expectations
- People who are incompetent at their jobs
All of these problems are leadership problems. None of these problems are process problems.
You must be wary of any process that purports to address these issues. Take the latest development fad with a truckload of salt and stay focused on being the best leader you can be. Actively research and learn what has worked and what has failed for others but ultimately adapt everything to what works best for you and your team.
If you absolutely must have a formula for doing your work, here’s mine: Figure out what doesn’t work and do less of that; Figure out what works well and do more of that.
You probably have a lead. That might even be me. That lead needs to make decisions. When you agree with those decisions, things are easy. Anyone can be a champion for a decision they agree with. I don’t expect you to always agree. I do expect you disagree in private or in a leads meeting where that disagreement is encouraged. Outside that, I expect you to not just agree, but sell the direction to your team. Once the decision is made, I expect you to figure out how to make yourself believe in it. You should expect the same from your team.
I expect you to know the problem space of your team better than I do. You spend much more time in your problem space than I do, so I certainly also expect you to be able to come up with solutions much better than what I could come up with. When I suggest what problems we should solve it’s based on the best information that I have. When you have better information, it’s up to you to speak up. If what I suggest doesn’t make sense, it’s up to you to tell me that. If there’s a better option, it’s up to you to bring that to the table. As soon as possible.
- Is there anything you think we should remove from our development process?
- What decisions of the past do you feel get in our way?
- Where do you believe we are asking the wrong questions?
For some leads, this is the hardest part. You may in fact be the best person to solve a particular problem or implement a particular system. That does not mean you are always the right person. It’s difficult to help your team solve their problems when you are heads-down in the trenches with your own issues. You need to figure out what the best balance is. You need to consider what is best for the team. You need to appreciate your role as teacher and mentor on the team. Use your experience to develop your team so that (eventually) they can do it better than you. They have the advantage of having you, you didn’t.
When you are working on implementing something yourself, remember you are setting the example and the bar for how you think the problem should be approached and solved. Take the time to step your team through your process so that you all can be more confident on some future problem that your team will even better than they already are.
You are responsible for the work of your team. You are responsible for knowing how their work will affect the game and the players’ experiences. You are responsible for knowing how their work will affect development of the game and all the other gamedevs in the studio.
In order to lead others you need to know yourself. Constant introspection is crucial to leadership. Understand what you value most and make sure you can articulate that to your team in a way they can understand and articulate to others.
If you are having a difficult time figuring out what your values are, take some time to answer these questions the best you can. We can discuss what you come up with and see if together we can’t work out how to describe what you value.
- Why are you here?
- Why games?
- What does success mean to you?
- What is most important to you about the player experience?
- What is most important to you about the development experience?
- What frustrates or irritates you most about the player experience?
- What frustrates or irritates you most about the development experience?
- What frustrates or irritates you most about yourself?
- What are three things that you would like other gamedevs to say about you?
- What are three words you would use to describe your point of view on technical issues?
- What are three words you would use to describe your point of view on personal development?
- When was a time when you felt a lead personally let you down?
- When was a time when you felt a lead really helped you out?
Your direction is the mission for your team. It should be clear. It should be a concise description of what your team ideally does. “Make good games” is not good direction because no one will argue with it. If no one can disagree with what you’re saying, you’re probably not saying anything. As a goal, it should be hard. It should also be a method of judgment for the team. For any given problem, they should be able to judge whether or not their proposed solution would take the team closer to the goal or further away without consulting you personally.
- For instance your team may be focused on the Player Experience. Your direction might be: “Be Invisible. No player ever notices anything not directly related to their gameplay experience.”
- Or your team might be making animation tools and your direction might be: “Frictionless experience. No animator is ever waiting on anyone else to complete their work. No animator should ever wait more than five seconds to see the results of their work in-game.”
Perhaps your team has more than one mission. Perhaps your mission changes over time. Don’t get too hung up on it. We’ll adapt as we need to.
Clear expectations is not micro-managing. It means that your team can predict with some accuracy whether or not you will think things are going as anticipated. (And if not, that your teams knows whether or not they are handling the unanticipated well.)
The easiest way to enumerate some of your basic expectations for any given problem, in my experience, is to simply ask yourself: “What would frustrate me if not done or not done well?”
Where setting expectations is most difficult, that’s where it’s usually most important.
- You need clear expectations for those “soft” but extremely critical skills e.g. communication, growth, leadership, cultural fit, etc.
- You need to draw a clear line to what results your gamedevs are ultimately responsible for.
Everyone on your team is here because they are problem solvers. Give them problems to solve not solutions to implement. They are the experts (or you are helping them to become the experts.) They will spend more time with the problem, more time with their tools, more time with the data than you possibly can. Always expect your team to come up with a better solution than you can envision with your limited information.
However it’s up to you to give your team the right problems. To provide the constraints to the solutions. And make sure the problems are just outside their immediate grasp. A Junior Engine Programmer will not be able to solve the same types of problems as a Senior Engine Programmer. But both need to be challenged.
You can’t help your team if you don’t know what they’re doing. You can’t figure out how the development pieces fit together if you don’t know what’s going on. And we’ll both be a lot less effective if we don’t know where things are at. There shouldn’t be any surprises.
You will probably spend most of your time talking to your team, preparing to talk to your team, talking to others as the representative of your team, preparing to talk to others as the representative of your team or preparing your team to talk to others.
You should know your team. The gamedevs on your team should know each other. Spend time with them. Ask questions about their background and hopes for the future. Know about the things most important in their lives. e.g. Their family, hobbies, religious beliefs, food restrictions, etc.
Every gamedev on your team will need something unique. It’s up to you to figure out what that is.
Along with constant ad hoc discussions, I highly recommend that you have scheduled one-on-one meetings with every gamedev on your team. I suggest those meetings are scheduled at least once every week or two weeks. Anything less than that will be a problem.
What should a one-on-one consist of? This will be unique to you and the gamedev you are talking to. But as a general framework,
- Let them know whether or not they are meeting your expectations. Do not put this off. Do not avoid this discussion.
- Answer any questions your gamedev may have. Listen to any feedback.
- Ask probing questions.
- I find 30 minutes to be a reasonable guideline. Times can vary greatly from gamedev to gamedev and situation to situation. Sometimes 10 minutes is perfect. Sometimes you need an hour or more.
Here are some questions you could ask in a one-on-one to help start a discussion. The goal is not necessarily to get the answer to the specific question, but to open the conversation and ultimately see if there’s anything you can do to help.
- What concrete, specific feedback would you like to have about yourself?
- What has been the same for a long time that you think needs some more attention?
- What do you find most difficult?
- What do you find most frustrating?
- Where do you feel like you are being held back?
- Is there anything you feel is wasting your time?
- What do you think I need to be more aware of or paying more attention to?
- What do you think you need to be paying more attention to?
- What do you consider your next big career step? What are you doing to get there?