Goal Setting, Team Management, and Data-Driven Decision-Making

Goal Setting, Team Management, and Data-Driven Decision-Making

Over the past 15 years working in game development, software development, and management, I've gathered a range of positive and negative experiences. I want to share a brief overview of these lessons and the framework that has emerged from them. In this text, I want to briefly share some of the good and bad experiences I’ve had and the framework I’ve developed over the years while working with many outstanding managers.


Vision

The most crucial factor in any team’s success is its vision. That means the organization and its teams define an image of success and identity for themselves and align all decisions and objectives toward that vision.

For example, Blizzard Entertainment’s vision is:

“Dedicated to creating the most epic entertainment experiences… ever.”

This vision helps everyone in the company stay aligned in all their decision-making. Whether a new project is being proposed or a technical decision is made, it should be measured against that vision. I’ve observed that successful companies always define their vision around the user experience.


Mission

If the vision is like the North Star—showing the overall direction but not the specifics of the path—then mission statements help define the values that guide us along that path. These values clarify the one-line vision and ensure that achieving the goal isn’t justified by any means necessary.

Following the Blizzard example, they have defined eight missions (you can read about them on their website). Their very first mission is:

“Gameplay First.”

This mission ties back to their vision of creating epic and unparalleled gaming experiences across all their products. Team members refer to these missions when making decisions, and they can challenge them if they see a conflict with these values.

A personal example comes from Cafe Bazaar. One of the values there was:

“If we wouldn’t accept something for ourselves, we shouldn’t expect it for our users.”

Sometimes, we needed to provide support or answer developers’ questions. We used a Slack group (which included other managers) to review issues quickly. This usually helped us resolve matters efficiently, but sometimes threads got lost or took longer than expected, causing user dissatisfaction.

Referring to the aforementioned value, I gathered instances where requests took too long to handle and presented the issue. Managers in that department then developed a tool to ensure these special requests would be resolved within the allotted time, improving user satisfaction.


Goal Setting

Based on the above discussion, it should be clear that goals must align with the vision and missions. Everything done in the team and organization should serve a defined goal, and each goal should meet the SMART criteria:

Specific

The goal must be clearly defined. Saying, “We want to make the best game possible,” is not exact. “Best” can differ from one person to another, leaving room for misunderstanding and making it difficult for people to align with the goal.

Measurable

The goal should be measurable, meaning you can assess progress and how close you are to achieving it at any time. Simply starting and finishing a product is not enough; we need to see ongoing progress. Goals should be broken down into smaller parts. For instance, if you’re developing a game or software, list all the main features you aim to include. Clearly define what “done” means for each feature—this way, as each part is completed, you can gauge how far you are from the final result.

Achievable

Sometimes goals exceed the team's capabilities: they may lack the necessary expertise, or the goals simply aren’t realistic. If you plan to create an online game, you need network programming expertise on the team. If it’s lacking, you have to find an alternative strategy and assess the risks. Selecting the right strategy, evaluating feasibility, and performing a risk assessment is complex, and I will discuss it in detail when talking about production stages (likely in a dedicated post).

Relevant

Earlier, we talked about vision and mission, which serve as a guiding light, setting standards, policies, and moral values for the team. Every goal must follow and serve these definitions. Sometimes, a single question can help evaluate a goal. For example: “Would Blizzard create a casual game with minimal challenge, like Animal Crossing?” No—Blizzard creates epic games. If the idea isn’t epic, it won’t be approved. That’s determined in the company’s foundational vision.

Time-Bound

In most projects—whether successful or not—failing to pay attention to time causes the greatest damage. Yes, even in successful projects, delays can prevent a product from reaching its full potential. But as we all know, the creative process is often chaotic, and it’s not always possible to estimate the time required for certain features. Therefore, you must have contingency plans (Plan B and C) in case you run short on time. Reducing features, simplifying, changing design, and even canceling a project or goal should be determined at the time of goal setting.

Once we have a clear vision, goals, and a way to measure progress, everything looks great on paper. But to ensure we stay on track and not drift away from our goals, we need measurement and monitoring. Several methods exist for monitoring, and some of them have become standards and benchmarks due to repeated use and success. One such method is OKR (Objectives and Key Results), which has proven highly effective. It was first introduced by IBM, and many companies, including Google, use OKRs to define and monitor all corporate goals.


OKR Focuses on Outcomes, Not Just Outputs

Before explaining OKRs, it’s crucial to highlight the difference between “output” and “outcome.”

Output ≠ Outcome

One of the biggest pitfalls in creative industries—including game development—is failing to distinguish between output and outcome. An output-focused mindset might say:

“I want a commercially successful RPG. Therefore, I need this list of mechanics and features—open world, skill upgrades, a map, etc. I’ll create all of them with quality.”

Despite producing a high-quality output, the product could still fail in the market and among users.

A more outcome-focused mindset works differently:

“If I want commercial success, I need to pay 100% attention to user preferences and feedback. Satisfied customers become loyal and repeat buyers, and eventually turn into ambassadors for the product. So, before making the product, I’ll spend time with my target audience to understand their likes and dislikes. Then I’ll pick the genre and mechanics. I’ll also ensure during development that I’m satisfying user preferences at every step—from costume colors to key mechanics.

I hope this clarifies the difference between output and outcome. One of the most common managerial weaknesses I’ve observed is focusing on high-quality outputs without measuring whether the outcome truly meets user or business needs.


OKR Methodology

OKR is a results-oriented goal-setting framework. You define an Objective (with SMART criteria) and then break it down into one or more Key Results that are measurable:

  • Each Key Result must be specific and measurable at any given moment.
  • Each Key Result can include one or more KPIs (Key Performance Indicators).
  • The measurement shouldn’t be just a binary (0 or 1); it should show progress over time.

OKRs can be set for annual or quarterly views. If there’s a main objective at the company level, each sub-team can interpret and redefine that objective in a way that aligns with their own work. For instance, suppose the overarching goal is to develop a high-quality game with a large player base.

  • The technical team might define key results and metrics related to the number of bugs fixed, server speed under load, and so on.
  • The art team would define quality differently, potentially focusing on accessibility, such as features for color-blind players in all UI/menus.

Another key characteristic of OKRs is that they should be stretch goals. In other words, don’t simply set objectives that match the team’s current abilities—make them slightly more ambitious. This encourages the team to grow. In OKR methodology, achieving around 60% of the defined goal is considered a success!

The discussion around OKRs can be very long—long enough for an entire book—but I won’t dive deeper into the details here. For further reading, you can refer to this source.


At this point, we have our vision, our goals, and our progress measurements. Everything looks neat on paper until we reach the stage of execution, or in other words, the human element!

In a future post, I’ll delve into the human aspects of goal-setting and team management.

Rob Sandberg

?? Helping game development teams deliver with flow to produce predictable business outcomes ?? Head of Production ??

1 个月

Nice piece! It is refreshing to see fellow game developers think?this way, given climbing development budgets, more significant risk adversity, and commercial headwinds. The irony of the game business, especially with mobile, is that it focuses on data after release but not on the data produced by its dev teams during development. Those who do look at the development phase data tend to focus on trailing measures that report issues after the fact. Developers who focus on data that signals leading indicators have a massive opportunity to get more kicks at iterating their way to fun. Techniques like flow metrics and probabilistic thinking allow teams to see the warning signs of process issues while they are happening, not after. There is a good chance they are already collecting the necessary data in Jira and need to learn how to unleash the ability to read that data in an actionable way.

要查看或添加评论,请登录

Mohamad Iraji的更多文章

社区洞察

其他会员也浏览了