The refusal arrived wrapped in a compliment to the status quo. Patrick Wendell and his colleagues at UC Berkeley had built open-source software for large-scale data work and were trying to give it away. Users were curious. The established vendors, who controlled much of the route into companies, were unmoved. They already had products, thank you. Better products, they said. Wendell remembers the researchers asking the natural question: are you sure? It is free.
The vendors were sure. That left the Berkeley group with an awkwardly productive conclusion. If nobody else intended to commercialize Apache Spark, the people who had built it would have to try. In 2013, Wendell left the PhD path he had started two years earlier and co-founded Databricks with six colleagues from the orbit of Berkeley's AMPLab.
Founding myths usually acquire thunder with age. This one keeps a pleasing trace of administrative comedy: an important company exists partly because several incumbents looked at useful free software and declined the parcel. Yet the episode also reveals Wendell's recurring concern. A technical idea is only halfway alive until ordinary teams can put it to work.
A short career history, with a very long consequence
Wendell describes his career history as simple. He studied computer science at Princeton, graduating summa cum laude. Then he went to Berkeley because a team there was doing interesting work in distributed computation: scheduling, resource management, and the question of how very large jobs could run across increasingly available computing hardware. The work had the forbidding name of infrastructure and the attractive quality of being newly possible.
At AMPLab he joined the group that would become the Databricks founding team. Spark was young. Wendell helped build its initial versions while working on how to optimize large-scale analytics workloads. He earned a master's degree, began doctoral study, and then discovered that the commercial problem had become more interesting than finishing the degree.
There is a useful distinction here. Spark did not leap fully formed from one laptop, and Databricks was not a solo act. Wendell's role was part builder, part maintainer, part organizer. He became a founding Spark committer and a member of its Project Management Committee. He maintained pieces of the core engine, served as release manager for several versions, and put a three-month release cadence in place.
A release calendar will never look as photogenic as a breakthrough. It may be more revealing. Predictability makes an open-source project legible to contributors, vendors, and the companies waiting to deploy it. The calendar says somebody has accepted responsibility for the morning after the demo.
The ten-minute promise
In Databricks' early days, Wendell says, the founders were all engineers because there was nothing else to be. They had to build the first product, decide what it meant, and persuade customers to care. Their broad promise was easy to explain. A company that once might spend weeks, months, or even a year assembling a Spark cluster should be able to enter a credit card and have an environment running in less than ten minutes.
That bet contained another unfashionable decision: concentrate on the cloud. In 2015, with Databricks still a small startup, Wendell argued that cloud services would be a major growth area over the next five years. Partners could support Spark on company-owned systems. Databricks would focus its energy where the founders believed computing was moving.
He also carried an academic instinct into the business. The shortage of data skills could not be solved by a company training a few thousand people each year. Open source could let anyone download the software, read its documentation, and experiment. Public videos, notebooks, and datasets could turn the web into a much larger classroom. Access was not merely distribution. It was education.
The founder as a permanent condition
Databricks grew far beyond the room in which everyone could simply be an engineer. Wendell now holds the title of co-founder and vice president of engineering. In a recent long-form conversation, he described supporting an AI and data-science product organization of roughly 500 people inside a company of about 10,000. The exact head counts will change. The managerial puzzle will not.
His formal work includes team leadership, product definition, and strategy. His unofficial work includes company culture, leadership hiring, and the occasional crisis. A founder, in his telling, never quite loses the original job. He compares it to parenthood after the children leave home: the daily arrangements change, but the relation does not expire.
That conviction does not lead him to prescribe every button and database. Wendell says leadership should establish a vision and a strategic frame, then leave degrees of freedom for product managers and technical leads to decide what the thing becomes. Databricks' founders remain close to product and engineering, while experienced executives run other functions. His phrase for giving those leaders room is nicely culinary: let them cook.
Nor has scale abolished the late-night note. One interviewer recalled Wendell contacting him after hours with a question about a customer use case. Wendell acknowledged that this was common behavior among the founders. It is difficult to maintain the fiction of lofty executive distance when a customer has an interesting problem.
AI meets the morning after the demo
Wendell's present portfolio includes Databricks products such as Genie, which lets people question company data in natural language, and Unity Gateway, which governs access to AI models and tracks their use. He also works across partnerships with leading model providers. The nouns have changed since Spark's earliest days. His underlying assignment has not: assemble complicated machinery into something coherent enough that customers need not understand every pipe.
He has described the central enterprise AI problem as the journey from a clever demonstration to a production application. In production, an answer must be accurate, current, safe, and affordable. Company data has to meet a model without losing its meaning or its permissions. Teams need evaluations and monitoring. Someone eventually receives the invoice.
AI cost levers Wendell described in 2026
In 2026, Wendell shared a Databricks analysis of its own coding-agent costs. The company shifted routine work toward more efficient models, routed tasks according to their needs, showed employees what they were spending, added friction for unusually heavy use, and pruned context that cost money without improving answers. Layered together, Databricks said these techniques could reduce unit costs by as much as 90 percent in some scenarios. The percentages are estimates, not a coupon. The more durable point is that intelligence requires operations.
This is where the Spark veteran becomes particularly legible. Model releases may arrive with theater, but Wendell gravitates toward the release cadence, the gateway, the training material, the cost control, and the customer interface. These are the prosaic devices by which a technology survives contact with an organization.
Research becomes code. Code acquires a rhythm. The rhythm supports a product. The product hides enough complexity for someone else to make useful work.
The good manners of infrastructure
Near the end of a recent technical interview, Wendell discussed the various systems Databricks had assembled for online and offline data, feature computation, storage, and AI applications. To an outsider, the collection could look like a jumble. His hope was that the average customer would meet only a high-level interface. Synchronizing all those systems should be Databricks' worry.
That ambition is less glamorous than promising omniscience, and considerably more considerate. Good infrastructure has manners. It does not insist that every customer admire its internal complications. It keeps time, explains its costs, permits inspection, and gets out of the way.
Wendell's career has followed that etiquette from an open-source engine to a global cloud company. The scale is different. The joke at the center remains intact. When established vendors did not want the free thing, the researchers built the missing route to the customer. Thirteen years later, much of Wendell's work still concerns missing routes: between data and models, experiments and production, technical possibility and a bill somebody can defend.
Being told no did not provide the plan. It clarified who would have to make one. Wendell and his colleagues supplied the rest: code, cadence, company, and years of stubbornly practical attention.