Databricks Built Its Business by Relentlessly Targeting the Bottleneck

In 2015, Ali Ghodsi was not trying to become Databricks’ CEO. The company’s open-source project, Apache Spark, was succeeding, but its commercial business was not: GAAP revenue was roughly $1.5 million. Ghodsi had heard that the board was interviewing outside CEO candidates and was preparing for the possibility that the founders would leave. He had applied for a faculty job at Berkeley, weighing a return to the academic career he had long wanted against a role in business that he says he never sought.

The board’s process was largely opaque to him. He was not formally interviewed as a CEO candidate, he says, and only later learned that Andreessen Horowitz and Ben Horowitz had treated his appointment as a trial. Initially, Databricks did not give him a CEO-level salary. About a year later, a larger equity package, higher pay, and longer-term strategy conversations suggested the experiment had become permanent.

Ghodsi accepted because he recognized a pattern in his own decisions. He had repeatedly passed on the familiar or immediately attractive option for the harder one: university rather than a game-programming job, school rather than a fast-growing startup, a PhD rather than an early professorship, and a Berkeley postdoc rather than remaining where he already knew how to succeed. The CEO role was the least familiar path. That made it the one worth taking.

His resulting management model begins with a constraint: a company may have many problems, but usually one is doing disproportionate damage. A CEO cannot avoid the daily flow of customer issues, hiring problems, legal disputes, board demands, and missed targets. But those demands should not crowd out the question of what is actually preventing the company from moving materially faster.

That meant working long hours, reading, seeking out experienced operators, and learning across disciplines. But Ghodsi rejects copying any one leader’s playbook. He compares his approach to Bruce Lee assembling Jeet Kune Do from different martial arts: the inputs matter only if they form a coherent system under first-principles scrutiny.

For Databricks, the initial diagnosis was direct. The technology and open-source adoption were strong; commercialization was not. Ghodsi handed engineering and product to a co-founder and spent roughly two years building the parts of the company that could turn technical credibility into an enterprise business.

A real strategic constraint, in his view, is not resolved in a week or a month. That is ordinary operational work. The meaningful commitments take one to three years, sometimes longer. The risk is not just that a company underinvests in a chosen priority; it is that leadership chooses the wrong priority and spends years directing the organization toward it.

Databricks initially wanted growth to be product-led. The company admired the AWS model: customers swipe a card, begin using the product, and salespeople are unnecessary or secondary. That preference became embedded in the company’s culture. Before Ghodsi became CEO, Databricks tested a “Zero Touch” model in which it would not speak to customers at all and would rely entirely on an automated funnel.

Revenue, which had been rising, flattened for two quarters.

At roughly $1.5 million of revenue, Ghodsi concluded that the company’s assumptions had become untenable. A single account executive with a $1 million or $2 million quota could generate as much business as Databricks had produced over several years. The company did not need a cosmetic adjustment to product-led growth. It needed to build an enterprise sales organization.

That required the founders to discard their own hiring instincts. Databricks had evaluated account executives partly through technical depth: Were they smart? Could they understand the product? Ghodsi looked at companies where enterprise sales was already working and asked whether the best sellers were unusually technical people, perhaps with PhDs. They were not. If technical sophistication created a meaningful advantage, he reasoned, more technically credentialed sellers should have appeared at the top of the field.

Instead, he found a different set of capabilities. Strong enterprise sellers were professionally aggressive—persistent enough to get into accounts that were not responding, but not simply abrasive. They could manage emotionally charged conversations, redirect a hostile interaction toward a productive subject, and command a room. At large enterprises, they also had to understand the customer’s internal “power base”: not a single buyer, but the network of executives, influencers, and functional leaders who shape a major purchase.

One early Databricks account executive secured a meeting with a customer that had been inaccessible through ordinary outreach. The executive who arranged the meeting began by demanding that the seller never return, angry that he had contacted the executive’s boss and others in the organization. The seller’s defense was simple: he had been told to get into the building, conventional approaches had failed, and he had found a route in. For Ghodsi, the lesson was that selling requires forms of persistence that can look alien to engineers and academics.

Ron Gabrisko became central to translating that insight into an operating system. Ghodsi credits Gabrisko with 99% of what happened on the sales side. He describes him as a hard-driving enterprise seller with enough engineering training to argue with Databricks’ founders in their own language.

Gabrisko had also seen a startup grow from roughly zero to $50 million of ARR, then operated at a larger scale after its acquisition. That mattered because Ghodsi distinguishes between executives who can run a machine built by somebody else and those who can build one. Gabrisko remains Databricks’ CRO, having helped create what Ghodsi describes as a revenue engine that grew from about $1 million to $7 billion in ARR.

The commercial rebuild established a broader hiring doctrine. Ghodsi tries to hire executives before the company urgently needs them, because time permits a more demanding search. His preference is to tolerate false negatives—passing on people who might have worked—rather than false positives that consume years.

A mistaken executive hire can require months to diagnose, more months of hesitation, a departure, a new search colored by the previous failure, and a ramp period for the replacement. Ghodsi says two major hiring mistakes stand out to him; in retrospect, the warning signs had been visible. In one case, he moved too quickly. His practical advice is extensive back-channel referencing, especially with former managers. Front-door references, he says, are often performative. Back-channel conversations reveal the fuller pattern: how a leader performs under pressure, what kinds of conflict they create, and whether their apparent strengths come with costs that a company can absorb.

Databricks did not approach Snowflake by trying to reproduce Snowflake’s category. Ali Ghodsi describes Snowflake as a great company with a game-changing product that disrupted hyperscaler data warehouses. At the time, Databricks had about half Snowflake’s revenue and was growing more slowly. Passing a rival with twice one’s revenue was necessarily a multi-year project.

The strategic task, as Ghodsi frames it, was to study the competitor carefully without becoming obsessed with copying it. Companies can fail by ignoring competitors; they can also fail by monitoring them so closely that every product roadmap and positioning move becomes a response. He considers the second mistake especially common.

Databricks identified three areas where it believed Snowflake was vulnerable. Ghodsi describes Snowflake’s core storage as proprietary, which he believed raised concerns about lock-in. He saw AI support as weak at the time, while Databricks could draw on roots in machine learning and AI dating to 2009. The third opening was cost. Snowflake was expensive, he acknowledges, partly because it had a product strong enough to command high margins.

The answer was not to walk into accounts and demand that customers replace Snowflake wholesale. Databricks developed a coexistence playbook. Sales teams were to find specific workloads that could benefit from machine learning, move those workloads onto Databricks, and shift data toward open formats. The pitch combined open ownership of data, AI capability, and a lower total cost of ownership.

Ghodsi says Databricks still typically wins on TCO. But its larger aim was not merely to win individual migrations. It was to establish a different category: the lakehouse.

The term itself was contentious. Seasoned employees thought it sounded funny, overly technical, and ill-suited to enterprise buyers. Strategy firms surveyed the market and came back with the same verdict, proposing the safer label “Unified Data Science Platform.” Some salespeople resisted as well. Spark was already familiar to customers, easier to sell, and more effective in advertising.

Databricks proceeded anyway. The company did not treat Lakehouse as a product-launch slogan that marketing could deploy selectively. It made the category a test of organizational consistency. An otherwise favorable press article that omitted the word “Lakehouse” was a miss. A customer win that failed to state the category was incomplete. Ads that converted better by emphasizing Spark rather than Lakehouse were, in Ghodsi’s view, promoting the wrong thing.

The category initially attracted ridicule. Critics made jokes about “data rapids,” “data rivers,” and “data huts.” Ghodsi says the mockery also gave the term attention, but it meant that internal skeptics initially appeared justified.

The response was to make the choice visible in every system that could otherwise pull the company back to its old identity: product positioning, marketing, press, customer stories, and sales compensation. Ghodsi’s rule is that leadership should not endlessly argue with sales about a behavior it has already decided is necessary. If selling the new product is strategically correct, put it in the compensation plan. Use multipliers, spiffs, and other incentives. The argument ends when the economic signal becomes unambiguous.

That sort of clarity is also why Ghodsi considers conflict aversion a serious liability in a CEO. Every function has a request, an exception, a resource claim, or a new initiative that it wants approved. A leader who will not say no can leave teams with incompatible readings of what was decided. At scale, Ghodsi says, people do not reliably infer nuance. He favors explicit boundaries: a hallway conversation is not approval; a request goes through the proper process; a strategic priority is not displaced because someone made a persuasive case in the moment.

He does not present this as an enjoyable temperament. He attributes some of his own aggression to growing up as an immigrant in Sweden and moving through unfamiliar environments. But he also treats confrontation as a discipline. The starting point is truth-seeking: not rationalizing what is broken in a strategy, an organization, or an individual. For a CEO who is conflict-averse, his advice is blunt: change that tendency or choose another role. A company cannot hold to a difficult, contested direction if its leader will not confront the resistance it produces.

By 2018 and 2019, Databricks had several hundred million dollars of ARR. It was successful by ordinary measures, but Ghodsi was dissatisfied with a company that was still, in his account, largely selling Spark. In conversations with public-market investors, he would describe a much bigger company with a diversified product portfolio, then recognize afterward that Databricks had not yet become that company.

He did not want Databricks to remain a one-product business, however good the first product might be. The comparison he draws is between specialized companies and companies such as Amazon, Google, and Microsoft, which cannot be reduced to a single offering. Building the latter kind of company requires bets that can slow the current business, provoke internal opposition, and remain unrecognized for years.

Ali Ghodsi still codes, having programmed since childhood, and began committing code to production more directly in November of the prior year because he wanted to understand why apparently simple work took so long to reach customers.

He built a connector in two days. Databricks teams, he says, had been taking about three quarters of work by one person to build similar connectors. Their initial response was that his work was only a proof of concept: not secure, not thoroughly tested, and not production-ready.

The question was not whether writing the core code had become faster. It was why everything surrounding the code consumed so much time.

The team’s first proposed improvement was modest. With better use of AI, it said, the work could be reduced from three quarters to seven and a half months for one person. Ghodsi challenged that result. After a deeper redesign, the team reported it could deliver seven connectors in one quarter.

The change was organizational. The old process spent a quarter gathering customer feedback and producing a detailed PRD. It required cumbersome setup work with systems such as Salesforce, Workday, and NetSuite—work Databricks’ engineers did not enjoy and outside companies might not help them perform. Testing took another quarter at the end of the process.

The redesigned workflow gathered requirements in roughly a week and captured them in a lighter-weight MD file, accepting that details could be corrected later. It moved testing forward into an end-to-end process supported by AI. It used consultants for specialized setup work. And it staffed multiple connectors in parallel rather than structuring the work around one person completing one connector.

The models improved, Ghodsi says, but better models were not the full explanation. The productivity gain came from redesigning requirements, handoffs, systems access, testing, and staffing around what AI made possible.

That experience informs his expectation that absorbing AI will take humanity at least a decade. Even Databricks—a technology company full of people who wanted to use AI—had to change the process around the model before it could realize the apparent speed of the technology.

Ghodsi also argues that current AI already meets his practical definition of AGI: systems that are smarter than most people around a user most of the time. That is a claim about the models’ general capability, rather than a claim that enterprises have already reorganized around them. In his account, companies are still using AI primarily as chatbots and coding agents.

The missing layer is enterprise context. Ghodsi says decisions, meetings, emails, and other institutional knowledge need to be captured and supplied to AI as what Databricks calls an ontology. Its Genie product is intended to do that. He says Databricks has built an internal ontology that allows Genie to answer many questions arising in meetings and automate growing numbers of tasks, while customers using the same product have not necessarily built comparable context.

AI may substantially change how organizations gather information, distribute context, and automate work. Ghodsi is less convinced that it settles the question of how humans should be managed. A manager with 25 direct reports still has to deal with career questions, unclear goals, dissatisfaction, alignment, and decision tie-breaking. Asking that manager to be a player-coach who also spends most of the day coding may simply produce neglected employees and organizational confusion.

Databricks encountered a version of Dunbar’s number around 200 to 250 employees, Ali Ghodsi says, near the period of his CEO transition. Before that, the CEO could operate as the center of a star: everyone knew one another, and leadership could directly understand almost everything happening in the company.

At greater scale, managers of managers cease to be nominal. The CEO can no longer reach down, tap shoulders, or know every employee’s work firsthand. That requires processes, KPIs, reviews, and intermediate leadership that allow the company to scale indirectly while giving the CEO evidence that functions, regions, and products are moving in the intended direction.

Ghodsi distinguishes the formal org chart from the way information is collected, disseminated, and used to make decisions. In the past, the two were effectively the same: knowledge traveled up and down a reporting tree. AI and richer enterprise context could alter that arrangement substantially, he says, even if they do not eliminate the value of a human hierarchy.

Databricks’ own cadence still relies on direct interaction. Its executive staff meets on Mondays for an hour to an hour and a half to review the KPIs of the year’s top goals. The company had two goals in the current year; Ghodsi says he had wanted one. The staff also meets for 30 minutes on Wednesday and Friday mornings. Those shorter sessions can address an urgent problem, go around the group for updates, or simply give people time to talk.

Ghodsi rejects the idea that a Google Doc can substitute for those meetings. The point is not only information transfer. An executive team needs to trust one another and identify first with the company-wide group rather than solely with the functions beneath them. Without that cohesion, sales, legal, marketing, and other departments revert to their own immediate needs and build walls between one another.

Quarterly business reviews provide the more formal scaling mechanism. They run for two or three days and cover product and go-to-market operations across regions, departments, and portfolios. They are where the company detects a failing product team, a region that has stopped selling, or an ineffective leadership problem, then defines action plans. Ghodsi also says Databricks holds at least one offsite each quarter, often focused on a particular department or major problem.

He treats uninterrupted back-to-back meetings as a failure of CEO time allocation. Such days may be necessary, but they are largely spent resolving immediate decisions, breaking ties, and handling what arrives. He tries to leave open blocks in his schedule and uses mornings and weekends to work on the issue he believes only the CEO can unblock. Product work takes much of the remainder; Databricks now has 3,500 engineers and a large enough portfolio that he tries to maintain technical depth across it.

Ghodsi says Databricks will go public, but he does not see an immediate need to do so. Ali Ghodsi believes the company would be worth more in public markets at present, citing a recent fundraise in which it raised $5 billion while receiving roughly $20 billion of interest. But valuation is not the metric he is optimizing for.

Databricks already organizes recurring employee liquidity through private tenders, a process Ghodsi describes as operating a private-market version of Nasdaq. It covers employees and former employees across nearly 100 countries and requires the company to account for differing tax rules. At some point, he says, it will make sense to become public rather than keep facilitating that marketplace itself.

For now, he sees private status as better suited to a period of AI-driven transition. Databricks is free-cash-flow break-even, he says, and therefore does not have the immediate capital needs he attributes to Anthropic and OpenAI. He would rather avoid public markets while investors are rapidly changing their views about the value of software, AI, and semiconductor companies. The company can wait, in his view, until conditions are more predictable.