Something I've noticed: it's pretty common for organisations to expect their people to take ownership of what they're working on whilst structurally preventing them from doing so.
The result is that responsibility for the outcome of a system is handed down to people who have no influence over that system – whether the organisation's intentions are laudable or cynical.
And you see this idea of 'taking ownership' everywhere – job descriptions, leadership talks, company values, you name it. It sounds great, and it sounds people-focussed. But is it?
Let's explore.
Ownership vs Liability
The idea of getting development teams to 'take ownership' is an attractive one. It suggests trust. It suggests empowerment. It suggests a culture where people step up, rather than being told what to do. It suggests that, on the individual level, people and teams have control – within reason – over what it is they're working on, how they approach it, how they implement it, and what outcomes they and their team achieve.
These are good things. Really.
But, handled wrongly – when it's imposed, rather than when it's been truly integrated from the start – the result isn't ownership.
It's liability.
My position is that ownership cannot be a temporary state imposed when it suits those higher up in the organisation. True ownership isn't something that can simply be passed down; it develops over time, from seeds sown at the very beginning.
Essentially, ownership doesn't – cannot – appear when leadership asks for it. It appears naturally when the system allows it.
The Structural Problem
The problem begins when organisations use the word ownership to shift responsibility downward, into parts of the organisation where real ownership is structurally impossible. That's not to say that ownership isn't possible at those parts of the organisation; rather, that the organisational structure of the company, and how it does what it does, aren't set up to allow it.
In many organisations – and my stomping ground, games dev, is no different – the structures that determine outcomes are distributed across multiple layers.
Strategy might sit with leadership. Commercial commitments might be made by leadership and management with some input from leads. In a pitch-led scenario, there might be pressure to make sure that the organisation's bid is weighty and ambitious – but here we risk that the company's ego is writing cheques that its body can't cash.
However it's structured, wherever and whatever those outcome-determining processes are, delivery teams sit at the end of the chain.
And yet those same delivery teams are often the ones expected to 'own the outcome'.
The problem here isn't one of motivation. Most teams – most people – are perfectly willing to take ownership of their work. Most people at most places I've worked at, aren't working just to keep a chair warm for eight hours; they actively want to work on something that challenges them, that interests them, and that matters to them.
The core of this Ownership Paradox is structural. Ownership only makes sense when the people responsible for an outcome have influence over the conditions that produce that outcome. Scope, priorities, timelines, resources, constraints — these are the levers that shape delivery. And those conditions aren't just set-and-forget; if they're charged with ownership of a result, people need to feel as though they have control over the context of that ownership on an ongoing basis.
Remove influence over those levers, or ignore that plans don't survive first contact with reality, or treat your people as human resources rather than human beings, and ownership becomes symbolic.
(Incentives, where they exist, can matter here too – but they must be very carefully designed, since it sometimes isn't clear What Rewards Reward.)
Ownership sounds empowering, but in practice it simply assigns responsibility without authority.
Organisations may claim that they are entrusting their teams. But in reality, those teams are often left delivering outcomes that someone else has already decided are possible.
And when the requirements turn out to be unrealistic, the responsibility for delivery – and the blame when things go wrong – lands with the people who never had the authority to make – or at least influence – the decision in the first place.
When Responsibility and Authority Diverge
When responsibility and authority diverge like this, predictable things start to happen. Decisions that should be made close to the work are escalated upward – ownership without empowerment becomes bureaucracy, becomes delay, becomes failure.
Or production becomes a box-ticking exercise, rather than one that's meaningfully monitoring – and supporting – progress. If you're accountable for delivering a milestone but unable to influence the scope that defines it, the safest strategy is no longer ownership, but self-protection.
Anyone who has worked in game development will recognise the symptoms. Estimates become defensive. Risks are softened and hidden rather than surfaced and discussed realistically. Teams quietly adapt their behaviour to the structure around them, because the system has made genuine ownership unsafe.
Ironically, the more organisations talk about ownership in these circumstances, the less real ownership actually appears. It's a feel-good label slapped across the reality of self-preservation, of box-ticking, of death by a thousand cuts.
The Reality of Creative Systems
There is also a deeper production reality that organisations sometimes ignore: complex creative work does not behave like a fixed plan.
Games evolve, and their possibility space is discovered and expanded, throughout development. Systems interact in unexpected ways. Technical constraints might reveal themselves later than you'd want. What looks achievable in a pitch deck – or worse, blindly hopefully – can become something very different once real work begins.
Good production structures acknowledge this uncertainty and adapt as new information appears.
Bad structures pretend certainty exists – and then blame the delivery team when reality inevitably diverges from the plan.
The Ownership Paradox, then, is a structural problem. And if a problem is structural, then the solution has to be structural as well.
Three Moments Where Ownership Can Be Designed
In my experience, there are three moments in the life of a project where organisations have the opportunity to get this right.
Before production begins
In games, this is often the pitch or contract phase – the moment when ambitions are turned into commitments. This is also where the Ownership Paradox most often begins.
When delivery teams are meaningfully involved in shaping those commitments – and by meaningfully, I really mean 'they can say things that leadership or management mightn't want to hear, but they're supported when they do so' – something important happens. Risks are surfaced early. Assumptions are challenged. Estimates reflect the realities of the work rather than the aspirations of the pitch. Buffers are built in. Future milestone deliveries are confident and polished, rather than technically-correct contractual-requirement tick-box exercises.
In many cases this is also the moment where prototyping becomes invaluable. And prototyping is invaluable. A short, focused prototype phase – ideally funded and explicitly exploratory – can reveal more about the feasibility of an idea than any number of pitch decks or planning documents.
The goal here isn't polish. It's understanding. Teams might use existing code, rough prototypes in Unity or Unreal, board game analogues, hacked-together mechanics – anything that helps explore ideas, systems, technical constraints, or other unknowns quickly and while keeping sunk cost low.
Too often, however, organisations focus on generating as many ideas as possible while skipping the harder work of testing whether those ideas can actually function as systems. If you have systems thinkers on your team, use the them to their fullest extent here. People that can foresee how complex game mechanics – or code bases, or scheduling assumptions, whatever – might trip themselves up in the future are valuable as hell. Nurture them and encourage them. But, whatever your team looks like, a small amount of honest prototyping early on can save enormous amounts of pain later.
And one important distinction: prototyping is not the same thing as building a vertical slice. Vertical slices are often designed to reassure stakeholders. Prototypes are designed to answer questions. Vertical slices deliver leadership comfort, at the cost of a dev team that's knackered before they've even begun. Prototypes deliver information.
Just as importantly, the sorts of early collaboration I've been talking about signals something cultural. Leadership is not simply promising outcomes on behalf of the team – they are negotiating what is genuinely achievable. That's where real ownership begins.
During development
The second moment comes during development itself.
Even well-planned projects can get derailed once they meet with reality. Systems behave in unexpected ways. Technical constraints appear. Features interact in ways that nobody predicted at the planning stage.
Good production, and good leadership, recognises this as part of the process. Scope evolves. Milestones adjust. Expectations are renegotiated when new information appears.
This also requires treating roadmaps and milestones as guides rather than promises carved in stone. In many studios, milestones quietly turn into millstones – commitments that teams feel unable to revisit even when new information makes those commitments unrealistic. Admittedly, this sort of flexibility can be hard to capture in a contract, but it needs to be discussed, and stakeholders on both sides of the development / publisher divide need to realise that merely capturing delivery requirements in a contract appendix doesn't make them reality.
Good organisations create space for those conversations. Change is not treated as failure, but as the natural consequence of learning more about the work.
That doesn't mean abandoning structure. It means designing structures that can adapt without turning every adjustment into a political negotiation.
Change is not failure. It's simply the reality of complex creative work.
And ownership becomes possible when the system is allowed to evolve alongside the work itself.
When The Commitments Are Fixed
The third scenario is the uncomfortable one.
Sometimes the commitments are already fixed. The contract is rigid. The scope cannot move and the milestone cannot slip.
In those situations the Ownership Paradox becomes painfully visible.
The team is now responsible for delivering something that may never have been achievable in the first place.
There isn't a clean solution here. The best leadership can do is acknowledge the reality of the situation, protect the team as much as possible, and focus on delivering the best possible outcome within the constraints that exist. I've spent much of my career fine-toothing contracts for the little bits that a knackered dev team can navigate their way through in order to keep their jobs thanks to a rigid and over-promised contract. It isn't fun. And it isn't how great products get made.
Leadership Under Pressure
These situations are also where leadership behaviour becomes critical. When something goes wrong, teams watch carefully to see what happens next.
Good leaders act as a sponge. They absorb pressure from above, protect the team from blame where possible, and take responsibility for decisions that were made higher up the chain.
Bad leaders do the opposite. Responsibility flows downward while accountability disappears upward.
The difference between those two behaviours determines whether ownership – or any of the benefits that it's supposed to confer – survives the crisis or disappears entirely.
Designing Real Ownership
But the deeper truth remains: no amount of motivational language about ownership can repair a system that was structurally misaligned from the beginning.
Ownership isn't something organisations can simply ask for. It emerges when the structures around the work align responsibility with authority.
When teams have influence over the conditions that shape delivery, ownership appears naturally.
When they don't, 'ownership' becomes little more than a polite way of assigning blame.