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.
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...
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
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).
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...
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.
In addition to my own experience, I’m drawing from Dr. Ken Blanchard’s One Minute Manager when I talk about tiers of feedback.
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.
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.
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:
Perf reviews, if you feel you need them, should be driven by explicit company values and should be as lightweight as possible. Make them more frequent than once a year. Figuring out what should be assessed requires serious contemplation by company leaders. I spent months meeting with the COO and executive directors at a client to help them craft their first ever company-wide reviews. In design and delivery, ask yourself how this will value the employee.
Iterate and improve your reviews, just like everything else you do.
Retain and examine the data you’re getting from the process. What did reviewers like, what did reviewees like, what should you start/stop/change. It should be someone’s explicit responsibility to spearhead this or it will never happen.
No tool is perfect for doing reviews. Ask around for others’ recommendations and try something. Don’t waste your time trying to find exactly the right package for your company. If you implement an 80% solution you’re doing better than most organizations. BambooHR is a starting point. I’ve got multiple clients who use it.
If you’re a game company and you’re only doing annual reviews, stop. Seriously. Don’t do them. You’re better off doing no reviews at all.
There’s a ton to cover here but I’ll share what I’d consider the most important attributes for a company that doesn’t do these, or for a manager who’s new to the concept.
First off: what’s the problem we’re trying to solve? Build rapport. Whatever else you think is important about 1:1’s, and whatever you believe about how to deliver them, you should make sure you’re forging a relationship. An employee spends more of their waking hours at the workplace than anywhere else. And their connection with their supervisor is one of the main factors in determining their retention and their emotional investment. At one of my clients there’s a guy who went from Chicago to Seattle and back to Chicago (about 3000km each way) just because his manager changed jobs. He loved his manager so he followed him to each gig. If you’re just starting, I don’t care if you play games together for your 1:1’s, take a walk, sit in the break room, or go bowling. Build rapport.
Sadly, there’s a good chance you know what it’s like when you don’t trust your boss. Do you ever want your team members to feel that way about you? Here's an important point about trust from the realm of academic study: we evaluate people for trust on two axes. The first is warmth. Is the person likeable? Approachable? The second is competence. Can they do the things they’re talking about? If someone scores high enough on both axes we tend to consider them trustworthy. But even if you’re off the charts on a single axis, scoring low on the other axis can be a dealbreaker. The most experienced and intelligent tech director on the planet will still have difficulty generating trust if they’re a sociopath. And research indicates that if any given person had to pick only one, warmth is more important to people than competence.
Not sure what to talk about in your first 1:1? Spend ⅓ asking about their concerns, ⅓ talking about your feedback, and ⅓ discussing their development goals. I’d advise against feeling like you have to cram in your comments and questions, though. Really this meeting is about them. If you’re pressed for time, make sure the team member gets to use as much of it as they like. Finally, here are a few wonderful questions I found on the blog of @lara_hogan of Etsy: What makes you grumpy? How will I know when you’re grumpy? What can I do when you’re grumpy?
There are no hard rules here, but if you’re looking to get started, go with one hour every two weeks. This may change over time as the employee’s needs change and as you have more or fewer development goals to discuss. The key words here are regular and frequent. Frequent will likely mean something different to each team member, but everyone knows what regular looks likes. Do not miss your 1:1’s. Don’t cancel or postpone at the last second. There’s only one thing you can do here that will send the message “you are important to me”, but there’s a thousand ways to say, “I don’t really care about you.”
You have a million channels to get up to date on the status of a team member's work. Emails, Trello boards, JIRA filters, team meetings, Confluence, playing through their level...whatever. Don’t waste this time checking up on how many widgets they made this week. Their 1:1 is not about that.
This is a topic that doesn’t get proper examination in most companies. At a studio where I worked prior to becoming a consultant it was required that we create three development goals for each annual review.
Me: What defines a “goal”?
Them: We’re not going to tell you. But write down three of them so we can proceed to not mention them until twelve months from now in your next review with the third new lead you’ve had in the past year.
What do I recommend to ensure your goals are meaningful? Use the time-honored acronym, SMART. Yes, this is tired and hackneyed to some. But there’s a reason it’s survived all these years of corporate training and overuse: it makes sense. If your goal isn’t Specific, Measurable, Attainable, Realistic, and Time-framed, it isn’t actually a goal. A SMART goal doesn’t have to be an epic saga. You can still write one in a single sentence. You just have to think about it enough, and that’s really the point here. Make sure you understand it enough so you can tell when it’s done, and if you’re making progress on it in the meantime.
Where do goals come from? Two places: top down, and bottom up. Top down means when your CEO says “We’re going all in this year on mobile RPG’s!” then he will decompose that company goal into items that make more sense for each of this directors. The directors will decompose their goals into items that apply to each of their discipline leads or project managers. Eventually this will make its way down to the QA tester who started last week.
As a top down goal an employee’s manager might want to create a goal pertinent to an area that needs improvement. This is understandable, but as my friend Scott Crabtree points out it would’ve been pretty dumb to give Michael Jordan a performance review in which you tasked him with improving his baseball skills. Try focusing on strengths instead, which I consider a combination of a person’s affinity plus ability. Bill Gates purportedly claimed that a great programmer is worth 10000X an average programmer.
That 10000X may be hyperbole, or it may have actually been a quote from Abraham Lincoln. Hard to say. But I suspect you get the point.
Google’s own research seems to indicate something similar. Someone who’s in the top few percentiles of their field will perform exponentially better than their average performing peers. Don’t just help someone become less awful in some area of deficiency. If you want to really see a team member’s passion pay off for the company and themselves, find something they’re good at and enjoy, and help them develop into being awesome at it.
Bottom up goals are generated by the personal development interests of the employee themselves. Maybe the person who started in QA last week ultimately wants to be a creative director. What goals might they create that would help them develop in that direction? Maybe they don’t even know what goals make sense. It’s on you, their manager, to help them. A final point on personal goals, though: as one client of mine, @josephjbroni, has unequivocally stated, “This ain’t Make-a-wish.” If your team member desperately wants to develop, say, their horseback riding skills, they also need to provide a sensible business case.
Why have I spent so much time on goals? Because they’re the keystone for managers in a healthy organization. Below is a slide I’ve been given permission to share from the training I’ve delivered at a particular client. Yes, it’s client-specific, but I crafted it based on what I think is crucial for all managers everywhere.
If you’re not clear on how to create and track goals, it’s arguable that you’ll even be able to perform as a manager at all.