Over the course of my long career in the game industry, I’ve had good and bad experiences. Regardless of how a project turned out, I’ve always learned something. Sometimes I learn what NOT to do, but any time you work on a creative project with talented, passionate developers, you pick up something helpful.
Two decades ago at Westwood, I saw first-hand how valuable it is for a project to have an experienced core programming team that knows how to finish games. At Ensemble, I learned the value of iterative development and frequent team playtests. And at BonusXP, my most recent (and highly positive) experience, the piece I’ll carry forward is an idea at the core of the company’s culture, one that BonusXP’s CEO Dave Pottinger summed up with a simple phrase: grade on intent.
It’s a simple concept – when your co-workers implement a feature in a way you didn’t expect or produce work that doesn’t meet expectations, before leaping to correct what seems like an error, take a moment to understand why they did it that way. Odds are they think they did the right thing and their actions likely have good intentions behind them. If you only look at the results of their work rather than why they made certain decisions, you’ll miss the bigger picture – and your project will suffer for it.
When Meetings Get Grumpy
We’ve all been in that meeting that goes off the rails, where everyone is tired and the discussion devolves into unproductive bickering. In an early blog, I wrote about the benefits of lowering the temperature and ensuring everyone is heard. To do that, you’ve got to be willing to see problems from different angles and understand everyone’s intent.
The disconnects happen because so much of game development is subjective. There is no one perfect game; there are no perfect decisions. Everyone on the team brings their perspective about what makes a game “good.” A systems designer might love a complex game feature; a narrative specialist might be passionate about the game’s story; a programmer might be proud of how an efficient tool lets the art team do their work easier.
When serious disagreements crop up – when it seems like someone is arguing for something that doesn’t make sense – it’s exhausting and can feel like a team member is sabotaging the process or wasting time. But grading on intent is partly about recognizing the variety of experiences the team brings to the table. Fundamentally folks want to do the right thing – their intent is almost always good.
This doesn’t mean that every perspective is the right one for the finished game. A team member might not be aligned on the core vision, or they may be pushing for a decision before the project’s ready to make a call, or they may not understand the impact of a feature’s complex design on the production schedule. In a creative field like game development, it’s not going to be possible to get everyone to agree. But when meetings get grumpy, it’s an opportunity to ferret out the disconnects and realign the team.
Grade on Intent – and Effort Too
A philosophy of grading on intent has value beyond meeting etiquette – it’s helpful when evaluating a team member’s work product as well. Of the hundreds of people I’ve worked with over the years, I can count on one hand the people in development who were in the game industry for a reason other than wanting to make successful games. (Of course, “successful” means different things to different people – it may mean commercial success, critical success, or even creating a game that caters to a small, niche audience but does it very well.)
Lazy people – or people who spend all their time playing office politics – tend to get out of the business. Anyone that sticks around through the ups and downs (and bad development experiences) cares about what they do.
When a co-worker implements something in a way you disagree with – just like when they argue passionately for something in a meeting – their intent is almost always good. Maybe a programmer over-engineered a problem, adding more features than were required – or maybe they were smartly future-proofing the feature against anticipated problems. Maybe a designer wrote quest text that’s not colorful or evocative enough – or maybe they were taking important localization or diversity considerations into account when they created the content.
If a team member’s work product doesn’t hit a desired quality bar or it takes too long, it’s worth digging into the whys, rather than thinking the worst. What were the assumptions they made? What goals weren’t communicated properly upfront?
Not every choice made by every team member is going to be right for the game, but a management team that expects everything to go perfectly according to plan isn’t going to be successful. When a disconnect between vision and execution occurs, it’s a golden opportunity to improve communication, mentor an inexperienced team member, or step back and consider whether the vision itself has a flaw.
Yes, sometimes a team member just isn’t up to the job or didn’t put in the necessary effort to do it right. It happens. But if those are the first assumptions the team leads make they’re attributing bad intent or effort – when what’s happening is a problem with team communication or project direction.
Communicate with Kindness
Even when the vision is crystal clear, a project is well-funded, and the team is experienced, game development is hard. Teams that succeed support each other and have each other’s backs. “Grading on intent” is one of the best encapsulations I’ve ever heard for a path to effective teamwork. When the starting assumption is that a team member isn’t coming from a place of good intent, critical flaws in the process or vision are going to get missed.
I can hear the skeptics now: “Grading on intent sounds like a high school awarding participation trophies, regardless of results.” That’s not the idea; in the end, a team has to deliver because games have to ship, and people have to be accountable for their work output. But by assuming good intent out of the gate, rather than leaping to the idea that your co-workers are incompetent, lazy, or trying to sabotage the process, you’ll always get better results and identify problems faster.
Grading on intent, like so many good development practices, is at its core about improved team communication. Whether you’re remote, hybrid, or onsite – whether on a Zoom call or Slack chat, pairing in person with a single co-worker on a thorny engineering problem, or participating in a giant all-hands meeting – assuming the best intentions of the people you spend forty hours a week is always a good choice.
What lessons have you learned in your game career? Join the discussion in the comments! A new Scree Games blog appears every Tuesday.