My Memories of Yahoo!

Y!I used to work at Yahoo! for a very long two and a half years, from mid-2001 to the end of 2003. It was a strange period, with monumental shifts in the Internet. Yahoo! was a the center of it all, but the other players were rapidly rearranging themselves. Microsoft, for the longest time the bane of Yahoo! (more accurately, Microsoft’s MSN division, later Live, later Bing) was rapidly driving itself into irrelevance. On the other hand, the tiny upstart Google was starting to bite at its former master’s heels as it managed its entrance into the email market and other derivative of popular and lucrative Yahoo! products.

Things went horribly wrong at Yahoo! When I left, in 2003, the company was doing very well, but the seeds of destruction were visible everywhere. I left because I didn’t believe the company was pursuing the right strategy, and was deploying the wrong processes, and focusing on the wrong people. My bet was expensive – my stock was only half vested, and I left the other half on the table.

After I left, though, there were tons of articles about what had gone wrong at Yahoo!. All of them were written from a specific, political point of view. Essentially, the author was blaming everybody else. There was an article by Brad Garlinghouse, now gone from the Internet, about how the problem at Yahoo! was the IQ of its developers (especially compared to Google). Another article by Caterina Fake highlighted how she perceived Yahoo! fumbling the Flickr acquisition. Caterina was one of the founders of Flickr, and in her generous (to herself) memory, Flickr stood poised to become the company that Facebook became. Oh, if only Yahoo! hadn’t been so short-sighted!

I was surprised by these articles, and by comments made by other colleagues, because they seemed to focus on a single issue, as if addressing it would have completely changed the fate of the company. Instead, I felt that the reasons for the failure were as numerous as the failure colossal. It is a testament to the company’s greatness that it survived the many self-inflicted wounds and is still alive today. But let me enumerate for thee:

1. Strategy

I remember the first meeting I attended where producers (the Microsoft/Yahoo! term for product managers) discussed the upcoming threat of Google. Until then, they had talked in the same identical way about Microsoft, and Google had been until recently just the little company that provided search services, because Yahoo! didn’t really care about a geeky function like search, where it had more important things to do.

I noticed people talking about Google, but not learning much about what Google did right. Granted, in the beginning Google was a maelstrom of projects without a visible direction, but Yahoo! failed to realize what all those projects had in common: they provided functionality. Google was rapidly becoming the leading provider of applications on the Internet. Search was not good enough: mail had to be part of it, maps, chat, RSS, photos (Picasa), and so on. What Google didn’t build, it bought.

At the same time,** Yahoo! hired a Hollywood big-wig (Terry Semel) as CEO**. The man shocked everybody at HQ when he had his assistant send an email on his behalf (as you can do in Microsoft Exchange). The complaint was political: behold the man that doesn’t even use our own, first class email system! But the issue was strategic: hiring a Hollywood person was a sign that the company saw itself as a media conglomerate, not an application provider.

This is not entirely surprising: Yahoo! had been created as a portal, that is a news aggregator. You would go to Yahoo! to find other places where to do things, and Yahoo! was initially perfectly happy as a hub. Of course, in time it had added (mostly through acquisitions) functionality of all sorts. It had Maps (411.com), Mail (I think homegrown), Groups (eGroups), Instant Messaging (a huge product in the day), and so on. But its advertising model was media driven, and the functionality-based areas (properties) just couldn’t make a whole lot of money that way.

The problem with the aggregator approach is that it is pointless to be a hub in a place with no restrictions on flow. It is convenient to have an airline hub, because there are only so many planes that fly across the country, and connecting all of them in a single place is a very efficient way to offer flights from any origin to any destination. But on the Internet, you can access any site, and you’d quickly find out what source is the most reliable without the need for Yahoo! to find anything.

Yahoo! also unsurprisingly missed the boat on user-generated content. That’s a blunder that is strategy-driven: what’s the point of being a hub if all the content is generated by those that are supposed to consume it?

2. Processes

Yahoo!’s maddening ways were exacerbated by its completely broken processes. It’s not that the company was not aware that something was wrong; it knew very well. The problem was that Yahoo! didn’t know what to fix most of the time, and ended up fixing the wrong thing.

I’ll start with the most visible case, the Panama Debacle. Panama was Yahoo!’s attempt to push out a Google AdSense competitor in time for the holiday season 2006. It was ambitious, and at the same time desperately needed. Yahoo!’s paid ads were terrible, users hated them, and they provided little return on investment.

Panama was led by two senior executives. On the Engineering side, there was Farzad Nazem (commonly known as zod). On the business side, there was a Senior Vice-President of Search, Jeff Wiener. They represented the opposite ends of Yahoo! at that point: zod had been head of Engineering (and CTO) for the longest time; Wiener was one of the “Golden Boys,” the young and driven, technologically incompetent people that came with the new media mogul CEO.

Panama launched late. Too late to be relevant for the holiday season 2006, missing the mark by a mile, crushing Yahoo!’s ability to recoup the paid search market. It was a giant catastrophe.

So the board reacted, by firing two executives. You would think the responsible parties would be fired: the head of search and the head of engineering. Nothing of the sort happened: instead, the COO was fired (and I forget the other one – help me out here!).

That’s how things worked at Yahoo!. Processes were nebulous, the outcomes unpredictable, and the result eternal frustration. A few examples:

The product approval process required a series of buy-ins from unrelated panels. Each panel would spend a minimal amount of time with a new product and critique it, after which the product had to be modified to reflect the criticism. You would end up undoing something for one panel just to have to redo it for the next. While you spent hundreds of man-hours to do this, the panels would not even be required to read the meeting minutes of the panel that preceded them.

Product management decisions were handed off to producers in a way very similar to Microsoft’s approach: young MBA types declared themselves owners of the product and discouraged any communication between different generators. UI was not to talk with Engineering, Engineering not with QA (as far as that went), business people were not encourage to talk to anyone. While understandable from a flow perspective, this approach ended up being very costly, since there was never any consideration of the cost of particular features.

Fixing was rewarded more than doing it right in the first place. The man that created a bug that threatened the stability of the servers was showered with accolades if he (or she) fixed the problem before it became very visible. The woman that wrote code that never needed fixing just flew under the radar.

3. Management

Processes in general were extremely frustrating, but that was just one of the symptoms of Yahoo!’s big Achilles Heel, its management. Not the management structure, but the people managing. It’s not that they were ill-willed, it’s that they had very little instruction on how to manage, and a culture of poor management around. They didn’t know what they were doing in theory, and nothing in their surroundings showed them how to do it in practice.

I think the origin of poor management came from Yahoo!’s history. In the beginning, the Web was new and you had to do everything by trial and error. There was no way to figure out ahead of time what was going to work, because nobody knew. By the time I joined, though, Yahoo! had already survived the Internet Mass Extinction, and we had a pretty good idea of what worked and what didn’t: open source and cheap hardware were in, Oracle and Solaris were out. Microsoft was not a player anymore, and startups could capture the virtual entirety of the market in a matter of months if they played their cards right.

At Yahoo!, though,** the lesson did not sink in**. While we knew that being nimble was of paramount importance, not enough time was devoted to harmonizing the products. As a result, there were dozens of different ways each property of Yahoo! did things differently – from storing cookies to storing ZIP codes. The problem was one of resources: faced with the decision between adding features and rationalizing products, Yahoo! management routinely chose features. The end result was cruft, and the embodiment of it was the 32 character debacle.

Yahoo! user IDs had been 16 character long for the longest time. At some point, Yahoo! had a giant partnership with SBC (now part of AT&T). This partnership required SBC email addresses to function as valid Yahoo! IDs. Small problem: those email addresses could be longer than 16 characters (especially because the email domain was “sbcglobal.net,” which by itself is 13 characters long).

Now, in a decently organized company, if you change the size of a fundamental constant, worst case you change the value of that constant in a few places, recompile the code, test, and deploy. It should take a couple of weeks, including testing and deployment.

At Yahoo!, that took a year and a half. And it would have taken a lot longer if it hadn’t been for the threat of penalties from the contract with SBC.

Now, this seems to be just a geek talking. But by never rationalizing the code, the company grew increasingly unable to make rapid changes, because each change required more and more work, and brought more and more risk. It’s not just that code had to be changed, or bugs to be fixed. The problem was that if a bug was affecting users, we had to stop whatever we were doing and find the source of the bug and address it. That completely threw off our schedule.

How to deal with it? Spend time rationalizing. Make it so nobody can write a second version of anything. Make it so it’s easier to do it the right way than the cheap way. Institute code reviews where people spot problematic issues. That takes time, of course, but it’s also a way to bring new people on board, something the company never did.

4. People

The thing I most remember about Yahoo! was how wonderfully enjoyable it was on one side, and how terrifyingly frustrating on the other. It was enjoyable, because you were surrounded by interesting people, there were tons of events, and the facilities were pleasant. Really, the only thing missing was an open air swimming pool and we would have had paradise on earth.

On the other hand, the place had grown strangely. It had grown in spurts, creating classes of employees (you even got a little banner when you started, and I affixed my Class of 2001 banner to the cubicle before I knew it made me an instant low-caste). Engineering, in particular, smelled bad of social ineptitude. People would relate to each other because of how long they had been mutually acquainted, which gave people with access to early employees social clout. That went as far as random early Yahoo!s threatening to get Filo (one of the founders) involved if I didn’t do their bidding.

The way I got into Yahoo! showed me how things would go wrong. I was part of Yahoo!’s attempt to create an enterprise presence. Yahoo! realized more and more large corporations were shutting out it servers, so it decided the right thing to do was to deploy a way for enterprises to use its services inside the firewall.

Yahoo! went big. Instead of trying a foray with something that would have been plausible (for instance, creating custom web sites for enterprises, where it might have had credibility), it aimed straight at creating a software suite that would take over the Enterprise. That IT departments would be less than thrilled didn’t matter: Yahoo! was going to leverage its political clout at the executive level to sell its proposition.

The attempt failed miserably. In the end, the problems were multiple, but the root cause of all of them was a single one: Yahoos didn’t understand how enterprises work, how they buy, and in what time frames they deploy. When Yahoo realized its revenue projections could not be met, it jettisoned the whole project.

That’s the way things worked. Executives making decisions about things they didn’t understand. Managers promoted because of seniority, but completely untrained in management. Personal relationships that could get in the way of any process, no matter how crucial.

5. Jerry Syndrome

One final thought about the downfall of Yahoo!. I don’t think I have ever met anyone as down-to-earth, genuinely caring, astonishingly nice as the two Yahoo! founders. Jerry Yang and David Filo are just amazing human beings. Even as the company had 4000 employees, they would come out every December and bring you a holiday present. I still have all the ones I received, and I am genuinely happy that I met the two of them.

One anecdote stands out: I was having lunch with my colleague Toby, a recent hire and not the most socially informed person in the world. As we were about to sit down, our friend Bill waved us over, proudly. He somehow had been in line behind Filo and the two of them were having lunch together. Toby and I sat down next to them, and we started chatting about nothing.

Toby, at one point, asked this guy he’d never met (Filo) what he did at Yahoo!. Filo remained composed and answered in the vaguest of terms. He took care of some servers. Toby pressed on, Filo stayed vague. Toby asked some more, and Filo remained more vague. At some point, Toby decided he’d had enough of this secretive and rude person, stood up, and left. He came across as slightly cross, vaguely upset.

I finished lunch and walked upstairs. Toby was in his cubicle. I asked him if he knew who he had been talking with. He said, no. I said David Filo, one of the founders. Toby looked dejected and said, “Why does this kind of thing always happen to me?”

Cute story, but it highlights the kind of person the two of them are. By now, though, I realize that Yahoo! didn’t need their personality. In particular, their genuine niceness ended up creating an environment where the people they interfaced with the most (senior executives) were never held personally accountable for their failures.

Just like the ripples created in a pond force the water to go up and down, the genuine niceness of the founders created a circle of incompetence around them. They should have forced zod to clean up the act of engineering as soon as the SBC debacle came along – and should have fired him once he wasn’t able to change. They should have never allowed a lightweight to head a crucial project like Panama. They should have realized the media strategy pushed by Semel was not working much sooner and cut him loose before the spectacular downfall.

6. Yahoo! Superstar

At some point, Yahoo! decided it needed to** celebrate accomplishment.** At one of our party-like All Hands Meetings, the creation of the Yahoo! SuperStar Award was announced. A series of awards were going to be given out. Fame, riches, fortune, and a dinner with the founders were on the table. SuperStars were going to be recognized company wide. It was a big deal.

We were all very excited about this. We were trying to figure out how the decision making process was going to work. Was the panel going to reward innovation? Was it going to be critical services? Was it business acumen? We thought that looking at who was celebrated was going to allow us insight into one of the things we strangely didn’t know: company priorities.

That should have already set a flag in my mind. I had to wait for the announcement of an award to know the company’s priorities.** In hindsight, I realize how cloistered and incompetent my senior executives were**: during my entire tenure at Yahoo!, I do not recall a singlemessage from the CTO. It was all on a strictly “needs to know” basis, and that led to informal channels for distribution of strategy. Not efficient, not reliable.

As if that realization hadn’t been bad enough, we were utterly shocked by the actual awards. First, it was clear that every department had its own award, since there was a single superstar in every department. Second, seniority was over-rewarded. While the ceremony highlighted the reason for the award as a single contribution, some of the contributions were questionable, and the awarded simply a long-termer. I recall how surprised we were when the company’s Party Princess (the employee that planned all the company parties) was the winner (for the HR department).

The winner for the Engineering Department, by the way, was the guy that created Yet Another Package Management tool. Yahoo! could have simply taken one of the myriad tools available. Instead, it wasted one guy’s time to create a tool that did what other did, and better, and then awarded him with the most significant contribution in engineering.

Suddenly, in one flashy and unself-aware award celebration, Yahoo! showed everything that doomed it to irrelevance. Political infighting, seniority preference, broken processes, lack of clarity on priorities, goals, and direction. All coming from the very top.

7. Conclusion

I have heard from people at Google and Microsoft that they thought Yahoo! engineers were not so bright. That was usually in the context of me out-IQing them on something, and the dig at Yahoo! was a backhanded compliment, whose sincerity I tend to find more reliable.

Let me simply say that wasn’t the case. Yahoo! employees in general, and Yahoo! engineers in particular, were smart, competent, and able. What Yahoo! lacked was not intelligence, especially at the individual contributor level. Yahoo! was rotten at the very top, and that rot projected downwards, generating frustration everywhere.

Frustration, I learned at Yahoo!, is the direct result of broken processes. You can work around an incompetent person, you can work around business issues, but you cannot work around a broken process. Any work you do is always subject to last minute cancellation, in a Dilbertian sort of way.

This kind of Frustration is not uncommon, of course. But it’s poisonous in an environment where a company less frustrating has the ability to unseat you in a matter of months. If I had run a large Internet company, I would send out my HR Department to figure out frustration levels once a month. And immediately react to the findings.

Yahoo! didn’t have to become irrelevant. It chose to.