Adam Nahari: Six Moves to Turn AI Pilots Into Financial Impact

An airline crew-scheduling example shows why financial outcomes depend on workflow redesign, adoption and disciplined measurement.

ANAdam NahariSpeaker · Apollo
Channel
AI Engineer
Published
Nov 2, 2026
Video
15:51
Read
4 min
Slides
4
Original
English
Open on YouTube
Scroll to read and the video shrinks to the bottom-right corner. Captions follow your reading language.
Reading languageAvailable in 2 languages
You're reading the original English.
SUMMARY

In 30 seconds

Apollo’s Adam Nahari describes six steps for enterprise AI transformation using cargo-airline crew scheduling as an example. He argues that selecting a financially meaningful problem, redesigning work, securing leadership and user ownership, and measuring adoption and economics matter more than engineering alone.

  1. 1Change management dominatesNahari uses a five-to-one change-management-to-engineering mental model.
  2. 2Three layers of AIGeneral productivity, domain-specific tools and core operational systems create different opportunities.
  3. 3Start from a financial problemChoose one or two measurable priorities with a committed user and executive support.
  4. 4Redesign the workflowThe airline optimization engine ranks possible crew solutions by cost in under a minute.
  5. 5Build with usersScheduler champions helped design and test the system before promoting adoption.
  6. 6Set stop criteria in advanceTime, metric and adoption gates are paired with a CFO-led cost-versus-impact test.

Takeaways

  1. Start with one or two financially meaningful problems and agree on a measurable baseline.
  2. Redesign the end-to-end workflow rather than merely speeding up the existing process.
  3. Secure sustained executive sponsorship and involve the people who will use the system.
  4. Give decision-makers hands-on experience with AI tools.
  5. Set time, outcome and adoption gates in advance, and test costs at scale with the CFO.
FULL TEXT

Read the edited text by chapter

Transcript only
01

Why productivity gains miss the P&L

Nahari presents an airline scheduling problem and argues that change management is central to financial impact.

I'm Adam Nahari. To understand AI transformation, start at a large cargo airline's scheduling desk. When an aircraft fails, a scheduler has 15 minutes to re-crew a flight, manually checking rest rules, qualifications and pilot locations. They may find one legal solution, not necessarily the cheapest, or none at all; premium pay becomes the release valve. Crew is the airline's second-largest cost after fuel.

AI tools are widely used, but reported financial impact is much rarer. I cited figures that over 55% of US adults had used generative AI in three years, almost 90% of businesses used AI in a function, and only 6% reported significant EBIT impact. People report real time savings, yet I argued that little of it appears in profit and loss. These are the figures I presented, not proof that every deployment has the same outcome.

In transformations I've led or observed, engineering has been the smaller part. My mental model is five units of change management for each unit of engineering: choosing the problem, getting buy-in, driving adoption and measuring impact take the effort. As models improve, I expect the engineering share to shrink further.

02

Three layers and problem selection

He distinguishes general, domain and core operational AI, then works backward from financial priorities.

Three layers of enterprise AI
SLIDE 1 / 4Three layers of enterprise AIThe slide compares individual productivity, domain-specific tools and core operational systems.

I think of business AI in three layers. General productivity tools help individuals, but when everyone has access, competitive pressure can pass gains through to prices rather than margins. Domain-specific copilots and retrieval systems help teams use enterprise knowledge. Core operational AI embeds vertical systems in the processes that make a business work, such as airline crew scheduling.

I argued that core operational improvements are harder to buy off the shelf and may therefore be retained in margins. The slide cites a McKinsey survey finding that companies reporting material EBIT impact were more than three times as likely to redesign workflows. I use that observation to motivate six moves, not to claim that redesign guarantees a particular return.

First, pick one or two problems rather than 40 pilots. Work backward from a financial metric: for an airline, routes represent demand, aircraft supply, maintenance constraints and crew costs all affect EBITDA. Crew was important enough for us to choose one initiative that could materially move the result.

Selecting the problem
SLIDE 2 / 4Selecting the problemThe airline example links EBITDA drivers to five criteria for choosing a use case.

A good problem should move a line the CFO recognizes, be measurable against a baseline agreed in advance, and have ready technology and data that the company owns. A named user—not just a department—should want to champion it, and it should rank among the CEO's top five priorities.

03

Redesign and ownership

The airline example illustrates end-to-end redesign, executive sponsorship and user participation.

Second, reimagine the whole process. Simply giving a scheduler a faster tool would produce incremental improvement. In our airline example, the larger play was an optimization engine that considered the constraints, produced possible solutions and ranked them by cost in under a minute.

Redesigning crew scheduling
SLIDE 3 / 4Redesigning crew schedulingThe slide contrasts manual scheduling with an optimization engine and decision support.

That required consolidating flight, crew and maintenance data, building the engine and providing schedulers with a decision-support app. But the engineering was still the smaller job. Getting people to use the new workflow was the larger one.

Third, start with the CEO. Before funding an initiative, I ask whether the CEO has publicly committed to it as a company priority. Without that commitment, projects encounter scheduling conflicts, delayed pilots and data requests that take weeks. The P&L owner, CFO and CTO take cues from leadership, and alignment has to be renewed over time.

Fourth, build with the business. At the airline, the VP of crew scheduling co-sponsored the transformation. We embedded scheduler champions in design from day one: they met engineering every other day, designed the interface, participated in A/B tests and brought the change to peers. They adopted it partly because they helped build it.

We also hired a CIO, a VP of data and AI, and a senior director of data science with both technical and airline-domain expertise. They could understand how schedulers worked and help design a tool around their needs. The organizational investment exceeded the technology investment.

04

Adoption and economics

Hands-on use, pre-agreed stop criteria and CFO oversight help determine whether a pilot should scale.

Fifth, put the tools in people's hands. At one executive workshop, three out of four participants had not used any AI tool before that week. I don't think someone can reliably redesign a workflow with AI without using it: experimentation is the minimum needed to develop intuition about value and possible use cases.

Sixth, set kill metrics before the pilot and let the CFO keep score. In this initiative, each stage had a 90-day time gate: if it showed no value, we would stop. We also used A/B tests against an agreed baseline and an adoption gate requiring more than half of crew schedulers to use the tool.

Three pilot gates
SLIDE 4 / 4Three pilot gatesThe slide shows time, metric and adoption gates alongside the airline operating model.

With the CFO, we also tested whether the initiative's cost at scale—including compute, tokens and the people involved—was substantially lower than the impact it would generate. Many pilots fail this economic test. Tool availability is widespread; the ability to absorb models into operations and make them stick can be a differentiator.

Returning to the scheduler: what previously took 15 minutes to find one answer can now find an answer in less than a minute. The lesson is to choose a financially meaningful problem, redesign the workflow, align leadership and users, and measure whether the change actually delivers.

More from this channel

5 slides18:33EN
AI Engineer· Nov 2, 2026Zack Proser: Build a Factory to Help Others Tell Their StoriesZack Proser · WorkOSA WorkOS blog assistant and a bedtime-story app show how AI tools can share expertise while humans retain responsibility.CreativityContent StrategyAI agents+1
5 slides15:44EN
AI Engineer· Nov 1, 2026Yijia Liang on Building Office-Compatible Engines for Finance AgentsYijia Liang · Compound AICompound’s approach combines shared agent inboxes, document engines and cited access to large data rooms.Agent engineeringSoftware engineeringDeveloper productivity
5 slides16:37EN
AI Engineer· Nov 1, 2026Nick Nisi: What a Fruit Fly Code Reviewer Reveals About Human ReviewNick Nisi · WorkOSA simulated fruit fly becomes an unlikely code reviewer—and a starting point for a team-owned automated review pipeline.Developer workflows & testingCoding agentsSoftware engineering+1
18:52EN
AI Engineer· Nov 1, 2026Hahnbee Lee and Lincoln Murr on Documentation and Payments for AI AgentsHahnbee Lee, Lincoln Murr · MintlifyAs agents increasingly read docs and use services, Mintlify and Coinbase describe the importance of accurate content, APIs, payment permissions and maintenance.Agent engineeringAgentic commerceDeveloper productivity
Slides18:45EN
AI Engineer· Nov 1, 2026Ramakrishnan Lokanathan: Evaluate the AI Agent’s Job, Not Just Its AnswerRamakrishnan LokanathanA practical framework for testing complete AI workflows, combining human feedback and regression checks with more challenging evaluations.Agent engineeringAI SafetyMachine Learning
8 slides21:39EN
AI Engineer· Oct 31, 2026Jeff Smith on Safer Database Access for AI AgentsJeff Smith · OracleOracle’s Jeff Smith explains why generated SQL can be misleading and shows how reviewed reports, schema context and database-level controls can limit agent risk.Natural-language database queriesMCP & toolsContext engineering+2