Amandeep Khurana joined a sales call expecting questions. A prospective Cloudera customer was comparing vendors, and he was one of the company’s HBase specialists. This was supposed to be a serious technical discussion. He introduced himself and asked what the team wanted to know.
Nothing, apparently. They were ready to proceed. They had been learning HBase from his book. If he was involved, they wanted to work with Cloudera. An author’s dream: the reader had finished the homework and brought a purchasing department.
Khurana was flattered. Years later, he came to see something more useful in the encounter. The book had already supplied evidence of how he thought and what he knew. Before the commercial conversation began, the customer had formed an opinion about the person who might help them. The sale had acquired a history before it acquired a meeting.
That small episode offers a way into a career that can otherwise look like a procession of technology names: AWS, Cloudera, Okera, AWS again, Anthropic. The recurring interest is the encounter between a complicated system and the people expected to trust it with their work.
The industrialist who chose customers
Born in New Delhi, Khurana came to the United States for graduate school. The first months were financially difficult. He worked part-time as a graduate researcher at Cisco, and earned a master’s degree in computer science at the University of California, Santa Cruz. Before that, he had studied engineering at Thapar Institute of Engineering and Technology.
As a child, he wanted to be an industrialist, before he had much idea what the title meant. Graduate school offered another possible identity: researcher. He decided he wanted to build things rather than continue toward a doctorate. AWS became an early professional home, on its Elastic MapReduce engineering team.
He later described a preference that complicates the conventional engineer’s biography. Solving customers’ problems interested him more than engineering for its own sake. At Cloudera, his field work put him near the people trying to make Hadoop useful. A distributed system might be elegant; the customer still needed it to run.
There was a book along the way. With Nicholas Dimiduk, he co-authored HBase in Action, published by Manning in November 2012. Its subject was practical: designing, building and running applications on HBase. That verb sequence could serve as an early outline of his working life. Understanding the system was only the beginning of the assignment.
Two founders, then a bank
In 2016, Khurana and Nong Li founded the company first known as Cerebro Data and later as Okera. Khurana was its original CEO; Li was the founding CTO. Their backgrounds met at a particular enterprise difficulty: data was spreading across different systems, while people needed a dependable way to access and govern it.
The founding story had the less photogenic ingredients of a startup. Both founders gave up salaries and put savings at risk. Early attempts to raise money failed; one obstacle was that they were still working elsewhere. Eventually, they quit their jobs and committed to the company. The business plan had acquired a rather persuasive deadline: their own bank balances.
Capital One became an early design partner and customer. The relationship put a very small company against a very concrete test: could its software fit the bank’s security requirements? By the public launch in May 2018, Capital One was a named enterprise customer and its venture arm was an investor.
The launch brought $12 million in Series A financing, led by Bessemer Venture Partners, with Felicis Ventures and Capital One Growth Ventures participating. Total funding at that point was $14.6 million. The Active Data Access Platform was generally available. Cerebro Data had become Okera, with a product and a customer willing to be named beside it.
Khurana’s position at launch was that companies should be able to innovate while maintaining proper governance. The practical ambition was straightforward: people using data should not have to choose between getting work done and respecting the rules governing that data. Anyone who has waited for permission to open a file can appreciate the attraction.
The permission problem gets bigger
By 2019, he was explaining why ordinary access controls became cumbersome as the number of datasets grew. Mapping users to named datasets could produce an administrative tangle. Add more data and more complicated policies, and the rules became increasingly difficult to maintain.
Okera’s approach allowed controls to follow properties of the data. A policy concerning Social Security numbers, for example, could apply across a data lake, rather than requiring someone to recreate it for every dataset. Tags on tables and columns gave administrators a way to express those rules more consistently.
This is a fairly dry description of a problem with human consequences. The analyst needs access. The administrator needs a policy that can be maintained. The person responsible for security needs confidence that a permission still means what it meant yesterday. All three have jobs to do, preferably without convening a committee every morning.
Conceptual illustration of the access problem Okera addressed.
On May 3, 2023, Databricks announced its acquisition of Okera. Its plans included integrating Okera’s capabilities into Unity Catalog. Nong Li was CEO at the time. For Khurana’s biography, the distinction matters: he co-founded the business and led it originally; the acquisition came in a later chapter of the company’s leadership.
A smaller title, a larger education
Khurana’s own next chapters included product work at AWS. He was a founding product manager for Kiro and worked on agent optimization capabilities in Amazon Bedrock AgentCore. By 2026, he was at Anthropic as a Member of Technical Staff, leading forward deployed engineering and working with enterprise customers bringing Claude into production.
The move toward hands-on work had a personal cost. Returning from people leadership to an individual contributor role meant giving up status and, in the short term, compensation. He wanted to learn generative AI. He has described the move as a blow to his pride that changed his career’s direction and made work enjoyable again.
His account of that choice includes an earlier regret. For years, he had judged jobs largely by what they paid. Even at AWS, surrounded by engineers building large distributed services, he felt he had paid too little attention to what he could learn. A mentor gave him a compact test for future decisions.
“In every job, be learning or earning. Ideally both. Leave if it’s neither.”
Advice from a mentor, recalled by Khurana
He is careful about the arithmetic of freedom. In another reflection, he describes declining a startup executive role because its cash compensation could not meet his commitments. A house, renovations, children and life in the Bay Area had each brought reasonable expenses. Together, those expenses made a different career harder to choose.
There is something disarming about a founder explaining how ordinary obligations can hem him in. The entrepreneurial story usually enjoys the moment someone jumps. Khurana also writes about the times he could not. The mortgage, predictably, had neglected to read the motivational literature.
The awkward dinner question
His interest in learning extends to asking people for assessments he may dislike. During a dinner with a former colleague, he asked how that colleague had seen him when they worked together. The answer was uncomfortable: he had seemed preoccupied with finding a shortcut, optimizing so tightly for his preferences that he might miss nearby opportunities.
Someone else had independently noticed a similar pattern. Two observations made the criticism harder to dismiss. Khurana writes that he would never have learned about that blind spot without asking. He had begun deliberately seeking feedback while training as a coach and leader at Landmark Education.
His response is practical. Ask in several ways. Invite advice, ask what could have gone better, give someone room to say what they noticed. Listening does not create an obligation to agree. It does create a chance to understand how other people experience working with you. For a founder, that is information with unusually direct consequences.
Back at the keyboard
The contemporary version of this habit appears in his software workflow. After experimenting with AI coding tools, he began writing detailed specifications before asking for implementation. User stories, data models and edge cases came first, followed by a design and a task breakdown.
He describes accumulating written instructions and decision logs after specific mistakes: a premature commit, a design choice unnecessarily reopened, an important constraint forgotten. The resulting process gives the next working session something firmer than a recollection. It is the sort of procedural enthusiasm that tends to arrive after one has repaired the same mistake twice.
These days, he also advises founders on product and early sales, and writes lessons he hopes to pass to his children through Paid Tuition. The title acknowledges that experience sends invoices. He has enough material to recognize several of the charges.
At Anthropic, the setting has changed from Hadoop deployments and data access to enterprise AI. Yet the customer still has to make a consequential bet on software, and someone still has to help it work. Khurana’s book once answered a customer’s questions before he joined the call. His career since then has given him plenty of reasons to stay on the line.