Bonus post in the series: The Quest Guide Era — Why Enterprise Work Needs More Than Dashboards
At some point, every good metaphor has to come down from the clouds and pass through an operating model. This is inconvenient, because the clouds are very pretty and the airships have excellent lighting, but eventually someone reasonable will ask, “Okay, charming, but how does this actually work?”
And they should ask that. If the quest layer is going to be more than a beautiful idea, it has to connect to the real machinery of work: objectives, teams, owners, evidence, decisions, risks, progress, and outcomes. Otherwise we have not built an operating model. We have built a screensaver with ambitions.
So here is the actual model I am working with.
V2MOMs become expeditions. Fleets become durable capabilities. Airships become teams, service lines, or major workstreams. Crews are the people doing the work. Cargo is what they deliver. The Control Tower is the AI-enabled coordination layer that receives signal from the work and sends useful context back out.
That is the spine of it.
The annual objectives are not the ships. They are the missions. The capabilities are the fleets that keep flying year after year. The teams and workstreams are the airships moving across the sky. The people are the crew. The deliverables are the cargo. And trust is the city we are building, strengthening, and protecting.
This distinction matters because annual goals change, but capabilities endure.
A V2MOM might say we need to support a major migration, close identity gaps, improve data security, enable certification, or build automation. Those are expeditions. They have a destination, a timeline, a definition of success, and a reason the business cares.
But the fleets that support them are durable: Governance, Compliance, Customer Trust, Identity, Data Security, Product Security, Cloud Security, SecOps, Strategy and Operations. These do not disappear at the end of the fiscal year. They keep operating. They support this year’s expeditions, next year’s expeditions, and the thousand small “while we’re in here” quests that always appear wearing a suspicious hat.
The airships make the model more usable because they create a middle layer between “big capability” and “individual task.” A fleet might be Data Security, but the airships inside that fleet might represent classification, DLP, DSPM, data inventory, GenAI data protection, or ownership mapping. A fleet might be Compliance and Assurance, while its airships handle SOC 2, ISO, PCI, FedRAMP readiness, customer assurance evidence, or regulatory mapping.
This gives people a home capability and a current mission. Someone can say, “I crew the access review airship, and this quarter we are delivering cargo to Iron Gate and Golden Seal.” That sentence is strange. It is also clearer than many status updates I have seen in the wild.
Cargo is where the metaphor becomes operational.
Cargo is the work product that moves the expedition forward. It can be evidence, policies, control mappings, decision records, architecture reviews, runbooks, dashboards, metrics, automations, approvals, configurations, customer-facing assurance packets, risk acceptances, or implementation artifacts.
Cargo is not just “I did a thing.” Cargo answers, “What did this create, prove, reduce, unlock, or make possible?”
A policy update might be charter cargo. A completed access review might be gate cargo. A dashboard might be beacon cargo. A decision record might be signal cargo. Audit evidence might be sealed cargo. A workflow automation might be engine cargo.
The point is not to rename everything for theatrical reasons, although obviously I am not opposed to tasteful theatrics. The point is to make the deliverable meaningful in context.
Crews are the humans. This is important.
The people are not abstract resources in a capacity plan, which is a phrase that always sounds like it was invented by a vending machine with a minor in sadness. People have judgment, relationships, context, constraints, expertise, fatigue, courage, and the lived knowledge of how things actually get done.
In the quest layer, a crew member should be able to see which fleet they belong to, which airship they are on, which expeditions they are supporting, what cargo they own, what is blocked, which decisions affect their work, what evidence proves completion, and how their contribution ties to the larger trust outcome.
This is not just better reporting. It is better belonging.
The Control Tower ties the whole system together.
It receives meeting notes, Slack signal, Jira movement, ServiceNow tickets, audit evidence, architecture reviews, customer trust requests, executive direction, risk decisions, metrics, and AI summaries. Then it does the part organizations usually struggle to do consistently: it keeps the operating picture current.
What changed? Who needs to know? What cargo moved? What is blocked? Which route changed? Which decision unlocked the next step? Which evidence is missing? Which assumptions are stale? Which expedition is drifting into weather?
The Control Tower does not replace leadership. It helps leadership see. It does not replace teams. It helps teams move.
This is also how performance, progress, and trust outcomes become visible without making everyone perform visibility as a second job.
If the model is working, each piece of work can be tagged to the expedition it supports, the fleet or airship that owns it, the crew responsible, the cargo type, the trust outcome, the risk reduced, the evidence link, the dependency, the decision record, the status, and the confidence level.
That sounds like a lot until you realize organizations already carry all of that information. They just carry it badly, scattered across systems, meetings, memories, and the occasional heroic spreadsheet named Final_Final_v7_really_final.
The quest layer does not create complexity. It gives existing complexity a place to live.
Here is the clean version:
V2MOMs tell us what we are trying to accomplish. Expeditions make those objectives navigable. Fleets show which durable capabilities are contributing. Airships show the workstreams moving through the mission. Crews show the people doing the work. Cargo shows what is being delivered. Routes show dependencies and workflows. Weather shows risks and blockers. Beacons show metrics, readiness, and confidence. AI officers help maintain the signal. The Control Tower keeps the quest guide current.
And the whole thing exists so the organization can understand not just what happened, but what is happening, what matters, and what needs to happen next.
| Quest layer | Work equivalent | Why it matters |
|---|---|---|
| Floating City | Enterprise trust ecosystem | The larger thing being built and protected |
| V2MOM Expeditions | Annual strategic objectives | The missions for the year |
| Fleets | Durable capabilities | The long-lived functions that support many objectives |
| Airships | Teams, services, workstreams | The moving units of execution |
| Crews | People | The humans doing the work and making decisions |
| Cargo | Deliverables and evidence | The work products that prove progress |
| Routes | Workflows and dependencies | How work moves between teams and decisions |
| Weather | Risks, blockers, delays | What threatens progress |
| Beacons | Metrics, readiness, confidence | How progress and health are signaled |
| AI Officers | Specialized AI assistants | They summarize, inspect, route, and maintain context |
| Control Tower | AI-enabled source of truth | The live coordination layer |
The Zing Moment: the quest layer works because it connects strategy to motion.
V2MOMs are not just goals on a slide. Fleets are not just org chart boxes. Workstreams are not just task piles. People are not just resources. Deliverables are not just artifacts.
When mapped together, they become a living operating system for trust. The work gets a place. The people get a role. The cargo gets a purpose. The risks get visibility. The decisions get memory. And the organization gets something better than another static readout.
It gets a way to move together.
