Hi friends!

I’m back with another blog post about hiring—we recently hired a wonderful artist and wanted to share the experience in the hopes that either employers or folks looking for work can learn something from our process. We were looking for a UI & 2D artist who could do a wide variety of things as we’re a small team, but hopefully this post will apply to any job postings in game development.

This post will focus on the following topics with learnings throughout:

• The job posting and applications
• Application review
• Interviewing & tests

Diversity and equity are at the core of Clever Endeavour Games and you’ll see these themes throughout the post, so they won’t have their own section. If DEI isn’t worked into every aspect of your hiring process, you should review your processes and ensure that it is.

This is a good time to acknowledge my positioning—I realize that this blog post is adjacent to discussions of DEI in the games industry, and it’s important to recognize that I’m contributing to this discussion as a white man who is also the head of a (small) successful game development studio. I’m offering my experience to share learnings and encourage reflection on hiring practices, but recognize that I’m still learning too and that there are likely aspects of this discussion that I’m missing!

Learnings and mistakes we made will show up throughout the post in bold.

Let’s get to it.

The Job Posting & Applications Received

In my 2021 blog post about hiring, I talk about writing a job description to maximize the potential of attracting diverse talent, so I won’t cover that here. Since 2021 we’ve been making sure to focus on this and have been very happy with the results.

In case you’re curious about the job posting and seeing some of these learnings in action, you can see it here.

First learning: someone mentioned that they really liked how communication was the top requirement in our job post—will do this again! It’s extremely important to our organization, especially with hybrid/remote work.

Applications & Sorting

We received a lot more applications than expected—I (naively) expected only around 60 applications, but in the end we had 353(!). I spoke to others both on our team and from other studios after and they weren’t surprised by the number given that it was an artist position. There’s a ton of competition to get art jobs (and honestly most jobs) in games.

We were hoping to get someone in Montreal or at least in Canada, but made the job available to folks outside of these regions in case we couldn’t find the talent we were looking for locally. We received 163 applications from people who were not legally allowed to work in Canada. Of the remaining 190 applications, we probably had another 40 or so who had no experience anywhere close to what we were asking for (for example, folks with an IT background who had never studied or worked in art and had no portfolio). Had we known that we would get over 300 applications, we wouldn’t have made this open to folks who are not legally allowed to work in Canada. This was a waste of our time and the time of those people who applied.

We looked almost exclusively at portfolios seeing as this was an art application. Portfolio first—if that was good, we looked at cover letters. If those were good (enough), we looked at CVs. The cover letter should explain the work on the CV that is relevant to the job, so this definitely makes the CV the last stop. This might be a personal thing, but especially for art, the understanding of art fundamentals will show up in your portfolio and I don’t need to know (or care) whether you went to art school or not.

Okay, down to around 150. We sorted through the applications by having three members of the team look through the spreadsheet with all applicants and mark in red the ones who were not up for consideration. If there was a chance they might be considered, we would leave those cells white. This helped us to break up the task and not have one person spend days on this, and it also sped up the process so that we could get back to applicants faster. We went through the remaining ones together and did another pass, marking most in red until we were down to only around 15-20. For those 15-20, we discussed them and I leaned heavily on our art director’s sense to tell us who was a better or worse fit.

Some potential areas of bias:

• Time of day — if it’s the end of the day and you’ve just seen 20 applications, you’re much less likely to give as much time and attention to the 21 as you did to the first one of the day. Depending on the person reviewing the application and their energy levels, hunger levels, etc. this can affect the reading. We tried to avoid this by having others on the team review candidates as well.
• Whether someone had been recommended by another dev or a friend — this didn’t make us judge their portfolio less critically, but it did lead to, for example, asking them to explain more about their work. This is of course special treatment that is unfair, but we tried to avoid this by having others on the team, who didn’t know the applicant, review their portfolio.
• In my previous blog post I have a big section on potential areas of bias and questions to ask yourself as an employer, so check that out!

Another learning was that we asked for references in the initial job post form—some applicants said they weren’t comfortable providing these unless asked. This was a mistake! In hindsight I think it’s inappropriate to ask for references and contact information for those references without knowing that you plan to follow up with the applicant.

Applicant Profiles

In these applications we saw a wide variety of work and profiles, but the most common ones were:

1. animators or artists who had no experience working in games, but had experience animating for cartoons or client work in either 2D or 3D, or using motion graphics
2. game artists who were 3D modelers or animators but had nothing on their portfolio about any 2D work

This leads me to the next learning: include everything you’ve done on your portfolio, and check with others in your field if you think it’s embarrassingly bad—they’ll almost certainly reassure you that it’s good enough to include. There were a couple of applicants whose 3D work or TV animation work was so good that we reached out to ask if they had other stuff they weren’t sharing—one of the 3D artists shared a large portfolio of life drawing, cartoon sketches and more which helped their application in a huge way.

Oh, another thing: if you’re an artist, please include life drawings in your portfolio! This is such a good way to show other artists, assuming they’re involved in the hiring process (which they should be), that you have a good understanding of the fundamentals of drawing humans, and likely other anthropomorphic beings.

We received almost no applications from people who had any experience with UI, even though it was in the job title. I’m not sure where those folks are! But they weren’t applying for this job—we had two, maybe three who had experience with this. That said, people can learn and part of maximizing the potential for diversity in your job application process is to understand that if someone has the necessary fundamentals, they can learn the craft you need them for. So we still did move forward with interviews for candidates who did not have games UI experience.

Where Did Applications Come From?

The best applicants came from people who reached out directly after I posted on a mailing list of other studio leads in the game development industry. This process was also super helpful because some game developers who I trust and know well recommended people they had worked with in the past, and this was a huge boost to their applications. This of course introduces bias and it’s important to note that if this was the entire job search process, it would only favour those who already have experience in the “right” places with the “right” people—i.e. the people who are already in power in already successful organizations.

Because of this potential bias, we also posted the job in as wide a variety of places as possible. This included in mailing lists from organizations in Montreal that aim to help promote gender equity in the games industry, as well as other community organizations whose missions align with our own surrounding diversity and equity. We also posted the job on WorkWithIndies, a lovely site that I personally think is the best place to post/find indie game dev jobs.

We weren’t getting a lot of applications at the start, so I started reaching out to individuals on LinkedIn who had the tag #readytowork. I ended up getting the trial for the LinkedIn business plan so that I could reach out directly to more people. This didn’t create any good leads—I mostly ended up with folks who were looking for AAA work (large companies like Ubisoft, Warner Bros, etc.) and not indie game work (smaller companies like us). Some potential leads did come about as folks answered me saying they knew someone who might be interested in the job. Again, this didn’t result in any promising applications, but I would do it again for the chance that it does.

We did not post the job through LinkedIn jobs, Indeed, or other services other than WorkWithIndies. In the last 4 jobs that we’ve posted, Indeed has not once given us even a single candidate that made it to the interview round (or anywhere close). LinkedIn was not as terrible, but still not good. In both cases, the people applying used features like “quick apply” meaning they put absolutely no work into the application, which makes sense since most of them didn’t work in this field at all. But then we still have to sort through them!

Responding to Applicants

As we went through the process of deciding who would not be considered for the job, we sent batch emails to tell applicants that they did not get the job. A number of people responded thanking us for getting back to them quickly, or for responsing to them at all. Some places don’t even send you anything if you didn’t get the job(!!). As a matter of basic respect for the people applying to the job, send them an email telling them they weren’t considered for the job as soon as you know.

We batched applicants into different groups and sent the same email to the next group once we were sure they were no longer in the running. When we had about 15 left, we told them all that we needed some more time and that we’re sorry that we hadn’t gotten back to them sooner. That said, our process is so much faster than the average (especially large companies) that I don’t imagine anyone had an issue with it. Once we got to the interview round, we interviewed 4 people but kept the other 9 around in case all of the interviews went poorly. After the interviews and tests, we knew we would go with one of those 4 we picked so we told the other 9 that they did not get the job, and provided a couple of paragraphs of explanation why—whether that was portfolio feedback, cover letter feedback, or explaining the other reasons (for example one candidate was really good but outside of Canada and with a very different time zone).

Art Tests

I went back and forth a bit in my mind about doing art tests, and I’m very glad that we did it in the end. We did a paid test (of course), and decided on six hours during a period of 10h, paid at $40/h.

The timing was chosen to allow applicants time to complete the test (since we were asking for UI and basic animation) and within a broader time period of 10h so that they could choose when they do it. This was sent on a Thursday morning, and the tests needed to be done by end of day Monday—this allowed applicants to choose a weekend day or a weekday for the work. **Quick note about inclusion here: often the people who are marginalized by our industry also tend to be in situations where they have less free time or less flexible schedules. Giving a short, fixed window will lead to more and better tests done by people with a time and flexibility privilege, which goes against our goals of inclusion.** Once they gave me their available 10h time slot, I scheduled emails to go out at the start of their time slot so they couldn’t get a head start (i.e. work way too long on something without compensation).

The $40/h pay was chosen because the job post said $70k+ salary, and there are 260 working days in the year according to the Canada Revenue Agency, so divide the yearly salary by 260, then by 7 (for 7h per day of work) and you get just under $40.

One possible source of bias with the test is that we asked applicants to think outside the box and be creative — We had some younger women applicants whose tests were not as “outside the box” as one of the male applicants—could it be that women, especially younger women, are less likely to take creative risks in tests/interview settings because our culture tells women to stay small and quiet and not to be bold? Creativity was important to us for this role, so how can we try to encourage that creative risk-taking more next time we have a test? We will make a point to address this head-on and next time, we will encourage all applicants to take creative risks, understanding that this can be harder to do naturally for more junior people or people holding identities that have been marginalized in our industry.

Vibe Checks & Interviews

I did a vibe check call before the art test, and then interviews were done after the test. Vibe check calls are super important even though they risk introducing biases. In the past, I avoided doing vibe check calls because I wanted to avoid bias—I had read a lot about how vibe checks lead to seeing how similar you are to the potential candidate and then influence you to hire people who are like you (i.e. not diverse relative to you or your organization). That said, I’ve had experiences where a vibe check call probably would have helped me to learn more about potential employees and avoid issues in the long-term, either by not hiring the person or by knowing what to look out for and what to work on when communicating with them. In hindsight, and now having experience doing vibe check calls for the last three hires, I understand that I’m not going to fall prey to this source of bias because I’m actively looking for people who are different than me—in life experience, ways of thinking, types of work experience, passions, etc. So if anything I’m actually more likely to not want to hire someone who is similar to me.

It’s important to take steps to remove bias in your hiring process, and it’s equally important to be conscious of how these steps are executed. In following bias-removal techniques blindly, you may risk hiring the wrong person and potentially even harming the diverse culture you aim to create.

In two (of four) cases, we didn’t end up interviewing the candidate after the test because the test did not meet our needs. I’m not sure if this was a mistake or not, but it felt disingenuous to set up calls with people when we knew that we weren’t going to hire them. In our email telling them they weren’t selected, we gave extensive feedback on the application and the test as well.

Our interviews were fairly short and allowed time to have the candidate ask questions. It was around 30 minutes to make sure they had time to think about and ask questions if they wanted to. I won’t include our interview questions here as that should probably be its own blog post in the future.

A Final Diversity Thought

In the end, the applicant we chose was another white dude. I say “another” because, while the only other “white dude” in the company right now is me, we started as three white men as co-founders. The company has become more diverse over the years but I was still very concerned about the perception of that and how it seems like we’re not hiring for diversity even though we say everywhere that we’re aiming for diversity and that it’s one of our core tenets.

I spoke to some others in the industry about this fear, specifically others who have worked on initiatives relating to diversity and equity in the games industry, and they reassured me that first of all, the fact that I’m even thinking about this and concerned about this perception is a very good sign. Second, they reassured me that if we grow more, we will naturally become more diverse because I’m always focused on this and it runs through every cultural pillar and every management practice that we have here at Clever Endeavour.

—

Thank you for reading! Please share this with others if you find it might be helpful to them. Good luck on your hiring (or getting hired) journey 🙂

❤
Rich

—

Bonus: Hiring Timeline

How long did it take? Not very long!

• Jan 17 — brainstorming and job description writing started
• Jan 22 — job description written and translated
• Jan 23 — job posting put up
• Jan 23 – Feb 6 —went through most applications as they came in
• Feb 6 — job posting closed
• Feb 6 — sent out emails to schedule vibe checks
• Feb 7 — did vibe checks
• Feb 8 – Feb 12 — sent test between Friday and Monday, depending on what applicants wanted
• Feb 13 — reviewed tests, sent emails to set up interviews
• Feb 14 — interviews
• Feb 14 — decided on a person
• Feb 14 — sent contract with updated information for the applicant
• Feb 15 — signed contract
• Feb 26 — employee started, could have been earlier even!

Does work constantly get thrown at you, and yet you’re also expected to produce deep thinking work? Today’s blog hopes to explore solutions of how to balance these two things for you and your team.

I was talking about work recently with a friend who is also in a management position, though not in game development and she manages a lot more people than me. As work conversations go, the feeling of being overwhelmed came up, having way too much to do and not enough time to do it.

Everything was always being thrown at her, and she was being asked to put out fire upon fire every day while also being expected to output (create) new things like programs and policies, reach out to potential partners, and improve the project management system. She was forced to be responsive and responsive only, never proactive or productive.

The Balance of Input/Output Work

Whether you’re in a leadership position or not, you may feel the need to balance the input coming in (emails, requests, meetings, fires to put out) and the output (creation of work plans, strategizing, new initiatives, etc).

The drawing below shows a day where you’d spend approximately half the time in input mode, and half the time in output mode. The amount of work you do total in either department would be the area under the curve (those shaded areas). In this case, it shows input work first thing in the morning, then some output work, back to input, and output before the work day is finished.

If you’re like my friend, however, your situation might look more like this:

This is obviously not a very good way to get output work done.

So what is a good way to get a nice balance of input to output work done? The “right” input/output graph depends on the specific person, the role, the field of work, and the team dynamic. Especially if you manage people, it’s worth thinking about because knowing what this graph looks like for each member of your team will help you plan meetings, work collaboratively, ensure focus time for your team members, and generally help you to manage people.

As the conversation continued we realized that there are at least two things we have to consider when thinking about input and output style work.

1. The total quantity of input vs output work
2. The timing and cadence of the input vs output work

1. The total quantity of input vs output work

As I mentioned, the quantity of input vs output will depend on the person, role, etc. Someone who is in a job where they produce things—an artist making art assets, a programmer writing code—should have a lot more output than input. Someone who is working a customer service job on the other hand would have almost only input in the form of requests coming at them.

2. The cadence and timing of input vs output work

Cadence: If a period of output work is too short—that is, the person is being interrupted with incoming communications or requests while trying to do output work, they won’t be able to stay focused on their task and they’re likely to perform much, much slower. Beyond that, if you (like me) believe that being in a flow state while doing output work is key to both productivity and to motivation/satisfaction at work, then having constant blips of input could be disastrous to the person and their work.

Timing: It’s important to think about when an individual is doing a certain type of work. Some people will focus super well first thing in the morning, so you don’t want to be interrupting their flow then. If two people work well late at night, you might have them do more collarborative work in the mornings. If you haven’t heard of chronotypes, I’d suggest checking them out. If your team’s input vs output work is always misaligned, collaboration will be difficult and flow will be nearly impossible.

How We Apply This at Clever Endeavour

At our studio, I’ve been trying to set a schedule where the mornings are reserved for focus (output) time and the afternoon is open discussion and collaboration (input). It’s not always perfect because different people on the team have different schedules, so sometimes we have some design-related meetings earlier in the day, sometimes folks are away at different times during the day, etc. But generally we aim for this and because we’re a small team that communicates often, we know when we’ll have to make exceptions to the plan.

Our daily check-in, weekly meeting, and any other internal or external meetings are done in the afternoon where possible (in some cases my afternoon is someone’s midnight across the world, so we have to call earlier).

For me personally, this focus time in the morning allows me to get into a flow state whether I’m working on design, HR initiatives, or more CEO-related thinking and planning work. In the afternoon, I’m doing small tasks that are too short to get into flow anyway, so I include external calls, 1 on 1 meetings, email cleanup, and any other things that would disrupt flow into the afternoon.

The hypothesis I’ve been working with, which seems to be going well so far, is that artists and programmers don’t want to be bothered, and they will perform better and feel better about their work if allowd to get into flow. Designers will have more input time but still need to be left with large blocks of time undisturbed to get into output mode. Managers and marketing folks will have even more input time, but still need some blocks of time to focus because they’re also being asked to come up with creative and well thought-out plans, like my friend mentioned above.

The important thing, in my opinion, is knowing where people want these blocks of work and making sure everyone is both aligned and knows when other people’s blocks of work are happening within a team.

Questions For You

• How much input/output should each person on your team have?
• Have you thought about how to align those times to maximize flow and maximize productivity?
• Are you often interrupting your team with inputs when they should be in output mode? (this is a common one!)

I hope these questions and this blog have given you something to think about either for your own work or for the work of the people you manage. I’d love to hear about it if you make changes that you find beneficial.

🙂

At this year’s Game Developers Conference (GDC 2023), I gave a micro-talk as part of a leadership seminar. My talk was about moving from Armored Leadership to Daring Leadership, a concept that comes from the great Brené Brown in her book Dare To Lead.

In the talk, I looked at some common problems in game development and tried to contrast what an armored approach and a daring approach would look like for each problem.

Quick primer:

Armored leadership is motivated by shame and fear. Great leaders feel fear all the time, but it’s the armor we put on when we feel fear that is the problem. Armored leadership is closed off, emotionally unavailable, defensive, cynical, keeps up an illusion of control, and uses our power over others to get things done. Where armored leadership shows up, shame and fear are almost always hiding close by.

Daring leadership is where we bring vulnerability and human emotion to the forefront of our leadership strategy. It’s open, emotionally available, meets people at eye level, encouraging, realistic and compassionate. It uses our power to help others rise up and help us tackle challenges together as a team.

So why is this useful for game development? From Dare to Lead: “Vulnerability is the emotion that we experience during times of uncertainty, risk, and emotional exposure. …Without vulnerability there is no creativity or innovation. Why? Because there is nothing more uncertain than the creative process.”

Game development is inherently creative, risky and uncertain:

Gamedev (Creative) → Uncertainty → Vulnerability

It’s our choice whether we lean into this vulnerability and learn how to work with it or if we armor up and avoid those feelings, pushing others away.

The problems I talked about in the talk are typical for leaders in game development but are not often talked about publicly. After reiterating those three (in more detail, for those of you who saw the talk and want more), I’ll talk about other common game development issues as well and apply this lens to them. Throughout these examples, you should also come to understand more about armored and daring leadership and hopefully you’ll be able to use this framework for your own issues in your teams. And, of course, I’ll leave you with homework. Let me know how it goes!

If ever you’re feeling short on time, feel free to read the first couple of examples and skip to the takeaways/homework section. Let’s go!

Running into a huge roadblock and direction shift in a project

We all run into issues while making games. Some of those issues are huge, unexpected, and put us at a crossroads where we need to shift direction in a major way. This is scary. A common armored response to this is to pretend that everything is okay, despite the obvious concerns about upcoming milestones, funding, etc.

Part of this pretending often includes fostering a culture of toxic positivity. Nobody on your team is going to bring up their concerns to a leader who is always smiling ear to ear even in the face of of obvious problems, and people see through the veil very quickly when you put on a face in order to keep up the appearance of control. Another armored strategy is to hole up and try to do it yourself, coming out of your hole with what you think are all of the solutions (spoiler alert: the solutions are worse than if you shared them with your team for feedback).

The fear shows up here because we’re worried about the project failing, running out of money, or failing our employees. As I said earlier, the fear is okay on its own. But the shame comes from concern about what our team will think of us as leaders, what the industry will think of us if we fail, what our families and friends will think of us, and if we will live up to our own (often unrealistic) expectations of ourselves*. We control these feelings of shame and fear by putting on armor (the appearance of control) and in the end, push others away.

*Small tangent here: perfectionism, a condition that plagues a lot of leaders and hurts their teams, is almost always a function of shame. This could be its own article but I would recommend reading Brené Brown’s work on this.

The daring flipside to this is acknowledging, naming, and normalizing collective fear and uncertainty. It requires opening up, sitting down with your team and expressing your fears and concerns about the situation from a place of grounded confidence but also a place of vulnerability. An example of how this might look: “I really want to ship this game on time because I’m worried that if we miss this deadline, Sony won’t take us seriously for our next project”. This can even include talking about the things underlying the shame you feel when concerned that you won’t live up to your own expectations: “I’ve always gotten things done on time and one of my favourite traits about myself is how dependable I can be. I feel like if I miss this deadline it will be a personal failure and that scares me.” While you don’t need to be asking your team for a full-blown therapy session, it can be humanizing and bring a sense of calm to know that even leaders have these feelings.

So instead of hiding that uncertainty, we can encourage the team to rally around the challenges. Leading from this place of shared commitment to overcome challenges—”I’m here with you, we’re going to get this done as a team”—will result in more buy-in from the team, as opposed to leading with compliance and control.

Employees not bringing up company-wide issues until it’s too late

We’ve all experienced issues within our teams, whether as a regular team member or a lead. And we’ve all experienced issues that are swept under the surface, only to bubble up to later, twice as powerful and noxious. How does this happen?

First, we can foster a fear of failure by treating mistakes as, well, failure. If we publicly shame people, including ourselves (note: owning your mistakes is not shaming yourself!), this shows that we fear failure and we teach others to fear that failure too, as well as its downstream consequences. If your team fears mistakes and failure then they won’t bring up company-wide issues, until the problem becomes unbearable and outweighs the fear your culture has helped to instill in them. Another way we run into this problem is by listening to individuals when they bring up problems (which is great) and then placating them in ways that are inconsistent or insincere (which is not so great). We’re afraid of failure too in this case, we’re afraid that if we make promises to make changes to help these people we won’t be able to live up to them. Or we dismiss the feedback or problem as being “just in someone’s head” because we’re concerned with how it will reflect on us (shame) if our company has these issues in it. Responding to concerns in a way that is placating, dismissive, or avoidant will lead to different people on the team having different stories about what’s going on, which will cause tension and build-up over time.

The daring approach to this would be to see failure as an opportunity for learning, and to applaud and reward team members for bringing up potential issues before it’s too late. A culture of psychological safety will help with this of course, and one way to try to ensure that is through vulnerability. Admitting that you didn’t know about a problem before a team member brings it up, admitting that the problem may have been caused by you as a leader, and taking the time and effort to truly sit down and listen to your people requires a great deal of both vulnerability and emotional availability. We can reward team members not only by showing that we’re trying to deal proactively with the problems that they’re bringing up, but also by thanking them either in one-on-one meetings or in team-wide meetings (if they’re okay with that).

Lastly, and most vulnerably of all, we can set up company-wide or team-wide conversations where everyone talks openly about what they’re feeling. In her book, Brené calls these “rumbles”—a directed and emotion-forward conversation about addressing problems with communication, between team members, etc. The key here is setting the stage—making it very known that this is an open, non-judgmental space where people are discussing ideas and improvements to the team dynamic, not blaming and shaming each other. This requires already having a team dynamic of psychological safety and open communication, and can take a while to really do well—I don’t think my team has ever truly had a “rumble” as vulnerable as Brené talks about having on her team in her book, but we’re working on getting there.

Keeping an employee on board or staying with partners for too long

One of the most common issues I hear from other leaders, and this was even more common during the pandemic, is about keeping an employee or partner on board for too long. Both parties feel a huge relief when they finally let the person go or split up.

The armored approach, driven by fear, is one of avoiding conflict and holding on to feedback in the hopes that things will change. We’re afraid of hurting the person, we’re afraid of the conflict if they push back, and we’re afraid that if they’re failing it must be our fault as their leader—this is the shame aspect that fuels this armored behaviour.

Another armored behaviour is creating a culture of passiveness, which allows us to avoid conflict, avoid the possibility of hurting another person, and avoid committing to hard and uncertain conversations. From Dare to Lead: “More than half [of the leaders in the data] talked about a cultural norm of “nice and polite” that’s leveraged as an excuse to avoid tough conversations.” This was one of the biggest issues in my studio and is something that I’m actively working on this time around after we underwent some major organizational changes. This time around, we’re ensuring a culture of candor and open conversation at all times. This could be another entire article (or three?) but I’ll leave it there for now.

In the situation of keeping an employee on board for too long or staying with partners for too long, we might blame ourselves for things that are out of our control. For example, while we play a role in an employee’s work performance, we might not be the primary cause of poor work performance (I’ve found this very hard to admit in my experience). This ties into the culture of passiveness because we hold on to that shame, that feeling that we must be failing, and avoid the hard conversation that we need to have. So this passiveness not only loads us up with emotional burden, but also allows behaviour to continue which might run counter to the culture we’re trying to build at our studio.

It also allows us to dismiss bad behaviour as a one-off event, every time it happens, as opposed to calling it out and having the necessary conversation as soon as it happens. If part of your culture includes the idea that you communicate openly with your team, so that failing is on you as much as anyone else.

The daring approach is to give regular, concise feedback, and be assertive while doing it. This is vulnerable in that it opens us up to all of the possible conflict we were avoiding, and it leads to difficult conversations with uncertain outcomes. (One of the best resources I’ve ever encountered on feedback is this 4-part Manager Tools podcast on effective feedback).

We need to get to the point and tell the employee what isn’t working, what we need from them, and ask for change that in a time-specific and measurable way. Specifically: “Here’s what isn’t working, and here’s why.” Ideally we can encourage the employee to come up with a solution on their own, and define it together. “By X date, this will be delivered in Y format.” Then, crucially, we need to ask them what they need to feel fully supported by us and work towards providing that for them.

One thing that I’ve been personally working on as a leader is being more assertive with this kind of conversation. Being more assertive and acting more quickly to give quick, small feedback has really helped me to face the small (perceived) conflict of these conversations but avoid the large-scale “we need to talk” conversations, and will hopefully help to do so in the future. I’ve historically struggled with the “being the boss” aspect and telling people what to do, thinking that it was somehow tyrannical even if it was delivered in a nice way, helps employees to achieve their goals, and works for the betterment of the project and company. If that last sentence resonates with you, then it’s important to undersand that, as Brené says, “Clear is kind. Unclear is unkind.” By avoiding conflict and armoring up in this way, it feels like we’re being nice and good and proper but we’re really leading from a place of armor, fear and shame. Time to move past that, if I haven’t convinced you yet.

Receiving feedback too late (or not at all)

We not only have to work on giving feedback, but on asking for it and receiving it too. Sometimes devs will ask me for feedback on a trailer that’s already fully edited with sound and a week away from launching. The feedback is often “had you showed me this two months ago, in storyboard, I would have had feedback”. Same with game pitches, a few days out from GDC. And folks will often work on a game for 8 months (10 months? 18 months?) without ever having it properly playtested, only to conclude that despite the problems, it’s too late to cancel it now. Three weeks in would have been a good time to start talking.

How is this armored behaviour?

We’re worried our ideas might be judged, that we might be judged based on the quality of our early work, that we might have to restart, etc. And of course the longer we wait, the worse this fear becomes because there’s more at stake—more money invested, more of our colleagues’ time invested, more attachment to the project. And how will this reflect on us as leaders, as creators? (Hear the shame voice talking yet?) What will our team think of us if our ideas aren’t perfect? What will our peers think of us if we share unpolished work? We need to have all the answers if we’re going to lead, right?

So we armor up. We become more concerned about being a knower and being right than we are with being a learner and getting it right. We need to be the person who has the answers, rather than be the person who is open to finding the answers. The daring flipside to this is to position yourself very clearly as a learner, as someone who is looking to improve, and someone who is going to get it right through feedback and learning. This can only happen if you take it seriously, you schedule regular feedback into your plans and you give it focused time and energy. It takes a great deal of vulnerability to do this, because it admits that you’re not perfect, and that you can improve with feedback (which is awesome!).

Another armored approach is to design in a black box (and this could extend to the team), without letting others into the process. “We (the individual or the team) have all the answers and know what we’re doing.”

At this point you’re like “but wait a second, I do ask for feedback!” Great. There are a few armored approaches that show up once we’ve received some feedback too.

Sometimes we’ll put role power before good ideas—”I’m the creative lead here, we’re making my game, so this is how it’s going to be.” It doesn’t always sound so malicious and evil, but this kind of thing happens all the time in games. Often, you can see the result of that in games that are poorly designed and have obvious problems that could have been fixed months or even years ago.

Alternatively, we’ve heard the feedback but we resist it because we know that it gets at something deeper, a weakness of ours or even a personality flaw that we’re afraid to confront. “Your project plan doesn’t leave any time for things to go wrong” gets at the same problem that caused you to be late for your best friend’s wedding, something which you’re deeply ashamed of to this day. (For the record this didn’t happen to me, but it probably could have).

We can try to disconnect our egos from our work, but at the end of the day this external feedback requires you to put your ego in the line of fire. So I wouldn’t say that disconnecting your ego from your work is a daring approach per se, but it is necessary if we want to be leaders, especially good ones. I think that, more importantly, we need to create a psychologically safe culture where people speak openly and focus on giving feedback on the work product and not the person creating the work product, but that’s a large topic which is covered elsewhere.

Another daring approach, other than positioning yourself as a learner, is to explicitly seek out management-specific feedback. It’s not always easy to get this feedback honestly from your team as the leader, especially if they know that you’re the one reading the feedback directly, but seeking it out explicitly means that your team at least knows that you want to improve and want to hear from them. Ideally, if the organization is large enough, you can have this feedback run through a third party, which also allows the data to become anonymized. Harder to do on my team of 4, easier to do if you have 12 people or lead a department at a larger organization.

Overwork and not respecting hours

If you’re not from the games industry, you might not know how big of a problem crunch—unpaid overtime and overworking people before major deadlines—can be in our field. If you are from the games industry, you’ve almost surely heard talk of crunch and I hope that you’ve done your best to implement a no-crunch policy in your workplace. Regardless of whether or not you experience crunch leading up to deadlines, there can still be problems of having a culture of overwork, pressure to stay later because of other team members or leaders, and a glorification of hours clocked in.

An armored leadership approach which leads to overwork and crunch is one where we work from scarcity. A mentality that there’s always too much to do and there’s never enough time will cause, even without explicitly asking for it, people to work overtime. Maybe it’s because they care about us and want to help (optimistic reading) or it’s because there’s pressure to perform and people know they will be treated worse for “leaving before the boss” (pessimistic reading). In either case it’s a problem and it’s normally the leaders’ fear or inability to manage their lives that cause this stress to be passed down to the rest of the team.

Shame inspires this armored behaviour by attaching productivity to self-worth. I bring up shame here because if one feels like they’re nothing without being hugely productive in their work then it means that they don’t believe the rest of them is very worthy on its own. If our organizations treat people who put more hours in as being more worthy, then the logical conclusion is rewarding overwork and exhaustion. This can be especially true because many leaders are “over-achievers”; if we deal with our over-achievement issues by modeling and rewarding exhaustion, that makes things worse for everyone in the organization (including ourselves, I’d argue).

The daring answer is, of course, to model and support rest and recovery as valuable parts of the working culture. This is vulnerable as it can leave us feeling like we’ll be taken advantage of, for example if we give people unlimited personal days. Rest, in Western society at least, is often perceived as “weakness” and as something to overcome, not promote. The human emotion comes in here because, especially to make change in an organization that already has a culture of overwork, we need to set the example. This will open us up to criticism and perceptions of others that go against the culture—”oh well if she’s leaving on time then she must not be a good leader”. Another daring technique is to be vulnerable and open about how the overwork has caused us harm in our own lives outside of work.

Another daring behaviour is to set boundaries. This can be especially challenging in the era of remote work and misaligned work schedules, but there are many tools and tricks you can use to make the most of your time at work and the most of your time outside of it. Just a couple of weeks before this talk was given I sat down with my team and we hashed out exactly: when we check in and check out on our communication channels, when you can ping someone directly, how you should leave them information when they’re outside of working hours, when our work schedules overlap and when meetings are to be planned, etc. This communication chat really helped me to set my own boundaries and make sure I wasn’t responding to non-urgent messages from work late at night, when I like to be off. Setting boundaries is easier to do in a work environment than, say, a family environment since at its core, work is expected to have clear boundaries. That said, it often doesn’t and it’s much easier to be proactive about this and bring it up with your team as a leader before someone on the team has to overcome the risk of starting that conversation with you and try to force your hand.

Employees feeling uncertain about the project and their futures

In several one-on-one conversations with employees over the years, I’ve seen cases where they feel uncertain about the project and consequentially, about their futures. This is not always easy to read and is not always offered up directly, so in my experience it’s worth bringing up to make sure to present the opportunity to your team to talk about it.

The armored approach is very similar to the approach talked about in the first section (Running into a huge roadblock and direction shift), so I won’t go over them again here except to say that it involves avoiding the conversation, avoiding conflict, pretending, and toxic positivity.

One daring approach to combat this is to check in regularly with your team and talk regularly about long-term goals with your employees. If they’re feeling uncertain about the project, these regular check-ins combined with an ability to listen, empathize and share our own insecurities, will lead them to open up and give us the information we need to improve the situation. This also ties into the section about dealing with problems before they become major issues, and helps us to avoid that happening. A scarier and even more vulnerable strategy is to be more transparent with your team about the situation you’re in, the company finances and budget, and plans for the future. There is, of course, a time and place and context in which to do this. It would be a bad idea to be one week away from a milestone and start freaking out in front of the team, saying that we might not have a budget in three weeks. Certain times ask for calm and grounded confidence, others for providing more information and planning and transparency. It’s easier to lead from a place of shared commitment when we can show the team what we’re working towards, why, and what will be required to get there.

Never actively talking about diversity, equity and inclusion // Feeling tension in the team around conversations about diversity, equity and inclusion

I hope and assume that at this point, we all understand how important diversity is to a team and how wonderful it can be for that team’s development and success. But sometimes, even in well-meaning teams, diversity, equity and inclusion are not talked about. When they are, they’re talked about at a very high-level, in company policies but never between people on the team in regular conversation.

The first armored reason for this is avoidance of conflict, as we’ve talked about already in this article. As a leader who comes from a privileged position (I’m white, a cis-gendered man, straight, and a Canadian living in Canada), the following was very eye-opening to me so I thought I’d share it. If you’re in a leadership position and come from any kind of privilege—that is, you’re not part of a group that is typically marginalized in this industry (gender, race, economic status, sexual orientation, etc.)—then you may never have had to face tough conversations or ever even been confronted with issues at all around equity or inclusion. This is the privilege. Folks who are marginalized in our industry (and society) face these issues every day and the fact that more privileged leaders could simply avoid this conversation is, at its very core, inequitable. The fear here shows up because we’re afraid of making mistakes that show our ignorance or lack of experience with these things, and we might be ashamed of our privilege.

This can lead to hiring people who look, think, and talk like us (whoever we are as leaders). This is pretty obviously rooted in fear—we’re worried we will have to face hard conversations or situations, we’ll have to learn to manage new cultures and ways of interacting, etc. And the shame comes in because we might fear for what others on the team might think, what others in the industry might think if we do something culturally insensitive or say something inappropriate to someone who is different from us on the team.

Good thing there’s a daring approach to this as well! Talk about it. We already mentioned positioning ourselves as a learner, and committing to getting it right through learning and feedback. It’s much more courageous to be open with our teams about things that we don’t know, admit that we’ll make mistakes, and be open to learning. To take a more proactive approach to this, we can get external help to do anti-racism or cultural sensitivity training. We can hire sensitivity readers for our games, and run our job postings and HR practices by diversity consultants. These kinds of things show that we value this kind of learning and gives us opportunities, especially in moderated sessions, to open up and be up front about what we don’t know.

We can also publicly (within the team, or publicly if we’re careful and run it by the person in question) applaud a diversity of thought and experience as a way to show that it’s appreciated. For example, if a team member suggests a game mechanic based on the sport cricket (most Canada-born Canadians like me have very little knowledge of cricket), we could clearly state why that idea would not have come up otherwise: “That’s a really cool idea, I never would have thought of that because I didn’t grow up with cricket here.”

Hiring people who don’t fit your culture

The last issue I want to bring up today is that of hiring people who don’t fit the culture, and all of the issues that can cause. We’ve already talked about keeping people on for too long, but often the issue is not as clear as poor work performance or communication. I’ve spoken to many leaders who talk about having employees who don’t quite fit but they’re not sure why or how, and only many months or years later realize what the problems were.

An armored mistake many of us make—myself included, up until those major organizational changes I mentioned before—is to have a very vague company mission and values. It’s very easy, safe, and useless to say “we inspire play” or “we’re kind”. Being vague enough about this means that we don’t actually have to act on it, and we can’t be held accountable for it, meaning we’re defended from it (read: armor). We might use this to dismiss negative events as being “exceptions”, despite being symptoms of a culture which allows these events to happen. If our employees and the external world can’t hold us accountable for our culture, then we make ourselves invulnerable to their criticism, and invulnerability is the strongest armor (someone’s going to argue with me on that).

That, or we make the mistake that many companies do when starting, which is to believe that the culture is simply something that appears as the result of people working together on a team. This can be especially true when teams start as friends who know each other and already have a rapport, a sort of “friend culture” which was established years ago. The resistance to define a culture can come from several fears—fear of getting it wrong, fear of becoming too corporate, fear of hurting the relationship between friends by establishing work boundaries.

The daring side of this coin would be making our values actionable and behaviour-oriented. Another daring behaviour is to talk about these values early on in our interview process. Talk about why we have this culture or this vision for our studio culture, and even what problems we’ve had in the past that led us to care about these values. This is vulnerable because it opens us up to losing candidates if they’re not aligned with our values (which is a good thing in the end anyway) and forces us to admit mistakes our organization has made in the past. It’s also vulnerable—and I can say this from experience—because we’re admitting the personal mistakes we’ve made to prospective employees. I can also say from experience that people really appreciate this kind of humanity in someone that they’re considering working for.

In order to combat the “friend culture”, we need to get uncomfortable together. These “rumbles” that Brené talks about force us into a room together to talk about what we’re really trying to build. We need to talk authentically and be open about the experiences we’ve had, our personal values, and our perspective on work and the world. It can be uncomfortable but is ultimately really important for leadership to stray from the usual conversations around solving design problems or creating marketing plans and into the forest that is human emotion and core values.

Homework & Take-aways

Before we get to takeaways, let’s do homework! Yay homework.

What is the number one top challenge in your work right now? Write out what an armored vs daring approach would look like for this challenge. For example, for the issue of ‘receiving feedback too late (or not at all)’, this is what my final slide looked like:

For your own issue, try to write it in the same way:

I’d invite you to do this with as many problems as you want to work on, and see if you can learn something from the exercise.

The second homework item would be to read the book Dare to Lead by Brené Brown (available wherever books are sold, try to avoid Amazon if possible), or at least to listen to some episodes of the podcast (a Spotify exclusive, at least at the time of writing).

—

So the real takeaway is this. If we want to be better leaders, have more fulfilled employees, feel more fulfilled ourselves, make better games, and make the industry a better place to work in for everyone involved, I think we need to put the armor down, open our hearts, and work on moving from armored leadership to daring leadership.

Thank you for reading!
❤ Rich

ps: here are the slides for the talk, in case you were curious.