Lessons from Oracle
![]()
I recently read "SOFTWAR- An intimate portrait of Larry Ellison and Oracle". Mathew Symonds, the author brings to life the story behind Oracle and Ellison. Here are my top six takeaways from the Oracle success story.
Question the pundits: When Oracle started out it had very little competition. All the other efforts in the RDBMS space were theoritical in nature because the pundits believed that performance issues would prevent an RDBMS from ever being successful.
Start with consulting: Consulting revenues funded the development of the first release of Oracle. While still a fledging company, Oracle almost closed down because they stopped doing consulting. Moral of the story: If you are bootstrapping a product company, don't ignore the steady cash flow from consulting.
When choosing a standard-Go with the tide: One reason Ingres lost out to Oracle was that Ingres adopted QUEL, a standard superior to SQL. QUEL was better, but SQL had more industry backing.
Question success, not just failure: Oracle's initial success had a lot to do with having a hyper aggressive team of "hunting" salesmen. The kind of salesmen who would do anything to meet the numbers. They kept up Ellison's vision of doubling sales every year. Year after year. But when the product matured and when customer needs changed in favor of a more service centric sales model, the hunting approach to sales became a huge liability that almost got the company closed down. Mathew Symonds mentions huge account receivables, false promises and huge discounts as some of the perils of hyper aggressive selling. Oracle had to re-orient the sales force to regain market and customer confidence.
Never mix a staff function with a line function: Contracting, legal and sales were clubbed together at one time in Oracle. A move that allowed sales to meet the obscene goal of doubling revenue every year. A move that also lower the quality of revenues and caused Oracle to make an embarassing restatement of earnings not once but thrice. A staff function, especially a controlling one should never be made to report into a line function.
Beware of the brilliant guy who cannot perform: Hiring smart guys is fine and IQ is perhaps the single biggest pre-requisite of performance. OK. OK. That's a big statement. But, atleast in an algorithm dense product engineering world IQ rules. The problem is that are some high IQ people who simply don't perform. Because of the high IQ, they get appointed to top positions and when they mess up, they can bring down a whole company. Identifying such guys is perhaps the single biggest recrutment challenge. Symonds mentions just such a man as one of the causes for Oracle's tough times in a year ninenties.
If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Lessons from Oracle
Tell a friend

