Uber ran on small, empowered teams. A city ops team in São Paulo owned everything – driver recruitment, marketing, the local marketplace. A product team owned surge pricing. Another owned driver onboarding. No one at HQ could tell you what was happening on the ground, and that was the point. Travis believed the people closest to a problem would make better decisions about it than anyone sitting three levels up.
But that only works if those people can actually see what's happening. So Travis insisted that everyone write SQL. Not dashboards someone else built, where you only see what someone else decided to show you. Not requests to a centralized analytics team, where every follow-up question costs another three days. It wasn't some eccentric mandate. It was a structural consequence of how the company was organized. If you owned the problem, you had to understand your own numbers, and you had to understand them fast enough to act on them. That meant you queried the warehouse yourself.
And Travis didn't exempt himself. I remember one New Year's Eve. Always chaos at Uber, because we'd typically double the highest traffic we'd ever seen. Travis was sitting with analysts, debugging marketplace issues in Query Builder, writing SQL. Not delegating. Not waiting for a morning summary. On a night where the whole marketplace was the problem, the CEO was the person closest to it, so he was in the data, in real time.
The instinct behind this was right, and I think it's worth taking seriously even now, a decade later.
The cost of being one step removed
The traditional model of how executives consume data (delegate the analysis, wait for the filtered summary) insulates you from how the business actually works. You only see what someone else thought you should see, shaped by their interpretation of your question, their divergent incentives, and their own mistakes and shortcomings.
And once you're one step removed, the second-order effects kick in. You stop following threads. The follow-up question costs another three days, so you don't ask it. You stop pattern-matching across the business because you're only ever looking at the slice someone packaged for you. Over time, you stop thinking in the data at all. You think in summaries of the data.
This is a real loss, and we don't think most leaders fully appreciate how much it costs them. Running a complex organization means holding a mental model of how every level functions: how the pieces connect, where the pressure is, what's changing. You can't build that model from summaries. The best operators we've worked with all share one trait: they have a tactile, hands-on relationship with their numbers. They can feel when something is off because they've spent enough time in the raw stuff to have a baseline.
Why the Uber version broke
Of course, the everyone-writes-SQL approach had its own pathology, and we lived that too.
The first problem was conflicting definitions. Uber had many definitions of "supply hours," one of the most important metrics in the entire business. Different teams calculated it differently, and most of them didn't know the others existed. Direct access without shared definitions meant everyone was asking their own questions and getting different answers, then making decisions on those different answers, then arguing in meetings about whose number was right.
The second was that SQL is hard to get right, even for experts. A subtle join condition, a missing filter, a misunderstanding of how nulls propagate. These are mistakes that experienced analysts make routinely, and the result is a number that looks plausible but is wrong. At Uber's scale, with thousands of people writing queries, the error rate wasn't theoretical.
On top of all this, the data itself was a moving target. Product teams shipped so fast that they had no visibility into, and frankly no incentive to care about, how their service's data got used downstream. A schema change or a new event format would break someone else's analysis without anyone realizing it until the numbers stopped making sense. The company and the market were changing constantly, and the data changed with them.
To be clear: the Uber model worked. It was a huge part of why the company scaled as fast as it did: thousands of people making fast, locally-informed decisions because they could see their own numbers. But it came with real costs, and most companies looking at those costs choose the opposite extreme: lock everything down, centralize analysis, and accept being one step removed. Neither end of that spectrum is where you want to be.
What changed
The reason this is worth revisiting now is that the tradeoff has shifted.
The thing that made the everyone-writes-SQL model strain at scale was the missing context layer: no shared definitions, no shared understanding of what the data meant. The industry's current best answer to this is hand-crafted semantic layers, gold and silver tables, elaborate dbt projects. Months of upfront work by the data team to build a curated, governed view of the business before anyone can use it. In practice, these are boil-the-ocean projects. They rarely get finished, and by the time they do, the business has moved on.
If your organization has undertaken one of these projects, ask yourself two questions. How long did it take to get to a gold layer with everything documented? And do you believe that layer is up to date right now?
The honest answer, almost always, is that it took longer than expected and it's already stale. That's not a failure of execution. It's a failure of the model. If you have to build the layer before anyone benefits from it, and the business keeps moving while you build, you are always chasing. The pipeline is being built, the analysis is being handed over, the gold tables are being refreshed, and meanwhile the people who need answers are still waiting.
This is where we think the game has changed. Instead of a hand-built semantic layer that someone has to maintain, you can have one that builds, organizes, and maintains itself. Delphina's knowledge agent can crawl the warehouse, extract metric definitions from existing dashboards and docs, surface conflicting definitions so the data team can consolidate them, and learn the unwritten rules of how a company measures itself: the Slack thread where someone explained why we exclude cancelled trips, the analyst who knows that "active users" means something different in APAC. When the agent encounters data quality issues (a broken schema, a stale table, an ambiguous join) it can navigate around them or flag them for the data team to fix. The context layer stays current because it's continuously learning, not waiting for someone to update a dbt model.
The data team's role shifts dramatically. Instead of hand-building and maintaining the layer, they oversee it, stepping in when the agent can't find an answer on its own, and resolving conflicts when different sources disagree. Everyone else queries through it in plain English.
You get Travis's instinct – direct hands-on access to the numbers, no waiting, no filtered summaries – without the chaos of seven definitions of the same metric.
The CEOs are the tell
What we find most interesting, watching this play out at companies using Delphina, is how often the CEO turns out to be one of the most enthusiastic users. Not always the heaviest user, but consistently the most thrilled to be hands-on again.
We don't think this is because CEOs are uniquely curious, though some are. We think it's because they're the people who feel the cost of being one step removed most acutely. They're trying to make decisions across the whole business, every part of it, and the standard pipeline of ask, wait, receive summary is exactly wrong for that job. Given a way to just look at the thing themselves, they take it, and they're visibly delighted by it. That surprised us at first and stopped surprising us pretty quickly.
And then it spreads. If the CEO trusts the tool enough to make decisions on it, everyone else does too. The skepticism that usually surrounds new data tooling collapses pretty quickly once the person at the top is visibly relying on it.
Travis was right about what good looks like: everyone in the data, making decisions with their own eyes, as close to the ground as possible. The technology just wasn't ready to make that work without the chaos. Now it is. That's what we're building at Delphina.