The following is part two of a summation of what I’ve taught in the most comprehensive of my manager training classes for game devs, a version of which was recently held at a client’s office over the course of two days. (part one can be found here)
This is not all of the things you need to know as a people leader. It’s not even all of the subjects I offer for training. But it’s the most information I’ve ever accumulated in one place and it’s been used in a real world setting to teach game dev managers, so I thought somebody might find it useful.
I typically present this material in a classroom setting using Google Slides, thus much of the value comes from my witty repartee and scintillating monologue as opposed to the written word. That’s my way of apologizing in advance for sentence fragments, colloquialisms, and Twitter-inspired verbiage. This wasn’t written for a book. It was, however, written to further my goal of putting myself out of a job by removing dysfunctionality from our industry’s people operations. When that happens I can finally move on to my much more lucrative second career in residential landscaping.
And now (minus any client-specific, proprietary information), here’s part two of the training material.
Psychological Safety
Much of this material comes from the research of Amy Edmondson, professor of leadership and management at the Harvard Business School.
Psychological safety is defined as a shared belief that the team is a safe place for interpersonal risk taking.
This sounds more formal and intimidating than it is. You already know what this feels like. When you’re meeting with your team and you can tell folks are unwilling to speak up about a topic. When you’re with a group that is verbose until the boss walks over to join you. That change in temperature is the draining away of psychological safety.
This is different from trust, which applies to a one-on-one relationship. Psychological safety is a belief about a group norm.
This topic makes my list of “things we should really be teaching managers” because:
Recently I’ve seen it cropping up more and more as a root cause for many problems in game companies.
This is a field that hardly anyone discusses even though there are obvious benefits and downsides to the presence or absence of psychological safety.
This concept of safety is plainly misunderstood by most leaders, especially the higher you go in the organization. “Well, I have an open door policy and since no one talks to me clearly our company has no problems.” That statement may win the award in two categories: Most Ubiquitous and Most Inherently Flawed.
I’ve visited client companies that proclaim every employee is very open and honest. Yet the employees themselves tell me, “Thanks for that training! It’s too bad the CEO wasn’t here, but then again we wouldn’t have had the discussions we did if he had been with us.” I’m not saying this is unusual or necessarily even bad, but it’s important to point out the perception of psychological safety in the workplace is almost always quite different between top level leaders and those closer to the front line. That’s important for any company because here are the things you lose when team members don’t feel safe...
What are the Benefits of Psychological Safety?
Aside from what you can readily imagine (like, say, promoting features and solutions rather than enduring painful silence), there are benefits that have surfaced through academic research. Empirically, these four are the most widely observed:
Improves likelihood that innovation is successful
Increases how much team members learn from mistakes
Increases employee engagement
Improves team innovation
Improving Psychological Safety
Researchers in this field recommend that leaders focus on:
Framing the work as a learning problem, not an execution problem. “There is enormous uncertainty ahead and enormous interdependence.”
Acknowledging your own fallibility. “I may miss something, so I need to hear from you.”
Being an example by demonstrating curiosity. Ask a lot of questions.
Participatory management -- empowering team members to be part of the decision making process. A closely related example is David Marquet’s notion of “pushing authority to information”.
Inclusive management -- Managing the ongoing process of including diverse perspectives. A point on diversity: Modern research is a bit divided but there’s a growing school of thought that says we may be doing diversity wrong. Typically we think Team X should have a white female, a Chinese male, a transgender German, etc -- this kind of mix achieves diversity. Some research, however, points out that background and environment have bigger parts to play, i.e. Team X would be more diverse in perspective even if it had three white males so long as they had radically different origins (e.g. big city barrio, upper middle class suburbs, hinterland farmstead).
Sample Survey of Psychological Safety
The premier researcher in this field, Amy Edmondson, created the following survey (pdf). Imagine sending this to any given team in your company and having the participants respond on a typical five-point scale, Strongly Disagree to Strongly Agree (the statements with an R next to them indicate the score should be inverted for this negative statement). How do you think your team would respond?
When someone makes a mistake in this team, it is often held against him or her (R).
In this team, it is easy to discuss difficult issues and problems.
In this team, people are sometimes rejected for being different (R).
It is completely safe to take a risk on this team.
It is difficult to ask other members of this team for help (R).
Members of this team value and respect each others' contributions.
Now we move on to One-on-one's (1:1) and Performance Reviews...
1:1's and Performance Reviews
In this and the following topics propriety demands that I pare down my comments to the company-agnostic material. When teaching managers about these issues many slides tie in to their company’s practices. There’s a lot more I’d like to share here, but can’t. And I wish I could, because this is critical. We’re getting into the most important aspects of your job as a leader, and I don’t want you to think it’s anemic drudgery or lacking in detail.
When these subjects connect with your company’s internal mechanisms there is enormous power to bring growth and fulfillment to developers. And I’m not spewing some well-rehearsed, generic, cubicle-flavored swill here. I’m speaking from the perspective of someone whose career as a game developer suffered on the truly dysfunctional end of the corporate management spectrum for 11 years. It sucked, and I didn’t even realize it at the time. I want your career and those of your teammates to be better.
Three Tiers of Feedback
In addition to my own experience, I’m drawing from Dr. Ken Blanchard’s One Minute Manager when I talk about tiers of feedback.
Daily coaching (Tier 1)
This should happen in response to events that are both positive and negative. Your team members might not know how good or bad a job they’ve done, but you should want them to know what you think, while the event is still recent. I know many people work with distributed teams, but to the best of your ability respond to events in person and within 24 hours.
1:1’s (Tier 2)
Really, this is the single most important tool in your toolbox as a manager. Companies that don’t make these mandatory at all levels do so at their own peril. We’ll talk about these in greater detail.
Performance reviews (Tier 3)
When you say “feedback” in a company setting, performance reviews are usually what people think of. Thing is, if your 1:1’s are being executed even nominally, performance reviews become perfunctory and represent a minimal investment of time. I know of one AAA studio that has evolved beyond perf reviews simply because their 1:1’s are being used so well.
Ostensibly, perf reviews are assisting the company in providing an assessment that’s as objective as possible, delivering information that allows certain HR processes to take place. In reality they’re often a billowing dumpster fire, wasting the time of all involved and providing nary a single benefit to the employees being reviewed. That was my experience for more than a decade so in addition to relating contemporary best practices, I’m mostly drawing from my own deep supply of bad examples here.
A few guidelines I’ll share: