Mike Olson has a different idea of good timing

The clock Mike Olson built for a café in West Berkeley required him to make his own display components. The digits needed to be readable across the room. Buying them was expensive. Making them meant learning how. For someone who had already been chief executive of two software companies, this was a pleasingly specific problem: could the people having dinner see what time it was?

There was a complication. Olson’s clock uses metric time. A perfectly ordinary day becomes a different arrangement of numbers. In March 2026, he published a detailed account of the UQBAR Café project, including the version he had replaced after living with its shortcomings. The clock had given its maker some notes.

That willingness to be taught by the thing in front of him runs through Olson’s working life. He helped commercialize database software, led Sleepycat Software, and co-founded Cloudera. He also took years away from college, learned to sell, and eventually made room for another CEO. His career has had several clocks running at once.

The summer that refused to end

Olson grew up in Kansas City, Missouri, where his stepfather brought home an Apple II. Playing games led to writing them. Programming offered a rewarding discovery: a machine could be made to do something it had not done yesterday. Berkeley offered a place to pursue that discovery seriously.

He arrived at the university in 1979. A campus programming job suited him; coursework proved less accommodating. Being comfortable with computers did not automatically make him good at the habits college required. In 1982, he left for a summer in Europe. The proposed improvement in his study habits would have to wait.

The trip expanded into roughly four years abroad. In Amsterdam, he worked as a line cook in a Mexican restaurant. It is a useful detail because it resists the usual résumé polish. A kitchen job does not need to become a secret masterclass in entrepreneurship to deserve a place in a life.

He returned to Berkeley, and eventually to the degree. His bachelor’s in computer science arrived in 1991, followed by a master’s in electrical engineering and computer sciences in 1992. The elapsed time would make a university administrator reach for a form. It also left Olson with experience beyond the laboratory.

The programmer joins the sales call

Berkeley’s database work gave him a lasting technical home. He contributed to Postgres and Berkeley DB. On his GitHub profile, he identifies his work with admirable specificity: storage and access methods in University POSTGRES, and the B-tree code in Berkeley DB. Underneath the later executive titles, there are particular pieces of software.

He left doctoral studies in 1993 to join Illustra, which brought Postgres technology into a commercial business. His career moved through technical and business positions at Illustra, Informix and other database companies. He became increasingly involved in the conversation between what software could do and what a customer needed done.

That conversation matters. An engineer can describe a feature accurately while leaving a buyer entirely unmoved. A customer can describe a difficulty without knowing its technical name. Someone has to stay interested long enough to connect the two. Olson’s move into sales and marketing made that translation part of his work.

In 1998, he joined Sleepycat Software as vice president of sales and marketing. The company made Berkeley DB, an embedded database engine. He became CEO in 2000. Oracle acquired Sleepycat in 2006, and Olson spent the next two years there as vice president of embedded technologies. By then, he understood both software that other people could build on and the business arrangements that kept its makers employed.

Learning to see a different problem

Olson did not immediately embrace the ideas that would lead him toward Hadoop. When Google published its research in 2004, he initially dismissed it. It lacked familiar database features, including transactions and a query language. Judged against the systems he knew, it looked incomplete.

By 2008, he saw the distinction more clearly. These systems addressed a different problem: processing data at a scale that changed the engineering choices. His earlier judgment had used the wrong set of expectations. Experience had helped him recognize the technology, then briefly got in the way of understanding it.

Cloudera came together that year with four co-founders. Christophe Bisciglia brought experience from Google, Amr Awadallah from Yahoo, and Jeff Hammerbacher from Facebook. Olson brought the database industry and the experience of running a software company. The combination put people who knew the emerging tools beside someone who knew enterprise customers.

Hadoop let work be distributed across clusters of computers. Cloudera’s opportunity was to make that approach usable by organizations beyond the internet companies already wrestling with it. Software availability alone would not settle every question about installing, operating and supporting a system. There was considerable work between a promising project and something a business could depend on.

Tom White, an early employee and author of Hadoop: The Definitive Guide, remembered the attraction clearly. The founders wanted to make Hadoop easier to use and run while retaining a commitment to open source. His account of the early work includes training, software packages, data-ingestion tools and a web interface. These are the practical details that turn a technical possibility into a working day.

In later discussions of Hadoop, Olson emphasized inexpensive storage, scalability and the freedom to capture different kinds of data without predicting every future use. The appeal was partly about postponing a decision. A company could retain information and discover a useful question later, rather than needing every question settled before collecting anything.

That gave Olson plenty to explain. His public talks and writing moved through enterprise data strategy, machine learning and the changing ways organizations stored and analyzed information. The programmer had become a spokesman for a category of computing. He still had to make the case in terms a customer could recognize.

A founder changes chairs

In June 2013, Tom Reilly became Cloudera’s CEO. Olson became chief strategy officer and continued as chairman. The distinction is worth keeping straight: founding the company and running it indefinitely are separate commitments. Olson stayed in the business, working on its direction, products and engagement with customers.

His later writing gives a practical account of how such jobs evolve. A technical founder needs enough understanding to explain the product’s value, and enough business fluency to turn that value into an organization. As the team grows, the founder has to delegate. Being able to do many things personally becomes less useful than enabling specialists to do them well.

“We interview not just for skills, we interview for capacity to learn.”

Mike Olson, Stanford, 2013

Olson’s discussion of hiring at Stanford put learning near the center of the job. A changing market requires people who can get better as the company develops. That is a sensible requirement from someone whose own work had already shifted from database code to sales, management and strategy.

He applies a similarly concrete test to directors. A board should contain people who can help the leadership team think through difficult decisions. He recalls long drives home when he would call investor and fellow operator Aneel Bhusri to work through problems at Cloudera. A useful board relationship could continue well beyond the scheduled meeting.

His board essay began as an email to a climate technology CEO assembling a board after fundraising. He expanded it into a Monktoberfest talk in 2023. The advice draws on actual conversations, mistakes and relationships. It treats leadership as a craft with things to learn, rather than a quality conferred by the right chair.

The news around the corner

Olson retired from Cloudera in 2019. His later interests give that date substance beyond an executive departure. He served as an OpenCorporates trustee, supported work using data for public benefit, and became involved in the climate crisis. These were places where experience with information and institutions could find another use.

At Cityside Journalism Initiative, he is board chairman. Its newsrooms include Berkeleyside, The Oaklandside and Richmondside. Here the geography is close to home. A business career spent explaining the value of data has been followed by a commitment to reporting that helps people understand the places where they live.

In a public fundraising appeal, Olson described giving Cityside both time and financial support. His personal site also describes strategic advising and investments as a limited partner in climate-focused funds. He is selective about the work he takes on. There are founders to help, institutions to support, and projects that need no investment committee.

MultiClock is one of those projects. It displays civil and solar time, using familiar clock notation and a metric alternative. It also gives prime numbers their own little celebration. The software is public. Fellow database people, including Doug Cutting and Tom White, appear among those thanked for trying versions and offering feedback.

The café clock takes that interest into a room where people can glance up from a table. Its maker has to consider the display, the case, the wiring and what will happen when something needs replacing. Years after helping companies work with vast amounts of data, Olson is still dealing with a user’s simple question. What does this thing tell me? And can I read it from over here?