Your “AI Strategy” Is Just AI Strategy Theater
What the Apache Iceberg ecosystem gets right about aligning Engineering, Product, GTM into outcomes people can actually ship
Let me tell you the exact moment I learned “alignment” isn’t a soft skill.
A Founder leaned over to the CPO right before a board meeting and whispered:
“Slides 8-10 are too busy. Can we just present 8 with the OKRs?”
He wanted to announce a win: “We launched a new app for a segment.”
Instead, he had that sinking feeling:
We were going to miss the public launch.
And the sick part?
The team looked busy.
Kanban board glowing. Burndowns “healthy.” Sprint ceremonies tight. Cards flying out of the factory like we were printing outcomes.
But reality didn’t care.
Because go-to-market objectives weren’t pulled into the dev lifecycle early enough, so we weren’t shipping outcomes.
We were shipping motion.
The lie we tell ourselves: “We just need to move faster.”
Most teams say they want to “move faster.”
What they really mean is:
“We want fewer surprises.”
Here’s the missing translation layer:
Builders reduce surprises by turning ambiguity into systems.
Business leaders reduce surprises by turning systems into outcomes with constraints and a decision cadence.
One-liner that stings because it’s true:
The gap between “great engineering” and “great business” is rarely talent. It’s translation.
Now… here’s why the Iceberg ecosystem is such a good case study.
Because every one of the six speakers at a recent developer event showed me a different version of the same truth:
“Shipping outcomes” is mostly about making constraints explicit, then building the system so the business can actually sell and operate it.
AI Strategy Theater: the fastest way to waste a year
AI projects don’t die because “the model wasn’t good enough.”
They die because:
the data is dirty
ownership is unclear
the workflow isn’t integrated
nobody agrees what “done” means
So, leadership panics and does the modern ritual:
They buy another tool.
Congrats. You didn’t fix the system.
You upgraded your chaos into automation theater.
The Iceberg talks were basically six different ways of saying:
“Stop doing theater. Start doing physics.”
RisingWave “Ship the upside, name the dragons.”
If you want builder energy in one slide, it’s this:
RisingWave integrated Apache DataFusion as a batch query engine for Iceberg workloads and saw 5–10× query speedups without tuning (and ~24% average speedup across 22 queries) and then immediately hit memory constraints that forced spill-to-disk + planner work.
That’s the point I wish every GTM leader understood:
You don’t get “speed.”
You get speed + the new bottleneck.
And the best teams don’t hide the bottleneck.
They productize it.
OLake “Ingestion is not a feature. It’s the foundation.”
OLake’s talk was basically a public service announcement:
Iceberg doesn’t save you if your ingestion is garbage.
At terabyte scale, ingestion must be high-throughput, lightweight, scalable, support full load + incremental + CDC, and guarantee exactly-once behavior, while avoiding the small-files / bloated-metadata death spiral.
That maps directly to the “fewer surprises” thesis:
Bad ingestion creates surprise bills, surprise latency, surprise “why is the catalog on fire?”
Good ingestion is alignment, disguised as plumbing.
Ryft “Time travel is cute until snapshot retention bankrupts you.”
Iceberg snapshots enable time travel and rollback…
…but with streaming ingestion + frequent commits + compaction, you can generate thousands of snapshots per day, and retention becomes expensive fast.
Ryft’s capability: intelligent snapshot management using time-aware retention models, high-resolution snapshots for recent history, calendar-aligned restore points for long-term recovery, leveraging Iceberg’s tagging semantics so retention becomes predictable and operationally sustainable.
Translation to GTM outcomes:
If you can’t control operational cost and recovery posture, you don’t have a product.
You have a demo.
Datastrato (Apache Gravitino) “Iceberg REST is not production-ready until identity + governance exist.”
This was the most important “grown-up” talk in the set:
Iceberg REST Catalog helps decouple compute from storage, but production teams hit the wall on security and governance, especially in multi-tenant lakehouses.
Datastrato’s capability (via Gravitino): making Iceberg REST production-ready with authentication, fine-grained access control, auditing, and secure credential vending, and doing it in a way engines like Spark/Trino/Flink can connect without custom forks.
Translation to the main script:
This is what “done” looks like.
Not “it works on my laptop.”
It works with identity, policy, and accountability.
Dremio “The fastest way to stall shipping is making everyone fight over where data lives.”
Alex Merced framed the real bottleneck perfectly:
Projects slow down when data sits in silos. Teams need quick access to current data without complex pipelines, and federation + virtualization create a unified logical layer over disparate systems.
Dremio’s capability here: query federation + data virtualization over Iceberg (and beyond), reducing the cognitive load of “where is the data / what can I access,” so more of the org can use the same data without a religious war over tools.
Translation to alignment:
If every roadmap item requires a bespoke data movement project first, you’re not “moving fast.”
You’re cosplaying as a product team while doing ETL therapy.
VeloDB (Apache Doris) “Stop rebuilding silos for AI. Use hybrid retrieval on shared data.”
Kevin Shen hit a problem almost everyone is recreating right now:
We adopted lakehouses to share data… and then for AI we revert to old behavior: copy data into a new system, worry later, and recreate silos.
VeloDB’s capability (via Apache Doris): serving diverse query patterns by combining high-performance SQL analytics + full-text search + vector search (hybrid search), plus query acceleration and materialized views on open Iceberg data to make analytics and retrieval cheaper and faster.
Translation to the “AI Strategy Theater” section:
If your RAG system needs a second copy of your truth, you’re not building intelligence.
You’re building lag, cost, and inconsistency.
So, what’s the throughline?
Each speaker attacked a different “surprise generator” that kills shipping:
Performance surprises → RisingWave (DataFusion-powered Iceberg analytics)
Ingestion/correctness surprises → OLake (Iceberg-native CDC + exactly-once + scale)
Retention/cost surprises → Ryft (time-aware snapshot management)
Security/governance surprises → Datastrato/Gravitino (identity-aware Iceberg REST)
Access/silo surprises → Dremio (federation + virtualization over open formats)
AI freshness + retrieval surprises → VeloDB/Doris (hybrid search on shared lakehouse data)
Which brings us back to the original thesis:
Most teams don’t need more motivation.
They need fewer surprises.
And fewer surprises come from systems that encode constraints, not decks that promise vibes.
Closing
If you’re a founder or product leader and your “AI strategy” currently feels like:
more tools
more meetings
more Slack threads
and the same shipping pain…
You’re not alone. You’re just in AI Strategy Theater.
I write about how to close gaps by aligning engineering reality with GTM outcomes without turning your company into a bureaucracy.
If that’s your world, subscribe so you don’t miss the next post.