Memo · June 2026
Standing Up an Airport
Innovation Program.
Why most programs underperform, and what to build instead.
By
Christian Kessler IV
Focus
Airport innovation · Strategy & operations
Read
14 minutes
Over the past decade, dedicated innovation programs have been started across U.S. airports, and nearly all of them have underperformed against their own expectations. The pattern is consistent enough that it cannot be attributed to bad luck, weak staffing, or insufficient executive ambition. The cause is structural: most programs are built on a model that cannot survive inside a procurement-bound, quasi-public or public organization like U.S. airports.
This short memo describes why airport innovation programs often fail, lays out the four disciplines that separate durable programs from stalled ones, and recommends a near-term strategy that “funds” the program by proving its own value. It draws on direct experience standing up and operating innovation work inside a major U.S. airport authority, on a review of program structures across North America and Europe, and on candid conversations with the people who run them.
The argument in brief
- Pilot-driven programs fail for structural reasons, not for lack of effort or talent — procurement kills a pilot’s momentum before it can scale.
- Durable programs run on four disciplines: a portfolio anchored to cost per enplanement, the will to kill weak projects, a peer relationship with the CIO, and a deliberate model for building culture.
- Fund the program by proving its own value — internal generative-AI applications that return their investment in roughly six months.
- Resist commercialization. Build instead a compounding institutional practice that makes the airport measurably cheaper to run and faster to act.
Why pilot-driven programs fail
The story plays out the same way at airport after airport. A promising company is found, a pilot is stood up with unusual speed, and for a few months it is the most exciting thing in the building — executives tour the demonstration, the local press takes notice. Then the pilot ends, the work disappears into procurement, and a year later the vendor has moved on and the capability is gone. Understanding why that arc is so consistent is the first step to building something that escapes it.
Most airport innovation programs organize themselves around commercial pilots. The appeal is obvious. Pilots feel like progress: a promising company is identified, the bureaucracy is cut through, something new is running on the ramp or in the terminal within months. Measured narrowly, these programs succeed. They are genuinely good at getting pilots launched.
“Airports are methodical purchasers by design.”
The fatal flaw is downstream. Airports are methodical purchasers by design. As public or quasi-public entities bound by open-competition requirements, they cannot quickly convert a successful pilot into a scaled deployment. The pilot must instead enter the procurement process, which routinely consumes most of a year or more and typically ends in an open competition that the pilot vendor may not even win. That delay kills momentum. Executive attention drifts to the next priority, operational sponsors rotate out, and the organization quietly internalizes the lesson that pilots never go anywhere. Launch, stalled procurement, lost momentum, quiet burial: the sequence repeats so reliably it deserves a name — the pilot death spiral.
The more corrosive effect is on the supply side. Capable vendors watch airport pilots stall in procurement, conclude the effort does not lead to revenue, and stop bringing their best ideas to the table. Over time the program degrades into a graveyard of promising demonstrations, and executives stop investing in it. Pilots can play a supporting role inside a broader program, but a program built on them has rarely delivered what its sponsors wanted.

What works: four disciplines
A portfolio anchored to cost per enplanement
Every airport executive knows CPE. What is underused is the recognition that its two components can be attacked individually. Every initiative in the portfolio of active innovation projects should declare, before it starts, whether it attacks the numerator by taking cost out of the operation or the denominator by helping airlines ultimately bring more passengers through the airport. This is not a reporting convention; it is a forcing function for project selection.
A tool that automates a manual inspection log attacks the numerator — it takes labor out of the operation and shows up directly in CPE. A capability that helps an airline turn its aircraft faster attacks the denominator — it touches no cost line, but it helps move more passengers through the same infrastructure. What matters is that every initiative can name the lever it pulls before a dollar is committed.

Kill projects ruthlessly
In an organization where the bottom line is not the binding constraint, mediocre projects do not die on their own. It is easy to let them limp along, and every one that does spreads the program thinner and feeds the cynicism that nothing here ever ends. The willingness to recommend killing an initiative, and the executive backing to actually do it, is a fundamental requirement of the program, not a nice-to-have.
The objective is to try as many things as possible and kill the unproductive ones as fast as possible. Particular caution is warranted on passenger-experience initiatives. They are appealing and easy to start, nominal gains are easy to show, the return on investment is chronically ill-defined, and they are nearly impossible to kill once underway. They are the slipperiest slope in the portfolio.
Seen across the whole portfolio, this is why the program should look like a funnel rather than a pipeline. Of twenty ideas worth a look, perhaps fifteen survive an initial review, ten earn a real experiment, five reach a pilot, and three earn an extended run. If roughly fifteen percent come through to something durable, the program is healthy — not failing. A program that advances most of what it starts is not being disciplined; it is being polite.

Independence, anchored by a peer relationship with the CIO
The innovation program should not report into the IT organization nor should IT report to the innovation program. The IT shop carries their mission-critical workload for the airport, and it should: when innovation work competes for attention inside that environment, it is deprioritized by necessity, and the friction degrades both functions. But independence is not adversarial.
The single most important governance condition for the program is that its leader operates as a genuine peer of the CIO, with a collaborative working relationship. Data access, cybersecurity posture, and the eventual operationalization of anything that succeeds all run through IT. Programs with a weak CIO relationship fail from the inside regardless of where they sit on the organization chart. Partnership, not reporting structure, is the whole of it.

A deliberate model for building innovation culture
The most durable contribution an innovation program makes is cultural: an organization that generates, tests, and advances its own ideas. There is more than one way to get there, and the models vary widely in cost. Some airports staff substantially, embedding innovation practitioners directly into capital and operational projects from the front end. Others run lean and build culture through breadth of engagement, deliberately involving as many employees as possible in identifying, testing, and championing ideas.
Both the well-resourced model and the lean model have worked. What fails is having no deliberate model at all. The right choice depends on the organization’s appetite, structure, and DNA, and identifying it is one of the first jobs of the program leader.
The funding engine: internal generative-AI applications
The most reliable way to fund an innovation program is to have it earn its keep. Internal generative-AI applications — tools that let the airport’s own staff do their existing work faster or with fewer handoffs — are unusually well suited to this. They can be built in weeks, not quarters. They can be measured against real labor lines. And they belong to the airport, not to a vendor with a renewal cycle.
A tool that reads the airport’s inbound complaint queue and drafts responses lands on the numerator side of CPE. A tool that reads the ground-surface data turns a feed the airport already receives into answers about how aircraft actually move on the ground, the kind of operational insight that once required a consulting study. Neither needs a vendor, a pilot, or a trip through procurement.
The natural objection is that if these applications are so valuable, IT should simply build them — no new program required. But that misreads what IT is built to do. The IT organization is engineered, correctly, around reliability: it runs the airport’s mission-critical systems, and its backlog, change controls, and risk posture exist to protect them. A speculative tool that might be killed in six weeks cannot compete for a place in that queue, and it should not — asking IT to work at experimental speed erodes the discipline that makes it good at its real job.
The innovation program works in the space IT is right not to occupy: it builds fast, measures honestly, kills freely, and hands the survivors to IT to be operationalized to production standards. This is the CIO partnership from Section 2 in practice — the program does the trying, IT does the running, and neither is asked to be the other.
“The program earns its budget through internal proof, not external pilots.”
Second, immediate and visible momentum: employees see and feel the benefit right away, especially with self-service tools, which builds broad-based buy-in across the organization rather than enthusiasm confined to an innovation team. Third, they instill a habit of rapid iteration and speed in an industry that has little of either. The program earns its budget through internal proof rather than external pilots, and it does so without touching the procurement machinery that strangles the pilot-driven model. Done well, this becomes a flywheel. Internal applications produce visible wins; visible wins earn executive trust; trust unlocks funding; funding buys the room to take bigger swings — which produce the next round of wins. The program stops asking to be funded and starts generating the case for its own expansion.

What not to do: commercialization
A recurring temptation is to reframe the innovation program as a revenue center — license the tools it builds, take equity in the startups it pilots, spin up a venture arm. On paper this is appealing. In practice it puts the program at war with itself. Commercialization requires a very different skill set, a very different risk posture, and a very different clock than running internal experiments inside an airport. Programs that try to do both tend to do neither well.
The more disciplined move is to keep the mission narrow. The program exists to make the airport measurably cheaper to operate and faster to act. Everything else is a distraction dressed up as an opportunity.
Closing: what innovation means in an airport
In practice, year one is concrete. It opens with two or three internal applications chosen because they have an honest path to cost per enplanement and can ship in months, not years. Each is measured, and the ones that work are talked about — loudly — so the rest of the organization comes to see innovation as something that produces results it can feel rather than slideware it can ignore. By the end of the year the program is not asking to be believed; it is pointing at what it has already delivered.
Airports are not startups, and they should not pretend to be. They are constrained, regulated, mission-critical institutions, and that is precisely why innovation inside them is valuable and rare. The programs that endure treat procurement reality, cost discipline, and operational primacy not as obstacles to route around but as the terrain the program is built for.
The objective is not to look innovative. It is to build a durable institutional practice that earns credibility one demonstrated result at a time and compounds, so that five years on the airport is measurably cheaper to operate, faster to act, and more confident in its own ideas. Building that practice requires leadership fluent in both worlds at once: the discipline of innovation and the realities of running an airport.
