I'd like to hear Paul Buchheit's take on this. He was thinking a lot about company culture issues at FriendFeed, and now at Facebook.
Paul "liked" the blog post on Facebook. :-)
Google Engineering Management Mistakes
111–120 of 136 posts
Re: Google Engineering Management Mistakes
#112Wow, this is one of the coolest things HN has found in awhile. It's remarkable how, time and time again, formal incentive compensation schemes are shown to cause more harm than benefit. I started paying attention when Joel Spolsky called it out 6-7 years ago, and then read Peopleware (an excellent book) which reiterates the point (and calls it "teamicide"), and then read the Harvard Business Review article ("Why Ince…
Watch "The Wire"; it is a whole show about incentive structures.
Re: Google Engineering Management Mistakes
#113Earlier quoted context omitted.
It's not only about the money, but it's still about money. No matter what the company's 'mission', anything that changes the distribution of equity or profits will bring out that truth awfully quick.
An insight gleaned from Donna Meadows is that profit is not the purpose of a company's existence. Profit is merely survival, it's what facilitates the company staying "in the game". Her view is that the purpose of companies is to grow .
That observation was made by Peter Drucker, fairly soon after WW2. Profit is the cost of continuing to do business; it's necessary to ensure that you are allocating your efforts efficiently, but is not the intrinsic raison d'etre of a corporation.
His view was that the purpose of companies was to serve a social purpose. The purpose of Google is so that people can find information. The purpose of Microsoft is so that people can use their computers. The purpose of Merck is to keep people healthy.
I like this viewpoint a whole lot better than Milton Friedman's corruption ("the purpose of a corporation is to increase shareholder value"), where an abstract measuring stick necessary to ensure corporate accountability somehow became the whole principle that society was organized around.
Re: Google Engineering Management Mistakes
#114Earlier quoted context omitted.
And regarding $150k/year, saw your profile and you look young (although maybe you're not). Like it or not, you'll make more as you get more experience. Maybe that's reverse ageism, I don't know, but seems to be a fact of life, even in software, which is more meritocratic than most industries. Also it appears you do game development. Unless you become a rockstar or do the next Angry Birds as a solo dev, you'll tend to…
Your observations re: gamedev are correct. Actually, I can't really stand working for other people, so I'm doing a startup. Now I work almost all the time I'm awake, and I make 0 dollars. Hmm. So, what city do you live in? Does your employer have EDIT> I should point out that the highest-paying jobs I've seen advertised for non-management devs in Toronto are around 100k. Architects are like 120k. Then again, a detach…
I live and work out of two houses and offices. One in Seattle and one in SF. Less than 100 people. I used to be a consultant... if you've never done it I recommend all devs to spend some time doing it.
The listed salaries in ads are just for where to start negotiations at :-)
In any case, if your start up does well, but not so well that you can retire like Brin & Page (exit w/ say $3-5M) you'll find that higher paying offers tend to come a fair bit easier.
I couldn't tell from your page (or I just missed it), what does your start up do?
Re: Google Engineering Management Mistakes
#115Earlier quoted context omitted.
Stack ranking means just that: the employees are ranked. What the company does with the ranking can vary. The uses of a stack rank can be beneficial or harmful. At one company where I worked, the rank was used to identify employees for promotion. If an employee consistently ranks above employees at a higher level, then the employee should probably be promoted. The company also merged the ranks for smaller groups into…
The problem with any sort of ranking sysyem is that skill sets, jobs, projects, and roles are not freely fungible or normalizable. You're forced to make some totally absurd comparisons for the sake of fitting whatever the mold may be. We're not talking apples to oranges here; we're talking apples to watermelons.
In the stack rank meetings that I was involved with, we ranked employees in the order that we would hire them to a new team. This ranking considered several things: productivity, ability to drive tasks to completion, quality of code, willingness to help others, personality and more. Although it was like comparing apples to oranges, there was usually a consensus on the ranking.
A useful aspect of this ranking is that it's a different perspective from the written employee review. The review measured people against goals agreed to at the beginning of the review period. The stack ranking criteria considered more of a person's contribution. An employee could suck at meeting goals, but come out high in the stack ranking because of other things the employee did.
Re: Google Engineering Management Mistakes
#116"The sum of money just appeared in my bank account, but was so insulting low that I felt devalued. If a manager had just talked to me about how much my work was appreciated, it would have been better than money." This is true at a certain threshold. Appreciation is immeasurably better than an demoralizing, insultingly-sized bonus. However on the other end, if you go above and beyond normal expectations and save or ea…
I have, along with the relatively small teams I've worked with, saved/earned Google at least several hundred million dollars. Possibly over a billion. Certainly more than I can expect to earn over my lifetime.
What size bonus is appropriate for that?
I don't view it in those terms. I get paid reasonably well, but certainly not millions of dollars. And that's because the employment agreement I signed when I was hired is essentially an apportionment of risk. It basically says "I will give my best efforts for the company in exchange for $X/year, and in exchange, the company takes on the risk that those efforts will have zero or negative effect."
After all, I don't have to give back my salary when the I cost Google millions of dollars, which has happened on more than a few occasions. Hell, I've done virtually nothing useful since last May (I've done a whole lot, it's just that none of it has turned out to be useful).
I've played the startup game, and for the roughly 16 months that I was working on my own startup, I earned precisely $0. I worked harder then than I do now. But basically none of the risks I took paid off. That's the nature of risk: you win some, you lose some. It's not really fair when you collect huge paydays when you win and small paydays when you lose (though this seems to be the compensation scheme upon which the financial industry is founded).
Re: Google Engineering Management Mistakes
#117Curious, why does he end the presentation saying that a tech ladder is bad? Is the idea that they should have a management ladder, but all engineers are at the same level? That sounds like a recipe for disaster.
If you just want to do interesting work, an issue with career ladders is that little interesting work filters down to the people at the bottom of the ladder. This becomes a catch 22 for rookie employees. It becomes difficult to level up, because you're never working on anything that will wow your reviewers. In fact, the reward for excelling at boring but necessary tasks is often being stuck on those tasks forever. Th…
There's a very curious effect at Google that the most interesting work goes to interns. The least interesting goes to heroic senior engineers who've taken it upon themselves to clean up Google's codebase.
This is as it should be, I think. Actually, I've noticed an almost direct correlation between the quality of a Tech Lead/Manager and his willingness to do the boring stuff and pass off the interesting, challenging tasks to his subordinates.
Re: Google Engineering Management Mistakes
#118Earlier quoted context omitted.
The problem with any sort of ranking sysyem is that skill sets, jobs, projects, and roles are not freely fungible or normalizable. You're forced to make some totally absurd comparisons for the sake of fitting whatever the mold may be. We're not talking apples to oranges here; we're talking apples to watermelons.
In the stack rank meetings that I was involved with, we ranked employees in the order that we would hire them to a new team. This ranking considered several things: productivity, ability to drive tasks to completion, quality of code, willingness to help others, personality and more. Although it was like comparing apples to oranges, there was usually a consensus on the ranking. A useful aspect of this ranking is that…
I like the idea of a consensus assessment. Sometimes a person's value to the team is less quantifiable on paper than someone else's, but that doesn't mean it's intangible. It's usually quite tangible, and if everyone notices it (or the reverse), that's usually a good sign of the person's value-add. Not everyone is going to be the tireless codebot on the team, but that doesn't mean everyone isn't playing a critical role (Joel Spolsky obviously goes on at great lengths about this). Consensus-style reviews would probably arrive at a fair assessment of such value a lot more readily than individual writeups would.
Also, a lot of people make critical contributions that just don't get noticed by the team lead because those contributions -- moral support, culture, taking time away from one's own work to assist others -- aren't boss-facing. But if you asked his or her peers, this person would get a stellar review. In situations like these, group feedback seems pretty important.
Re: Google Engineering Management Mistakes
#119It's funny how you could take "Google" out of that slide and put "Apple" in it and it would be almost word-for-word applicable. Or maybe it's not funny. Too, I recognize that this author of this presentation spent time to make it public, and sharing this sort of information is always welcome, so moaning about the format might seem a little rich. But in the glorious tradition of the internet, I'ma gonna bitch about it…
Honestly, this sounds like the problems at any largish engineering company. At least the nice thing about Google is that they're openly discussing it, and sort of scientifically at that. At other companies, you just resign yourself to politics being more than 50% of the equation, and the company slowly goes to hell in between increasingly rare and brief spurts of innovation.
Re: Google Engineering Management Mistakes
#120Wall Street solves this problem quite efficiently! The annual bonus is really the same as the performance review, so they simply tell everyone "you did a great job this year, here are your compensation numbers."
That way, as a rank and file employee you don't really know whether your "review" was above, at, or below average. First order, because you'd have to ask your peers about their compensation, which most people consider rude (at least in the US). Second order, because the bonus is supposed to be an aggregate of your group and individual performance (plus your seniority), so it's usually impossible to find a suitable cohort for comparison.