If it’s not obvious from Part I of this post, I like to ask questions that seem simple, but usually have an interesting and familiar production dilemma just beneath the surface. Most candidates can draw from real world examples to answer the questions (and if they struggle to, it helps me calibrate their practical experience). In the best conversations, there’s always a sort of “Aha!” that leads to a more structured answer around the process the candidate uses to support challenges they have seen repeated on multiple projects.
At some point in their tenure, most professionals switch from reacting to challenges to planning ahead. I call this switching from a trailing methodology to a leading methodology. In a trailing methodology, you solve things after they happen (usually after they have caused you pain). In a leading methodology, you know what’s coming and can solve for an issue before it ever arrives. This transition point is the best mark of seniority I know of. It’s one of the intangibles I try to get out of every interview.
Part II of this post deals with more of those intangibles. Where Part I focused on what you might call “producer acumen” the base sets of skills producers should have, Part II is more about sensibilities, seniority and leadership abilities most producers should have. Things like Dealing with Ambiguity, Collaboration, Ownership, Quality Orientation, Player Orientation, and People Skills.
Q: Method you used to clarify and operationalize an ambiguous goal?
Most modern tech companies try to stay agile by pushing ownership to the front lines of development. The idea is that small, highly empowered teams can respond to player or customer needs far more quickly than an old school corporate mandate. It’s a great practice, but also produces a lot of ambiguity around the right way to achieve a goal, or, indeed, which is even the right goal to pursue. Dealing with ambiguity has become an important skill in the tech work force—and for producers in particular.
I’m embarrassed to reveal how often I’ve been surprised by the first question a really good producer asks when they get an assignment. You know you’re dealing with a great operator when the first thing they say is, “When do you need it by?” They are already taking steps to prioritize, manage expectations, and get the work done.
Sometimes goals are vague, and producers have to figure out how to make progress even though the desired outcome is not well defined. “Improve frame rate.” Or “Make the game more accessible.” There can be a mountain of tradeoff and design between vague goals like these and getting to work. The purpose of this question is to understand whether the candidate knows how to manage both the team and stakeholders into a shared vision of the work to be done.
Since it’s the job of a producer to deliver an outcome, I love answers that focus on defining that outcome. The two most powerful questions a producer can ask to break through ambiguity are, “What’s the date?” and “What’s the deliverable?” I’m amazed how often I am working with teams who are in a heated debate, but haven’t clarified what they are actually working on. I’ll sometimes ask them to pause and answer the question—is it a document? A design? A prototype? A wireframe? A brainstorm of ideas? Putting the deliverable question out there almost always orients the team to actionable work and produces forward progress.
At Amazon, I was once impressed by another simple, obvious question. A project leader was describing the work his team had done during the previous week. One accomplishment was that they had reduced latency on a player attack. The question was, “What’s the from and to?” Such a simple question, but so pregnant with meaning! Was it a micro improvement, or truly significant? And underneath it all, was the effort worth it? Defining the “from” and the “to” are hugely helpful ways to reduce ambiguity.
The best answer to this question will include more questions, and simple practices around defining outcomes. My favorite is simple: “Write it down.” Writing a goal out, including dates, deliverables, and the metrics by which you will measure the “from” and the “to” almost always produce better goals and forward progress.
Q: Decision you made at the start of a project that had the biggest impact on the end result?
This is my favorite question. It’s my “stranded on a desert island and you can only have one question” question. In order to be successful, all producers have to be able to work with a degree of autonomy. They need to be able to establish priorities, focus development, provide feedback, and make hundreds of small, “steering” decisions every day. And, in the end, they have to own the outcome of those decisions.
It’s deceptively simple—tell me about a decision you made, and the resulting impact. But the way it’s worded teases out a producer’s experience over the full arc of development, which is incredibly revealing when it comes to 1) the candidate’s experience going end-to-end on a production, 2) the scope of decision they have been trusted with in the past, and 3) their ability to form a clear vision of a player experience from the earliest days of a production. The answer to this question invariably tells me everything I need to know about a candidate’s sense of ownership and follow through.
Sometimes a candidate will struggle. I can tell they’re reaching for a decision that had sweeping impact. Big, simple decisions can create genre explosions—like the perma-death decision and survival crafting, or the auto attack and Vampire Survivors/Bullet Heaven. But it’s OK if you didn’t contribute health regen or iron sights to the FPS, or rapid death-respawn to roguelikes. I really just want to know that you made a decision that had a meaningful impact on the play experience. It tells me you collaborated effectively. You were a persuasive and engaged member of your team. You didn’t hang back, but offered solutions and were empowered to make decisions.
A great answer might be something as simple as, “I drove the lock picking mini-game in the ARPG I worked on,” or “I advocated for Shotgrid as a way to track separate assets and approvals and improve our modeling pipelines.” Even the most simple mechanics or workflows connect easily to larger game design and production sensibilities, an understanding of tradeoffs, and deep, deep ownership of the resulting player experience.
Q: Method you used to share progress/results with the team, so they knew how they were doing vs. expectations?
Contrary to the Hollywood depictions, game development is hard work. Most developers are highly self-motivated, and take pride in making contributions to the game. So how do you convey to a team who feels passionate and proud of the work that they’re doing that they’re actually off track vs. expectations? The best way is with data.
Producers own most of the development data. They usually own project schedules, and, symbolically, the successful achievement—or not—of those schedules. This can put producers in the role of task masters or grinders, steadily scoring the work output of the team on their way to becoming its least popular member.
But working with teams is only half of the job. I often describe a producer’s role not as a pyramid, but an hourglass. Producers are responsible for the work output of large teams (the pyramid) but also accountable to large numbers of stakeholders (the top of the hourglass). In the pre-pandemic days, you only had to brush past a stakeholder in the hall to get asked, “How’s the game going?” Which, of course, is code for, “Are you going to ship on time?”
Good answers to this question will focus on hard data around how the schedule is incremented, and expected progress in each increment. This involves creating and maintaining milestone checklists, validating results, often holding retrospectives and steering the plan. However, answers in the general theme of milestones always tend to assume that the game stays on track through the life of development—which no game ever does.
So even better answers acknowledge that games can go off track. They focus on recognizing and correcting issues quickly (hours or days, not weeks or months). Really great answers will include crisp and demanding phase definitions and, often, accepted delays in order to achieve intended results and measure precisely how much longer an effort took than predicted.
The best answers will break down generally into three parts. Part one is instrumentation. What is the process of capturing data from development? This can be sprint and milestone deliverables and dates created by the team, but also issue tracking, defect rates and crisp phase definitions.
Part two is reporting. Once you have the info, how is it shared with the team in an empowering way? How does shared data lead the team to a unified conclusion? Information can be presented back to the team in the form of milestone checklists, daily burndowns, retrospectives or sprint reports.
Part three is some definition of the overall goal, a master feature list, Alpha definition, road map or other gate that represents the finish line.
Q: Big tradeoff you had to make to achieve expectations?
In discussing their background, most candidates present their past projects in a somewhat gauzy light, delivering all features on schedule and on budget, which is almost never the case. The tradeoff question is an excellent way to learn about a candidate’s ownership, flexibility, and ability to build consensus with their team and stakeholders. It’s also a great way to learn about a candidate’s real experience: if they have never made a tradeoff in order to deliver for the business, they probably have never had meaningful project responsibility.
Game developers are entrepreneurial and ambitious by nature. Games, after all, are an art, and all developers are inherently artists, with a desire to entertain, impress, and put on the best possible show. Given that, in the best of situations, scope management is always an issue.
Even beyond the initial vision, there always comes a time when the software begins to speak back to you—when you learn what’s fun and engaging, and what fails to impress in the way you’d hoped. These moments always lead to some kind of doubling down, scope creep or aggressive release date which puts further pressure on the schedule.
Since teams often get paid regardless of meeting their deadlines (except in scorched earth scenarios we’re starting to see all too frequently), the general bias among developers is to add as much gold plating as possible, schedule and cost be damned. How a candidate manages this balancing act is usually a great reflection of their degree of ownership, and how deeply connected they are to a business that is dependent upon their success.
No project gets a blank check in time, budget or quality. Asking about tradeoffs helps me understand how a producer navigates priorities. It tells me where the candidate believes product value lies. It tells me how much stock they put into business commitments like budget and release date vs. the team’s aspirations and vision for the final product. The answer will also say a lot about how the candidate uses data in their decision-making process, since tradeoffs are often connected to customer KPI’s, feature priority rankings, or market research.
The best answers to this question always come back to a core vision, and the focused set of features which are the essence of that vision. I don’t know that there’s a right answer, but I typically listen for three things. First, was the candidate able to deliver a complete project vision, even when they had to make a tradeoff? Second, did the candidate prioritize quality? I love hearing that they reserved time for polish and bug fixing rather than slipping their Alpha date to get one last feature in. Third, how did they manage the expectations they needed to satisfy? No tradeoff is worth it if the product fails and the business is not successful.
So there you have it. If you’ve read this far, thank you. If we’re ever lucky enough to interview together, you now know all my secret questions. I’m sure you’ll ace it.
Good luck, and see you next time.
