In Larry's Kingdom (Part 1)

(Larry Ellison, That Is)

(This is Part One of a two-part series. Part Two will come out next week, rather than my usual two-week interval.)

In the 1990s I worked for Larry.

I say that instead of “I worked at Oracle” (although that was true, too) because I thought of it like enlisting in the king’s army: my job was to make Larry Ellison richer every day. I had a clear purpose, it was fun, and best of all, it was lucrative.

Does that mercenary attitude bother you? Do you want a corporation to have a Higher Purpose, to serve all its “stakeholders,” and all that? This may not be the post for you, then. Wait a couple weeks and I’ll have something else.

The Beginning

If you’ve read The Big Bucks (not that you necessarily would have), you know that I was at 3Com in the late 80s. After my sabbatical in fall 1989, I started looking seriously for another job, and eventually settled for transferring within 3Com. My new job was in network management, which turned out to be a great career move. That became a very hot area in the 90s as networking exploded.

I had friends at Oracle, and in fact I’d gone on a ski trip with them in the 80s. The company always seemed boring to me, since it was “database” and I’d gone to some pains to get out of that area and into networking. However, Smokey Wallace (these photos are from long before the Oracle years):

(RIP, here’s his memorial), someone I knew from Xerox, was the VP of Oracle’s new Network Products Division, and the Old Boy Network kicked in for me once again. It probably didn’t hurt that my friend from Xerox, Derry Kabcenell, was also a VP there.

Oracle? Are you NUTS?

This is a direct quote from Alan Kessler

who was a major executive at 3Com, and whom I’d actually recruited from Analytica. He went on to run Palm and take on other major responsibilities at 3Com.

Oracle had a major stock crash in 1990. Here’s the New York Times article:

In the three weeks before the conference, ''we had seen and were able to track down fragments of negatives in the Oracle story,'' Mr. Readerman said. These included problems with accounts receivable; reports of sales representatives leaving the company; problems with customer service and support, and problems with the company's own internal computer system. Now, he said, analysts must ask ''are these random and fragmentary items constrained to this one quarter or are they symbolic of a longer-term problem?

Rick Sherlund, an analyst with Goldman, Sachs, said he thinks Oracle faces longer-term problems and the disappointing earnings were an indicator of that. Oracle ''management is stretching harder and harder to make their growth objectives,'' he said. The disallowal of some sales by auditors ''tells you that the growth is not sustainable; that the business is just not there,'' he said.

ORCL stock had reached a low of $4 after this blowup. You can see what Alan was reacting to. It’s easy to feel smug now, with hindsight, and ask: “Hey, which stock would you rather have held in the 90s: ORCL or COMS?” (“COMS” was the ticker symbol for 3Com) At the time, though, one could easily think as Alan did, “They’re corrupt as hell, Larry is a rapacious bastard, their software doesn’t work, and they’re going down the tubes.”

If this were a standard business article, I’d drag out the old trope that the Chinese character for “crisis” is composed of two characters, “danger” and “opportunity.” President Kennedy said that; Condoleeza Rice said it, Al Gore said it. Unfortunately, it’s not true, according to Wikipedia.

However, crisis can indeed mean opportunity in the stock market: if the market thinks a company is finished and you don’t, you have the opportunity to put skin in the game and buy it (or go to work for it). You might lose that skin, of course. It’s a game, after all.

Before moving on, it’s worth thinking about that decision a little more. How do you know when the conventional wisdom is wrong and you’re right? You might end up like Principal Skinner on the Simpsons

and you’re the one who’s out of touch.

There is no way to tell. On other things, I’ve thought I was right but turned out wrong more times than I can count. This time I got it right. I knew the database market, and I knew that, although “relational databases” had been a pipe dream when I started my career, the concept had taken over the academic literature because it was powerful. Oracle was actually doing it; not perfectly, but the customers were generally satisfied. “Relational” in databases had gone from “Sounds great, but just not practical” to “Of course our database is relational; what else would it be?” Now, of course, there are “noSQL” databases, but this was 30 years ago.

There are many, many people who only listen to conventional wisdom. That’s how you climb the corporate ladder, generally speaking: by agreeing with the consensus and going along with the crowd. It’s a perfectly viable career strategy; it’s just not me. So I didn’t care that this big executive thought I was nuts. If you look at his biography on LinkedIn, he’s now been on a whole bunch of Boards of Directors. It’s worth calling out this career advice in a bullet point:

• There is very little penalty for being wrong.

Network Products

Smokey thought he had sold the company on the idea that Oracle could sell networking software on its own, not tied to the database. With hindsight, I think Larry just humored him and secretly thought, “Fine, fine, whatever. Just be sure you deliver SQL*Net.” SQL*Net was an Oracle product that was technically “optional,” except that everyone bought it! You couldn’t really do much with a database if you couldn’t access it over your network. SQL*Net was a cash cow.

Despite having a profitable business already, NPD (Network Products Division) reminded me of Xerox a lot. The people were sharp: a lot of MIT graduates, people who could talk about subjects other than computers and science fiction, and a few who followed the Internet Engineering Task Force closely. One, Jack Haverty, was an Internet pioneer. Another, Rich Johnsson, I knew from Xerox. Many of them had been with Oracle for several years; enough to have enjoyed the free-spending habits of a successful company. I had the Xerox connection going for me! I fit right in. And I had a private office.

How’s Your Village’s Baron?

Oracle also had a terrible reputation in Silicon Valley as a place to work. “They hound you day and night, seven days a week; they fire you on a whim, it’s a sweatshop, etc. etc.” was what you heard

.

If Larry Ellison was indeed the King, he was more like a king in medieval France than Louis XIV. If you were a peasant in the Middle Ages, there might be a king in Paris, but most of your life was influenced by your nobleman. You could have a good baron or a bad baron, and the people ten kilometers away might have a completely different life

.

That was how Oracle was. Some groups probably were sweatshops, and some were not. It just depended on who your VP was. Larry didn’t try to enforce a uniform culture across the company. Our division was very, very nice. This was an era when Marketing people were expected to wear a tie to work, and they had a tradition called “dress down Friday” where they could be tie-less. Engineers, of course, had to be persuaded to even wear long pants and shoes, and ties were just a bad joke from a bygone era.

So one Friday we had “Engineer dress-down Friday” where we all did wear suits and ties. There must be someone who has a picture of that; if you do, please send it to me and I’ll revise this to include it.

What Kind of “Networking"?

I joined in March 1991. Nowadays people don’t even think about their network protocol, and it’s just “the Internet,” but back then, vendors still tried to lock in their customers with proprietary protocols. Digital Equipment Corp. had DECNet, IBM had SNA, Novell had its own protocols (which were really derived from Xerox’s XNS), Apple had AppleTalk. And there was OSI, the international standard, to which some people still paid lip service, but hardly anyone actually used. Oracle supplied software for most of those, since they didn’t want to preclude anyone from buying the database.

TCP, the protocol developed for the Internet, was clearly gaining momentum, but I distinctly remember Smokey insisting “Everything’s not going to be TCP. Those other protocols are not going away!” (Within a few years, everything was TCP and those other protocols did go away.) So a “multi-protocol interchange” (MPI) series of products was planned and one was actually shipped, where the database could be using one protocol and your client another. I have a friend who installed the MPI somewhere and he said it worked quite well.

Anyhow, the Internet was hot! Customers were frantically learning how to create those magic text files that made the net work, and naturally Oracle had the solution to every problem: use a database! One of my first projects was using the Oracle database to configure your DNS files.

Bob Miner, RIP

You probably don’t think of Oracle as a sentimental place, but everyone loved Bob Miner, one of the co-founders of the company (second from the right):

I didn’t know him nearly as well as hundreds of other people, but the phrases “down to earth” and “straightforward” would probably appear in everyone’s description. Bob was the least pretentious, most honest executive I’ve ever met in my career. I rode in the elevator with him once, and I thought, “This is the guy who’s here to fix the air-conditioning.”

Larry Ellison told a story about Bob at his memorial that would make anyone who knew Bob laugh: every Friday he used to go to the bank, hand the teller his check along with a deposit slip, and get $200 back for spending money.

When Oracle IPO’ed, Bob received a much larger check, in the millions. He went to the bank as usual, stood in line for the teller, and handed over his check, requesting his usual $200 in cash.

The teller called the bank manager, who explained to Bob that for a check that large, he didn’t need to wait in the teller line.

My encounter with Bob was so short that it reads almost like a haiku. Smokey, our VP, had left Oracle, and his deputy had taken over for him. Mr. Deputy was the sort of person who had to prove that he was smarter and cooler than everyone else. When we had an Oracle offsite at the Fox Theater in San Carlos, he thought it would be just the coolest thing to get there early and have a tailgate party, so everyone could see us being clever.

After he’d been in charge for a couple months, Bob called me up to his office on the 14th floor. He asked me straight away what I thought of Mr. Deputy. Since he didn’t seem like he wanted you to mince words, I just said, “I think he’s in over his head.”

Most executives would harumph at that and say something non-committal. Your average Power Guy would ask you to say more, draw you out and give nothing back, and keep his cards close to the vest at all times.

Not Bob. He just said, “I think so, too.”

SNMP and Management

SNMP is an Internet standard, meaning Simple Network Management Protocol. I first got into it at 3Com, in my last year and a half there. Just a few words about how it works, which I hope you’ll find interesting even if you’re not a network person:

The reason they called it “Simple” is because it was designed to use as little as possible of the network infrastructure. That’s because if the network is having problems, you won’t be able to use much of it.

On a TCP/IP network (the protocol that runs the Internet), you can talk to another node either with a connection or via datagram. You can think of a connection as like calling someone on the phone. They pick up the phone and now you’re connected. On the phone network, you actually have hardware dedicated to you and your connection, while on the Internet it’s all software. But in either case, some effort goes into setting up your connection.

With a datagram, you just send one packet to your destination, and it either gets there, or it doesn’t. The other side can acknowledge it (abbreviated ACK) or not; that’s up to you and it. With a connection, many packets can flow and ACK’ing always happens (how that’s done is the art of protocol design), and if the datagrams arrive out of order, they’re put in order for you.

SNMP was designed to use only datagrams. The management station asks the other node some questions, and it responds with the answers. If the other node doesn’t respond, the manager tries again, usually three to five times before giving up.

The only other thing I need to cover here is “What questions can you ask, and what do the answers mean?” This is a whole subject area of its own. The term “Management Information Base” means “the set of variables you can ask about.” The MIB is the whole ball game. Some common MIB variables that almost every node can answer are “how long have you been up?” and “how many bytes in and out have you handled?”

There are specific MIBs for special types of nodes, e.g. a router supports the Router MIB. Once SNMP became popular, vendors started creating management stations that used it. HP made one of the most popular, called “OpenView.” The pressure to define a MIB for everything on the Internet became irresistible, and one of those things could be a database server. So a “database MIB” working group was created in the Internet Engineering Task Force (IETF).

I saw my opportunity: Oracle wanted a database MIB that they could support, I had some expertise in MIBs, and Oracle was the largest database vendor (except for IBM). I got three other people to come with me to the first meeting. Given that Oracle dominated the database market, and we dominated the meeting, I was chosen as the chairman. It was ideal! Oracle wanted it to be done, but they didn’t much care what was in it, as long as they could support the end product. This was about October, 1993.

It turned out that that was the case with all the other vendors, too, which was why I was able to be so successful with it! All the vendors wanted to say they were part of the effort, and they supported it, but it wasn’t key to their business and wasn’t a life-or-death matter for them.

So does that mean that Oracle got to “own” the MIB and make sure it advantaged Oracle? No, that’s not how it works. “Rough consensus and running code” is the watchword of the IETF, and (almost) everyone has to agree. All the major database vendors joined eventually, and if I wasn’t fair to them, I’d be gone as chairman.

The IETF also assigned a senior person to be our advisor, the acerbic Marshall Rose, one of the “gang of four” SNMP gurus. Whenever there was a question of what a MIB variable could be, or how the standardization process worked, Marshall had the final word. My favorite quote of his was “What part of ‘no’ don’t you understand? The ‘n’ or the ‘o’?” I got along tolerably well with Marshall, but I knew not to push it.

The Working Group carried on its business mainly over email. There were some in-person meetings, of course, and those were very important. But for my own emails, I had an employee, Jay Smith look them over. My writing style can be a little brusque at times, which might actually be what you like about this article (if in fact you do). But in any large group, it can rub some people the wrong way. Jay helped me avoid that. We crafted the emails very carefully and smoothed down all the rough edges.

With any group effort, the big challenge is to avoid just saying Yes to everyone’s pet ideas. This is why the international standards efforts (CCITT, OSI, etc.) failed — the path of least resistance is to just let everyone add whatever they feel strongly about. You avoid hurting any feelings, but you end up with a bloated mess that no one wants to implement.

But IETF has always avoided that. It was not really a democracy, in that there was never a vote taken. “Rough consensus and running code” was the requirement. Someone with implicit authority, like Marshall, would be the judge of whether “rough consensus” had actually been reached, and if you didn’t agree with it, you’d have to convince him you were right.

I had one big thing working for me: most of the attendees were there at the sufferance of their managements. They wanted to succeed, and not spend year after year in IETF meetings. Like Oracle, they didn’t really care that much what the committee produced, as long as they could say in public they supported it.

I used that. Whenever a major new feature was proposed, I could always say “we’ll get to that in the second release. It’s important now to get a standard out there, and build on it later.” Since everyone wanted to accomplish something, this worked.

We got RFC 1697 published in about nine months. There was never a second release, and the status of the RFC never advanced to “Standard.” I got to be quoted in the press, which I enjoyed enormously, and the reason I was allowed to was that I was not speaking on behalf of Oracle; I was speaking on behalf of the IETF.

(End of Part One. Part Two will be next week.)