Effective Teams and Generic Problems
What problems to solve in game development?
In his popular book "Effective Executive," Peter Drucker distinguishes between generic and specific decisions. Generic decisions are those that repeat many times during a project, while specific decisions involve novel problems that occur only once. Drucker suggests creating policies and processes for generic decision-making to streamline and handle them efficiently. Since every decision is part of solving a problem, we can similarly categorize solutions and problems as either generic or specific.
In game development, we rarely categorize our problems as generic or specific. Many challenges repeat across game development teams. By identifying these recurring problems, we can better prepare for future solutions. This also helps us understand where to direct our creative energy, since not all problems require innovative solutions.
Every solution must lead to an actionable work plan with specific tasks to execute. For example, when designing a game level, you need several key elements: a story briefing, a design document outlining the level's main features, and a visual art guide that defines the constraints. These materials may or may not already exist. The process then continues with creating block-meshes, populating the level, conducting playtests, and adding final environment objects. Each of these steps becomes a task that you can assign to yourself or team members. This sequence of steps forms your solution to the problem. Once all tasks are completed, you'll have the tangible result—the finished level.
Identifying tasks and communicating them—the time spent planning steps to solve a problem—is solving a generic problem that, following Drucker's advice, can be converted into a standard procedure.
A practical implementation of this approach is to include a feature in the task management system that defines pre-made work packages—complete with tasks and workflows—for common problems. When assigned a problem, team members can simply insert the relevant work package, and all tasks will be automatically assigned with proper dependencies and workflows. This eliminates the need to spend time solving generic problems that have already been solved before.
What appears as a specific problem may actually be a globally generic one. While we might be encountering it for the first time, other teams may have already solved it many times before. A smart software system could learn from multiple teams' problems and solutions, then suggest approaches for challenges we face. Such systems could make teams highly efficient at handling previously solved problems, freeing them to focus on truly novel and unique work. This approach aligns with Drucker's advice on creating policies for generic decision-making, ultimately leading to more effective teams.
I believe the proper use of technology can help game development teams focus their most valuable asset—their attention—on problems that offer the greatest potential impact.
A key question to consider is: when should we classify a problem as generic? While established solutions may work, developing new approaches can lead to innovative products. After all, even old problems can inspire fresh solutions.