Every commercial leader I've worked with has a version of the same story.
They have a question. Not a complicated one. Something like, "Of the passengers booking our new route to Frankfurt, how many are local to our hub or flowing from a regional market?" Or, "What's the attach rate of paid advanced seat assignments by fare brand by channel?"
Basic questions that should take minutes. Instead they take weeks. The data lives in a system maintained by IT. The request goes into a queue. It gets prioritized against infrastructure projects, security patches and platform "modernization." By the time the answer arrives—if it arrives—the commercial window has moved. The decision got made on instinct or not at all.
Nobody is at fault. IT is doing what it's structured to do—maintain systems, manage risk, deliver projects. The commercial team is doing what it's structured to do—move fast, respond to markets, optimize revenue. The problem is the organizational design between them.
Org charts matter
When data services reports through IT, success gets measured in technical terms. Uptime. Query performance. Tickets closed. Projects on time and on budget.
None of those metrics ask whether the data actually answered a commercial question. None of them measure whether a revenue management analyst can respond to a pricing opportunity before it expires. None of them capture the ideas that never get proposed because the commercial team already knows the answer will be "what's the priority compared to the platform migration?"
This isn't a criticism of IT leadership. It's a design problem. The metrics are rational within the structure. But the structure ensures data products get optimized for technical health rather than commercial impact.
When I was at Continental, I saw the alternative. Under the CMO's and CIO's leadership, business and technology people worked together daily—not in status meetings but in the actual work. Business directors sat in architecture meetings. Technical directors negotiated data definitions between revenue management and network planning. Nobody had to be an expert in everything, but each side could translate for their teams and make trade-offs in real time. When the business needed new customer data feeds, the request didn't go into a queue. It went into a conversation between people who understood both the commercial need and the technical constraint.
That environment taught me what business ownership of data actually feels like. And I've spent the last decade trying to recreate it.
What changes when the business owns the data
At one midsized carrier, the revenue management team spent 80% of their time wrangling data and 20% actually doing something with it.
Think about that ratio. Eight out of every ten hours downloading files, joining spreadsheets, reconciling sources, cleaning up history, formatting CSVs. Two hours doing the work they were actually hired to do—finding revenue opportunities, testing pricing strategies, improving forecast accuracy.
The first thing we did wasn't build them a dashboard. It was build them a data layer—the kind we've been talking about all week—with shared definitions, versioned history and fit-for-purpose analytical views. The processing that consumed their days got automated into a foundation. It wasn't all perfect—perfect never ships. The ratio flipped. 20% processing, 80% analysis.
And here's what mattered more than the efficiency gain. Once the team wasn't spending every day just assembling data, they started asking questions nobody had time to ask before. Booking curves by time-band, point of sale and elite status—whatever leadership wanted, whenever they wanted it. Forecast improvements that boosted RASM enough to pay for the commercial data layer we'd built in four months.
The RM team didn't just use the data layer—they owned the analytical products built on top of it. When a forecast view was wrong, they didn't file a ticket. They sat with a forward-deployed data team inside their own department, walked through the business logic and resolved it in hours, not sprints. When we trained that team to maintain the layer themselves, the knowledge transfer stuck—because they already understood what the data meant and why it was structured the way it was.
That's not a technical outcome. That's an organizational transformation. The organization went from "not enough data" to "not enough data people."
The organization went from ‘not enough data’ to ‘not enough data people.’
This isn't just a data team problem
I've seen the same dynamic at every scale. Newly formed fare merchandising teams were waiting three weeks minimum to produce a campaign—brief to copywriter, copywriter to designer, designer to developer to production. We implemented a content management system that put campaign execution directly in marketers' hands. Production time went from three weeks to three hours, and personalized campaign volume increased 100x. Not because the technology was revolutionary—it was a bad Microsoft product that mercifully doesn't exist in that form anymore—but because the people closest to the customer finally controlled the tools.
That was twenty years ago, on a tool nobody would choose today. The tools are far better now—the instinct is identical. "We'll have AI code the landing pages." "We bought the industry-leading headless CMS." But it doesn't matter how good the platform is. If your marketing team runs the best headless CMS on the market and still can't get a landing page live without a queue, the tool was never the constraint. The access was.
The proof is in what happens next
The strongest evidence for business ownership isn't the initial efficiency gain. It's what the organization does afterward.
At one carrier, a single analyst in revenue management came in every morning and pushed a button to update a set of Access databases that produced a forecast on his local machine. No infrastructure. No enterprise architecture. Just one person proving that data could drive value. That manual process—one person, one button, every morning—became the seed for a sophisticated revenue management system, a large team and a level of autonomy no other department has. They earned it by demonstrating, day after day, that they could make data work for their business.
That's the pattern.
Prove value. Earn ownership. Build a team around success.
What this means Monday morning
If you're building the data: design your products to be owned by the business, not just consumed by them—naming conventions the commercial team understands, business logic documented in business terms, enough transparency that an analyst can troubleshoot without a ticket. Your goal is to build something they can't imagine working without—and can maintain the last mile themselves.
If you're leading a data team: stop measuring success by technical delivery and start measuring it by commercial outcomes enabled. Did RM improve forecast accuracy? Did marketing increase campaign velocity? If you can't connect your team's work to those outcomes, the business case for your team stays fragile.
If you're the executive funding the investment: look at where your data team reports. If it reports through IT, ask whether the incentives align with commercial outcomes or technical operations. This isn't about moving boxes on an org chart tomorrow. The teams closest to the commercial question should have direct influence over the data products that answer it. Fund ownership, the infrastructure will follow.
The organizations that get the best returns from their data investments aren't the ones with the best technology. They're the ones where commercial teams own the analytical products that drive their decisions—and have the autonomy, the skill and the standing to evolve them.
What's in the pipeline
Future Travel Experience ran a piece this week on agentic AI pulling retailing, digital and CX into one commercial motion—airline teams "joining AI meetings together" instead of defending their own systems. The line that stuck with me was the one at the end: the data and the technology will enable the convergence, but organizational alignment and the human factors are the harder problem. That's the whole newsletter in someone else's words. The agent doesn't fix the org chart. It just exposes which orgs were never aligned in the first place.
Databricks shipped a quiet update to its Genie data agent this week: its reasoning traces now cite the definition behind each answer. Ask for revenue by route and it tells you which revenue it means—booked or flown, before exchanges or after. The logic, surfaced, not buried. Eighteen months ago I'd have called that the whole game. Now I'd add a caveat. The feature answers a technical question—what did the agent do. It can't answer the business one—was that the right thing to do. Everyone wants an agentic strategy. Almost no one at an airline can tell you who owns the number the agent is about to cite, or whether the business ever agreed it was right. The tooling keeps getting more sophisticated. The unanswered question underneath it hasn't changed in twenty years. It was never what the technology can do. It's whether the business has decided what it needs.
What I'm cooking this week
Tuesday I'm at the Skift Data + AI Summit. Looking forward to a day of travel tech not centered on airlines—keeps me thinking bigger. The conversation behind the keynotes—the plumbing. Who owns the data, who can reach it, who's allowed to act on it. Everything I wrote today, argued at the industry level. If you're there, let’s connect.
The carry-on
Vendors saying the org is the hard part. AI footnoting its own work. An AI summit pretending, not pretending, to talk about data.
Same lesson, three rooms. The technology keeps racing ahead. The business questions continue to be left unanswered. We have to ask: Who owns this? What did we decide it means? What are we actually trying to do? You can buy every tool mentioned in that room Tuesday or in that west coast conference next week. You can't buy the relentless focus on your business that makes any of them worth owning. That's the one thing no vendor sells and no migration delivers. It’s what leaders bring to this work.
Next week: the last of the five, and the one the whole series has been building toward. The Independence Pattern—why the organizations that own their data layer own their destiny.
—Ben