Delivery

I have fond memories of the mission briefings from StarCraft. Characters of command or plot significance – Arcturus Mengsk, The Overmind, or Tassadar, to name a few – would appear as talking portraits, and convey the narrative, context, and exposition required to understand your upcoming task, then would make your objectives clear. Destroy the Zerg hatcheries. Hold this position until reinforcements arrive. Reach the beacon before the Protoss do. The goal was stated cleanly. Nothing else was given to you.

Once you got into the game, you could only see what your units could see, sometimes you'd have a view or marker of where the objective was. Fog of war covered everything beyond your immediate position. You knew where you were starting, and you knew – roughly – what you were trying to accomplish. Everything between those two points was obscured until you went and looked at it yourself.

This is, as it turns out, a precise description of what enterprise delivery actually feels like.

The objective is rarely the hard part. Someone has usually worked out what needs to happen, what the end state looks like – a platform migration, a product launch, an operating model that doesn't exist yet and needs to be built from scratch. The what arrives, stated clearly or approximately clearly, and then the briefing ends and you're left standing at the edge of a blacked-out map with your starting units and a waypoint in the distance.

What you do next is the whole job.

The complexity of enterprise delivery is genuinely staggering, and I want to be precise about what I mean by that, because the word gets used casually in ways that undersell it. It isn't just scale – though thousands of users, each with their own workflows and expectations and organizational contexts, are not a small thing. It isn't just the technical stack – though the layers of infrastructure, middleware, integration dependencies, and legacy architecture that most enterprise programs sit on top of constitute their own navigational challenge. It isn't even the process surface area – though the distance from initial concept to deployed, adopted, supported solution is longer and stranger than most people outside it appreciate.

It's all of those things, simultaneously, interacting with each other in ways that don't announce themselves in advance. A dependency you didn't map surfaces three weeks before go-live. A stakeholder who signed off in planning develops reservations when the rollout hits their division. The adoption curve you projected against one set of user behaviors encounters a different set of user behaviors, because users are not the rational actors that adoption models assume they are. The system you built to specification turns out to be not quite the system people needed, because the specification captured what they said, not what they meant.

None of this is solvable with a better Gantt chart.

The orientation that actually works in this environment – and I mean this structurally, not as a personality preference – is the one the Systems essay tried to establish at the start of this volume: zoom out far enough to see the whole map, then navigate it with enough discipline to make forward progress without losing sight of where you're trying to end up. Systems thinking, expressed as operational practice. The fog of war is always going to be there. The question is whether you've sent enough scouts in the right directions before you committed your main force.

This is what full-stack ownership means to me in practice, and it is the capability I believe separates good delivery leadership from excellent delivery leadership.

An average PM can articulate the system they directly inhabit. They know their lane, their dependencies, their stakeholders, their sprint cadence. That's the floor of the job, and it's necessary. A PM who can't navigate their own layer can't navigate anything. But their understanding of their system begins and ends at its borders: they can articulate the inputs and outputs, and the process it runs internally, but they don't understand how their system integrates into a larger whole. That's a problem, because a program at genuine scale doesn't live in one layer. It lives across a stack – from the architectural decisions being made in engineering to the adoption behaviors playing out in end-user populations, with every layer of product ownership, change management, stakeholder alignment, and operational readiness sitting between them. The PM who can only see their own layer is playing with the minimap covered.

The excellent PM – not just the good one – is the one who can move as many levels up or down the stack as the situation demands. That doesn't mean they are going to do everyone's job, but it does mean that they understand it well enough to see where things connect, where they depend on each other, where the fragile joints are, and where the intervention that looks small on the org chart will have the largest leverage on outcomes. The junior PM can articulate their own system. Where a good PM can go a level or two in either direction, the excellent PM goes as far as the problem requires, and knows when they've reached the edge of their useful understanding. That range is what makes the difference between managing a program and leading one.

Which is why the gap between delivery and adoption deserves its own treatment, because they are not the same problem.

Delivery is the technical accomplishment: the thing exists, it works, it shipped on time and within scope. Adoption is the human one: people are actually using it, in the ways it was designed to be used, with a level of fluency that produces the outcomes the delivery was meant to enable. Conflating these two is one of the most expensive mistakes a program can make. A platform can be technically excellent, delivered on schedule, and still fail at scale because the rollout treated behavior change as a communication problem rather than a systems problem. The fix is never a better training deck. It's understanding the social architecture of the organization well enough to know where trust lives and how to activate it – peer networks, champions, early adopters who can translate the new thing into the language of the people who haven't adopted it yet. That requires a different kind of map than the technical one, and the PM who can only read one of them is going to hit a wall.

This is the orientation I'd carry into game development: not a set of borrowed tools, but a way of reading the problem space before moving through it. The specific stack is different. The stakeholder dynamics have a texture I'll spend real time learning. The release pressures and community feedback loops that define live service production are not identical to what I've navigated before, and I won't pretend they are.

What I have done is navigate ambiguity at scale – repeatedly, in high-stakes environments, without a complete map – and deliver results that held up over time. The specific ambiguity that games delivery introduces is a new layer. But ambiguity at scale is not a new problem for me. It is, specifically, the problem I have spent my career learning to solve.

I’ll be up-front about all of this: I have not shipped a raid tier. I haven't built a dungeon. I haven't made a game before. I want to say that plainly, because the reader who has shipped one knows exactly how much that entails, and I have no interest in minimizing it. The domain knowledge is different. There are things I will need to learn that I do not yet know how to learn, because I don't yet know I need them. That's the nature of every new layer of ambiguity – the unknown unknowns are the ones that matter most, and you can't scout what you don't know to look for.

What I can tell you is what I do when the briefing ends and the map is dark: I send scouts. I map the stack before I commit resources. I find the layers I don't understand and develop enough fluency in them to see where they connect to the ones I do. I treat adoption as a separate problem from delivery, and I don't declare victory until both are solved. And I operate at the level of the people building the thing, not just the thing itself – because the people make the decisions that the thing is built from, and a PM who can't earn their trust can't move the work.

The briefing is always short. The map is always mostly dark.

What matters is what you do when the briefing ends.