Game development has a habit of bringing together people who are very good at different things and then assuming they all mean the same thing when they use the same words.

Take a milestone. To a development team, it might mean the game is ready to demonstrate a particular experience, with all the awkward qualifications that come with building something for the first time. To someone responsible for funding, it might mean the project has reached an agreed point and the next investment decision can be made. Both views are reasonable. Unfortunately, that does not mean they are interchangeable.

If those people do not discover the difference until the milestone review, the conversation can become uncomfortable rather quickly. The team thinks it has delivered what was asked for. Leadership thinks it has been shown something different from what it approved. The producer is somewhere in the middle, trying to work out whether the problem is the build, the expectation or the fact that nobody quite settled what the milestone meant in the first place.

This is what I mean by a failure of leadership translation. It is not a particularly glamorous phrase, I admit, but I think the problem behind it matters.

Knowing one part of the business is not the same as knowing all of it

People who have spent their careers making games bring knowledge that is hard to replace. They understand how teams work, why creative decisions take time and how much iteration can sit behind something that eventually looks effortless. That does not automatically mean they are comfortable with financing, forecasting or the obligations that come with running a business.

Equally, someone who has managed investment, governance or a large organisation can bring valuable discipline to a studio. They may ask questions that people close to the project have been avoiding. But if they do not understand how the game is being developed, a forecast can look much more certain than the work underneath it actually is.

I do not think we need to divide people into good creative leaders and bad corporate leaders, or the other way round. Most of us have areas we understand well and others where we need help. The trouble starts when a leadership team does not recognise the gaps, particularly when it is making decisions that depend on both.

A studio can be passionate about its game and still need to confront a funding problem. It can also be financially disciplined while giving a team enough space to discover what makes its game work. Neither conversation gets easier if one side treats the other as an inconvenience.

Two Incomplete Leadership Models. Games-native leader: craft knowledge; strong belief in the team and game; optimistic forecasts; late confrontation with reality; team may rely on heroes or over-expand; staff carry downside if plans fail. Corporate or finance leader: capital knowledge; portfolio logic, margin targets and process control; treats studios as assets to optimise; centralises decisions and reduces uncertainty; damages autonomy, trust and creative range; studio loses the conditions that made it valuable. Neither model is automatically wrong, but both are incomplete.
Infographic: two incomplete leadership models.

When a communication problem becomes a governance risk

Governance sounds like something that ought to happen in a room with a very long table. In practice, I am talking about questions such as: who gets to make a decision, what information do they need and what happens when the people doing the work disagree with the current plan?

Imagine a team has identified a technical uncertainty that could affect a release date. The producer raises it in a review, but nobody is quite sure whether further investigation has been approved. The team carries on with the existing plan. A senior leader later assumes the concern was resolved because it did not appear in the next report. Everyone has behaved reasonably according to their understanding, yet the uncertainty is still there.

That is a fictional example, but the mechanism is straightforward. A concern can be discussed without being assigned, an assumption can be mistaken for a decision and silence can look remarkably like agreement. By the time the consequences are obvious, the choice may be between a delay and a reduction in scope rather than between several less painful options.

This is where risk management earns its keep. Recording the risk is useful if it also makes clear who is investigating it, when the evidence will be reviewed and who can decide what happens next. Otherwise, we have merely given the uncertainty a very respectable place to sit.

The temptation to add more control

When leaders feel they cannot see what is happening, asking for more information is understandable. Extra reporting, reviews and approval steps can help if they answer a real question. They can also make the situation worse if people learn that bringing bad news results in blame, another meeting and no useful decision.

A team may then soften its assessment because it does not want to be accused of lacking confidence. Leadership receives a picture that looks healthier than the team believes it is, and asks for tighter control when the surprise eventually arrives. The next report may become even more carefully worded. That is not a problem a better dashboard can solve on its own.

A useful risk culture gives people a way to raise a concern early and see what happens to it. That does not mean every concern gets the response its author wants. It does mean someone can explain the decision, the uncertainty that remains and when it will be looked at again.

The Control Spiral. Leadership does not understand production uncertainty; adds more control, reporting and review; teams become less honest about risk; leadership receives weaker information; confidence falls; more controls are added. Trust deteriorates. Creative quality and decision speed decline. Risk lens: too much control can make teams less honest, not more aligned.
Infographic: the control spiral.

A diagnostic for the leadership team

I would use questions like these to find out whether the people making decisions and the people doing the work have a shared view of the uncertainty. The table is a starting point for a conversation, not an examination that a studio needs to pass.

Question

Healthy answer

Risk signal

What is the biggest uncertainty in the project or studio?

Leaders can name it clearly and consistently.

Leaders speak only in general confidence language.

Who owns the decision if the risk worsens?

A named person or group is accountable.

Ownership is distributed, vague or political.

Where is the decision recorded?

A decision log, risk register, board pack or project tool.

It lives in memory, Slack or private conversations.

What evidence would change the plan?

Defined triggers, thresholds or review gates exist.

The plan changes only after crisis.

Can staff escalate without punishment?

Escalation is treated as contribution.

Bad news is softened, delayed or punished.

Do creative and financial leaders review the same risk picture?

There is a shared dashboard or review cadence.

Finance sees numbers while teams see reality.

The final row needs a little care. Finance people are perfectly capable of understanding production reality, and development teams are perfectly capable of understanding numbers. The question is whether they are looking at enough of the same information to make a decision together.

Keeping the reason, not just the decision

One of the least glamorous improvements I can suggest is to write down the important decisions. Not every conversation needs to become a formal record. If a decision changes funding, scope, staffing or a studio’s autonomy, however, it is worth keeping enough information that someone can understand why it was made and what might cause it to be revisited.

Here are the examples from the original article:

Decision

Rationale

Risk considered

Owner

Review trigger

Delay feature X to post-launch.

Protect launch stability.

Player backlash, marketing mismatch, dependency impact.

Executive Producer.

If retention or marketing risk increases.

Keep team Y autonomous during integration.

Preserve creative velocity.

Loss of trust, process friction, cultural disruption.

Studio Head.

If delivery visibility drops or duplication increases.

Reduce scope before increasing headcount.

Avoid fixed-cost risk.

Schedule pressure, morale risk, reduced feature ambition.

Production Director.

If milestone confidence falls below agreed threshold.

Those owners and triggers are examples, not rules for every studio. What matters is that the people involved know what they agreed and how to bring it back if the evidence changes. Otherwise, the reason for a decision can disappear when somebody leaves, while the consequences carry on quite happily without them.

A leadership team does not need every member to be an expert in every discipline. It does need enough shared understanding to ask sensible questions and enough trust for the answers to be heard. Risk management can help create that conversation, provided we use it to make decisions rather than merely to produce reports.

I explore this approach in my book, Risk Management for Video Game Professionals, and in the Studio Risk Management course.