Monday, January 14, 2008

Yahoo! and how to run it

I used to work at Yahoo as a programmer. It's a good place to work unless you actually care about your job and want to get things done.

Here's why I think that is. Parts of this might be boring for you if you have no interest in management or technology work.

It comes down to motivations.

At Y!, as it is internally known, I worked with a systems administrator, a project manager, and had above me three or four levels of management just within the division of Y! I was in. Of this subset of 6-7 people, two (me and the project manager) contributed anything to getting my job done. (Tangentially, my project contributed nothing to the Y! bottom line, but more on that later).


When I started working there I got a logon, a development machine, and access to the company CVS (a repository for uncompiled source code) and package repositories. My job was to write code, commit it to CVS, generate a "package", and ultimately, after testing on a staging environment, and getting approval from a manager, roll it out to the live web servers.

For whatever reason, this system not set up right when I arrived. I needed help. I turned to my managers and my assigned systems administrator.

Here's the part about motivations: I needed someone to navigate the byzantine inner sanctum of Y! and get me working. Now, mine was a small project and I was the only one on it. Why should my sys admin help me? What is his motivation? If he does a bad job, will he get fired? He has two possible motivations: he is a very nice guy, or he fears getting in trouble.

The only way to motivate anyone to do anything at Yahoo was to make him fear "trouble" - to complain to his manager. This "economy of complaint" sucks as a way to run a company. It's all stick and no carrot. And generally, no stick either. I mean, am I really going to complain to my managers all the time? That's the problem at Yahoo.

About the money:

Though my project was a huge money hole, for years it was never made profitable or scrapped. It was largely ignored. Who was ignoring it? I never had any idea what was going on in management.

Here's an idea: eliminate the hiring and firing power of management. Those roles would be handled by HR personnel who interview peers, and otherwise objectively evaluate job performance.

The role then of the managers would be solely to manage - to arrange teams, help programmers and sys admins communicate, do scheduling, and have a sense of the big picture. If my manager's not doing that, I report him to HR, just as he would report me if I weren't programming.

Why wouldn't this work?

No comments: