If it\u2019s 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\u2019s always a sort of \u201cAha!\u201d that leads to a more structured answer around the process the candidate uses to support challenges they have seen repeated on multiple projects.<\/p>\n\n\n\n
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\u2019s coming and can solve for an issue before it ever arrives. This transition point is the best mark of seniority I know of. It\u2019s one of the intangibles I try to get out of every interview.<\/p>\n\n\n\n
Part II of this post deals with more of those intangibles. Where Part I focused on what you might call \u201cproducer acumen\u201d 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.<\/p>\n\n\n\n
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\u2019s 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\u2014and for producers in particular.<\/p>\n\n\n\n
I\u2019m embarrassed to reveal how often I\u2019ve been surprised by the first question a really good producer asks when they get an assignment. You know you\u2019re dealing with a great operator when the first thing they say is, \u201cWhen do you need it by?\u201d They are already taking steps to prioritize, manage expectations, and get the work done.<\/p>\n\n\n\n
Sometimes goals are vague, and producers have to figure out how to make progress even though the desired outcome is not well defined. \u201cImprove frame rate.\u201d Or \u201cMake the game more accessible.\u201d 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.<\/p>\n\n\n\n
Since it\u2019s 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, \u201cWhat\u2019s the date?\u201d and \u201cWhat\u2019s the deliverable?\u201d I\u2019m amazed how often I am working with teams who are in a heated debate, but haven\u2019t clarified what they are actually working on. I\u2019ll sometimes ask them to pause and answer the question\u2014is 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, \u201cWhat\u2019s the from and to?\u201d 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 \u201cfrom\u201d and the \u201cto\u201d are hugely helpful ways to reduce ambiguity.<\/p>\n\n\n\n
The best answer to this question will include more questions, and simple practices around defining outcomes. My favorite is simple: \u201cWrite it down.\u201d Writing a goal out, including dates, deliverables, and the metrics by which you will measure the \u201cfrom\u201d and the \u201cto\u201d almost always produce better goals and forward progress.<\/p>\n\n\n\n
This is my favorite question. It\u2019s my \u201cstranded on a desert island and you can only have one question\u201d 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, \u201csteering\u201d decisions every day. And, in the end, they have to own the outcome of those decisions.<\/p>\n\n\n\n
It\u2019s deceptively simple\u2014tell me about a decision you made, and the resulting impact. But the way it\u2019s worded teases out a producer\u2019s experience over the full arc of development, which is incredibly revealing when it comes to 1) the candidate\u2019s 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\u2019s sense of ownership and follow through.<\/p>\n\n\n\n
Sometimes a candidate will struggle. I can tell they\u2019re reaching for a decision that had sweeping impact. Big, simple decisions can create genre explosions\u2014like the perma-death decision and survival crafting, or the auto attack and Vampire Survivors\/Bullet Heaven. But it\u2019s OK if you didn\u2019t 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\u2019t hang back, but offered solutions and were empowered to make decisions.<\/p>\n\n\n\n
A great answer might be something as simple as, \u201cI drove the lock picking mini-game in the ARPG I worked on,\u201d or \u201cI advocated for Shotgrid as a way to track separate assets and approvals and improve our modeling pipelines.\u201d 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.<\/p>\n\n\n\n
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\u2019re doing that they\u2019re actually off track vs. expectations? The best way is with data.<\/p>\n\n\n\n
Producers own most of the development data. They usually own project schedules, and, symbolically, the successful achievement\u2014or not\u2014of 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\u2019s 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, \u201cHow\u2019s the game going?\u201d Which, of course, is code for, \u201cAre you going to ship on time?\u201d<\/p>\n\n\n\n
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\u2014which no game ever does.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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\u2019s ownership, flexibility, and ability to build consensus with their team and stakeholders. It\u2019s also a great way to learn about a candidate\u2019s real experience: if they have never made a tradeoff in order to deliver for the business, they probably have never had meaningful project responsibility.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Even beyond the initial vision, there always comes a time when the software begins to speak back to you\u2014when you learn what\u2019s fun and engaging, and what fails to impress in the way you\u2019d hoped. These moments always lead to some kind of doubling down, scope creep or aggressive release date which puts further pressure on the schedule.<\/p>\n\n\n\n
Since teams often get paid regardless of meeting their deadlines (except in scorched earth scenarios we\u2019re 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.<\/p>\n\n\n\n
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\u2019s 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\u2019s, feature priority rankings, or market research.<\/p>\n\n\n\n
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\u2019t know that there\u2019s 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.<\/p>\n\n\n\n
So there you have it. If you\u2019ve read this far, thank you. If we\u2019re ever lucky enough to interview together, you now know all my secret questions. I\u2019m sure you\u2019ll ace it.<\/p>\n\n\n\n
Good luck, and see you next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
If it\u2019s 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). […]<\/p>\n","protected":false},"author":1,"featured_media":55,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-container-style":"default","site-container-layout":"default","site-sidebar-layout":"default","disable-article-header":"default","disable-site-header":"default","disable-site-footer":"default","disable-content-area-spacing":"default","footnotes":""},"categories":[8,7,10],"tags":[],"class_list":["post-44","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-leadership","category-teambuilding","category-virtues"],"_links":{"self":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts\/44","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=44"}],"version-history":[{"count":5,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts\/44\/revisions"}],"predecessor-version":[{"id":62,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/posts\/44\/revisions\/62"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=\/wp\/v2\/media\/55"}],"wp:attachment":[{"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=44"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=44"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.attack-pattern.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=44"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}