This sounds a lot like a "lattice" organisation. It was invented by Bill Gore, founder of W.L. Gore & Associates (famous for their Gore-Tex fabric). At Gore, apparently everyone is an associate with no specific job title. There are no chains of command or hierarchy. People choose to work on projects based on their own judgement.
As Gore grew, it was apparent that this structure did not work with more than a couple of hundred people. So now, teams are limited to about 200 people (approximately Dunbar's number). I imagine Valve will run into this social limit as well once they grow well beyond their current 260 employees.
Given that Gore still exists, has 9000 employees and is profitable after 60 years is testament that such a structure can work for small as well as larger organisations over a longer period of time.
I was literally thinking about Valve's organizational structure this week, wondering if it had a classification. Nearly bugged Gabe. Thank you for sharing this.
Funny but true I interviewed and was given an offer but the pay was so far off what I was earning "at market" that I ended up not going to work for them.
The interview process was amazing, took 6 hours at a white board, multiple teams drilled me on all the various languages I claimed to know and then some business teams grilled me on my thoughts about the industry.
The passionate side of me really wanted to work for them but the pragmatic side of me made it clear I would have to work for considerably less than I was making open market. To make things worse my next position literally was almost double the salary Valve offered me.
I was just last night joking with my wife that when I want to settle down maybe I should try and go back through the process with the understanding it will most likely be 1/3 of my current salary.
I love working in my passion but as I always tell people the people at the grocery store still want me to pay for my food.
I try to balance passion and pragmatism and if I need some crazy passionate project I take on a side project on the weekends for some open source project etc.
Really curious to hear more about this.. $numbers would be awesome, but if you (understandably) aren't willing to share, could you give more info on your skillset, professional experience, etc?
What you're saying and what Valve says are two very different things. The handbok didn't just gloss over the compensation bit - they go into detail about proper compensation due to contributed value etc.
Edit: Just looked at your linkedin. You sure do have an interesting combination of skills.
I think you made the right choice unless taking 1/2 the salary for a couple years would have been a stepping stone to your own game company. I hate the 'passion' term because it's often the term thrown around by owners looking for employees. Of course the owners are passionate since they stand to gain a lot of money from the companies success.
I will passionately bust my ass for 12 hour days if I'm paid properly.
I do passionately bust my arse more like 14hrs a day and many times 7 days a week. And I'm just looking for places where that is rewarded.
My biggest flaw is I'm not a 501 programmer and I will accidentally choose an opportunity that lights my passion but doesn't pay my bills. I've done that in the past and to be clear it was very painful and soul crushing and something I do not want to repeat again in my life.
I know more than most people that more money will not make you happy.. I've been in tech for 30 years and I've had all sorts of levels of compensation, failures and successes. Always the differentiators have been: The people I work with, the passion I feel for the problems we are trying to solve and the acknowledgment I get for my contribution.
Money is just a version of acknowledgement but clearly not the most soul fulfilling type. The respect of my peers and the opportunity to learn and work on solving big problems are much more rewarding. But to do all those things I need to pay my bills and put some away for my later years when I wont have the same earning power.
It seems like you're wanting SVP / C-staff level pay (from your linked in profile), and it doesn't surprise me that Valve wouldn't pay that inflated amount.
Income Equality at work.
To be fair, you do seem like a talented person and I'm sure you are excelling at your current and past positions, but maybe you just aren't a good fit for Valve since they don't need more SVP level decision makers.
"501" is not an accepted term, and doesn't even make sense. Is it supposed to mean someone who programs at 5:01 or someone who doesn't? Someone who plays in the office all night, or someone who makes progress on a healthy schedule?
It's one thing if everyone has to play scrappy. But if there is plenty of gravy to go around, and your CEO is on the forbes list, I'd expect market rate or better.
It's less about greed and more about not being taken advantage of while someone else gets rich off of your back.
Well some people belong at a startup, and then there are some people like you who clearly don't. Life shouldn't be all about the money, sorry to break it to you.
So people should go be employees somewhere at 1/2 pay and bust their ass so the owners can sell and never have to worry about money again? Life can stop being about money, when everything required to live stop costing money. Food, shelter, education, healthcare all require money. Want to have kids, money. Want to travel and see the world, yep that also cost money.
Startups are exciting and fun, but their success is gauged by a single metric - money. When startups get acquired there are endless congratulations on this very site. And rightly so, the owners should be rewarded for their work.
In the end I guess you're right. I don't belong at a startup as an employee making 1/2 my salary. I either need adequate pay and/or an equity stake to work at one.
Life shouldn't be all about the money, agreed, but it is reasonable for someone to require enough salary to not run into the red every month paying for basic living expenses. Also, while money isn't a good motivator (see D. Pink), not enough money can be a terrific de-motivator.
Like anything, there's a reasonable-middle as to the salary requirements for an individual.
Given that Valve apparently makes >6 mill in revenue per employee yearly, I sincerely doubt that anyone they choose to hire is going into the red from normal living expenses.
Surprised to hear this. A couple years ago, local (LA-area) recruiters tried to get me to interview at Valve based on some very impressive salaries others had received.
Then again, I'm a programmer. They seem very intent on collecting the absolute top of the market for game programming talent. For the record, I love Valve but am happy in LA.
But now I wonder how they decide what to offer new hires, based on this process.
I agree. The whole paragraph, in fact, is the best description of that thing I've ever read.
There are more than a few things in here which, if true, turn common ideas about management on their head (or rather just shoot them in the head). What's exciting is that they reflect how work actually gets done. Shouldn't that be our organizing principle?
I think what makes startups so effective is that they naturally work this way at first. But then, typically, bad ideas about how one is supposed to "manage" and "scale" kick in and stifle the thing. This document is interesting as a conscious strategy for not being stifled. Valve's success lends it credibility, and the fact that Valve is not a startup makes it more interesting, not less, because it's so unusual.
Hm. So is this a leak or a "not strictly public but if it fell into the hands of a bunch of people we want to hire then I guess we'll just have to deal with it" sort of thing?
With this and the recent Michael Abrash blog post, I get the feeling that Valve is putting a bit more attention into making themselves attractive to developers. Frankly, I think it's working.
It works really well because Valve hires only highly experienced Senior people. Which is why they're able to manage themselves.
They liked my game ideas in my blog (I even predicted Steam's Big Picture mode) and I got a call from Greg Coomer, but ultimately I never got an interview because I didn't have the experience and hadn't shipped any real profitable products. It was a really nice reality check though. It made me realize where I am in life and where I need to go. So thank you Greg.
Also, they play the "Portal - Still Alive" song when you're on hold.
If there is no boss, everyone is your boss, or your client. Not a bad way to go about things. You end up overall working better with people around you.
Also, being evaluated by what you deliver and by your peers isn't too bad, considering the alternative is possibly a non technical boss that may never understand what you do.
I try to work with co-workers as if they were friendly clients. I think this leads to good product launches and results.
How exactly is this double speak? I am parsing this as saying that "nobody" is my boss (if I were at Valve), ESPECIALLY Gabe. If I am working on a team and there is a team lead and he asks me to do something I am most likely inclined to do it with little pushback/skepticism, what the handbook is saying that if Gabe tells me to do something I better damn well run it by 1 or more other people (the team I am on most likely) and discuss it before I even think of doing what he suggests.
I really like that they highlight and discuss possible downsides of their approach. It makes it a more credible source of inspiration and discussion for other companies.
In my experience it's really difficult to use material from Github or 37signals, for example, to start a constructive conversation on work practicess at your own company. Half of the team might dismiss it as a self-promotional, patronizing PR fluff piece, while the other half might gobble it up and fail to rationally weigh the pros and cons. And everyone gets this vague unpleasant feeling of being told that they're inadequate - like a 15-year old girl watching a weight watcher commercial.
Page 55, Josh Weier, 14 year old boy. Google him. This manual is from this year and it says he is 57. He really does look like he's been bathing in stem cells
This must be an in-joke. Best thing to do is respond the same way you do when you hear an in-joke at the new job: laugh along and then hope you overhear a conversation where someone explains it.
If Valve's organization is simply to let employees fight it out thunderdome style to see who controls projects, culture, and direction, the organization should be grown by spinning off completely new and independent businesses, not by hiring people. Then the economics of free enterprise provides a true risk/reward system. With salaried employees rewards are capped. Employees will only stick around until they discover that the real economy pays much better for hard work and good ideas and that the risks are basically the same: no income.
The "we have no structure" culture is disingenuous. I don't buy the idea that most of the employees at valve don't want to dominate all the projects and their coworkers. It is exactly the same anywhere. You can't simply say 'we don't have managers' as obviously only certain people are going to have power of budget and final hiring decision. Only certain people can sign documents. Only when employees can expense anything they want and hire anyone they feel should be hired would a "no managers" description be appropriate. You might say that this would never work, but it does work if each employee is given assistance or investment to spin off a new organization at any time, hire anyone, and spend money.
Now, this might surprise you, but working on cool projects can be its own reward. Your utility metric is flawed.
"I don't buy the idea that most of the employees at valve don't want to dominate all the projects and their coworkers. It is exactly the same anywhere."
Did you perchance get your worldview from anime? Really? This might also surprise you, but a lot of well-functioning folks don't care about petty politics as much as doing cool stuff.
"working on cool projects can be its own reward. Your utility metric is flawed."
Everyone is entitled to their opinions. My opinion is people that say they don't care about monetary rewards are bullshitters. After all, if you have enough money you can work on any project you want.
"a lot of well-functioning folks don't care about petty politics as much as doing cool stuff."
A lot of people SAY all they care about is doing cool stuff. People employed at a company to earn money are not these people (but they see if people will buy it anyways). Denying that you're playing politics is politics 101.
I don't buy the idea that most of the employees at valve don't want to dominate all the projects and their coworkers.
I'm pretty sure I don't want to dominate my coworkers, so I find it easy to believe there are others who don't want that either. In fact, a coworker who wanted to dominate me would be a highly unpleasant coworker.
"Co-" means "together". There are other forms of human relationship besides master/slave.
If the culture at Valve is one where everyone has self-determination, anyone trying to "dominate" others would quickly start to be seen as a dick, would stop being able to find collaborators, would stop being able to get much done, and would eventually be weeded out.
Anecdotally, I dislike telling people under me what to do, let alone "dominating" them. I much prefer working with people who are self-directed individual contributors. I would not want to hire anyone that I thought matched your description, and if I found out that they did, I would fire them when I saw any clear evidence of it.
Whatever is offered is simply designed to keep people from leaving, nothing more. Any of those in no way competes with being a major owner of a valuable firm. Most firms do things such as grant options that are way out of the money, essentially worthless pieces of paper, and that take half a decade to vest. Even if a firm grants equity, which is rare, it is based on pumped valuations not based on free cash flow and which also takes half a decade to vest. Even then, it is likely to be less than 0.1% of the company. Bonuses, as well, are small in comparison to the value created by employee's work or even the employee's salary.
Fishbowl—
The conference room by the lunchroom. The one with a bigglass wall. Don’t let the name throw you—we don’t actually use it as a fishbowl! Except, of course, on Fishbowl Fridays, where we fill it up with tenthousand gallons of putrid saltwater so that all the manta rays and sharks will have something to breathe while they fight to the death. You won’t seeit in your list of benefits, not because it isn’t fun, but because it is illegal.
Best part so far:
"Accepted truisms about sales, marketing, regionality, seasonality, the Internet, purchasing behavior, game design,
economics, and recruiting, etc., have proven wrong surprisingly often. So we have learned that when we take nearly any action, it’s best to do so in a way that we can measure, predict outcomes, and analyze results."
Inspiring reading. I wish they had chosen a better example of the archtypal "T" employee than the Heavy class...many of those attributes he has are just things that are obvious consequences/contributing factors to his main skill "hugeness, killing people".
I just can't believe that this works as seamlessly as the handbook would have you believe. It seems it would create a very Lord Of The Flies/cliquey atmosphere. In a group of people, there always exists some kind of hierarchy, whether it's explicit or implied. In this case, there is zero attempt to create an explicit power structure, so it's 100% implied, but I don't see why that's fundamentally better.
In general this sounds like the natural structure for pack animals, where you join a pack and no one anoints a power structure, but it becomes clear very quickly who is "alpha", "beta", etc. IMHO it sounds like it possibly could be a very stressful situation.
Somehow I tend to think that this leak is intentional... and it may be that the document has been specifically written for that purpose. Anyway, if what's written is true, Valve must be an amazing place to work at.
This is a cool handbook. I wonder what the frustrations are that come with this? As the book says, Valve sucks at disseminating information. It'd be interesting to see if there is some sort of pervasive feeling of "why didn't I know about that project? I wanted to work on that."
I wonder if this only applies to the game developers or other Valve staff (say web developers) as well. Is there anyone here working at Valve to could clear this up?
Why would they apply it differently to non-game developers?
"Whatever group you’re in, whether you’re building Steam servers, translating support articles, or making the tenthousandth hat for Team Fortress 2, this applies to you."
Well, I can imagine there's a lot of web designers who would love to take a shot at working on the physics engine for the next Portal game. Or play testers that would rather be actually doing development on the games. It would be interesting to see how people are cajoled into doing "lesser" jobs.
So .. I thought about it. If Valve were to hire me [1] I can see myself attaching to the systems admin role and liking it a great deal. It's what I do, what I like.
I do wonder how they make it happen for back office jobs that are not glamorous or especially fun but absolutely must happen.
[1] Hey, Valve. I'm not currently in the market, but I am a damn fine systems administrator. Drop me a line if you're interested.
Valve is on the list of companies I'd work for if I weren't doing a startup (along with Apple, Palantir, Square, Sig Arms, and anything Elon Musk is attached to in any way).
This kind of company coulture seems to run thru the most succesful software companies, such as Google is prominent is their areas, Valve are huge in games, Facebook seems to work in the same way. AFAIK Apple is hierarchical and is run in a very "traditional" fashion, but are still very successful.
Is there a pattern about theese things, and what way of managing a software company works best?
Unless you've worked at those companies, I'd suggest you refrain from stating that Google&co compares in openness with Valve in the way they let new-hires pick their own starter teams and similar things.
You can move around as you wish if you're a Real Googler. The Real Googler Line used to be Senior SWE; now it's somewhere between Senior and Staff. Staff are Real Googlers, and Seniors who are likely to make Staff are Real Googlers, but Seniors who are perceived as having plateaued are not.
If you're not a Real Googler, 20%T will be perceived as slacking off, and you're going to have a hard fight to get a transfer. Generally, it's hard to transfer unless you've had a recent promotion, so if you're not going to get promoted based on your current project, you might as well leave.
Ouch. Yeah, a friend of mine at G seems to be in this position.
Why do tech companies think that hitting a plateau is a bad thing? Someone who's not going to further advance and who is productive and happy should be allowed to remain happily churning stuff out, with no pressure to hit the next ranking, or be ousted, or be unable to move.
(I've seen some demotions at my company, which was basically recognition that "Okay, we want to keep you, and in the past we had to promote you to do that because of the fucked-up stuff that HR was forcing us to do. Here, have a lower position, and you get to keep your salary.")
My experience at Google is the opposite. I am friends with many Senior SWEs who have no interest in the next promotion and they do fine. They get paid well, get good bonuses, get to lead new projects, and so on. I'm also friends with people who are relatively new to Google that have made big (and small) moves inside the company.
In a company with 30,000 employees, some people are going to be unhappy. But the vast majority of people I interact with at Google are very happy. The biggest problem I face is the five minute wait for someone to make me a latte.
Wow, that's unfortunate too. Combined with your previous comments I have to assume that you were a long time googler. Can you tell us what it was like back in the day? I'm really curious how big companies change / devolve over time.
I wasn't at Google for very long, so my picture of its long-term trend has had to come from other people.
I think Google made several mistakes. First, the language issue. C++ is undoubtedly the right language for some of the work, but their language policy leaves a lot to be desired. A lot of systems that should be in a language like Scala or Python are in languages like C++ or Java. The problem isn't "bad languages", because C++ is not always bad; it's a very small language whitelist and an arrogant dismissal of "Other Languages" that goes up to the top. By the way, Python is nearly deprecated in production. It's used for some projects (such as Google's code review system) but generally the only people using Python for their day job are managers who still code, and then if their ideas take off they make other people implement them in C++. In reality, Google's mainly a C++/Java shop, with Java tolerated in the context of acquisitions.
A limited language white-list, coupled with a willingness to produce huge programs without modularity (Google's codebase is one monolith) produces something like this: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol... . This wasn't written about Google, and it's probably much less true of Google than of typical enterprise Java shops, but Google's not immune to the illnesses of the large-program mentality.
Ok, this sounds a bit like a religious war, but I think it's generally true that shops using Java and C++ for almost all of their development will very quickly get past the point where one person can have an independent impact-- especially on a 20% basis-- unless that person has above-normal political favor and can always end up on the right projects. Hence, politics. That said, Google was always a C++ shop at heart, and it didn't go to crap until late in its trajectory, so there has to be a lot more to the story. You can't really blame this on languages, or the culture would never have been good.
What I've heard is that the real change came in 2006-9, which is when Google hired a lot of executives from companies like Intel and Oracle, and they tracked a lot of shitty culture into the place. For example, "OKR" is an Intelism. This explanation sounds very plausible. What I was able to see, even in the short amount of time that I was there, was a top-down effort to concentrate power back in the hands of executives, at the expense of engineers. This would have been a creeping campaign, but Google+ turned it into a war.
The language issue was a "tyranny of past success" mistake. In 1998, using C++ for a high-performance service was the absolute right choice. In 2012, C++ still has a place but most new development should be in a language like Scala or Clojure.
The bigger mistake Google made was that it hired a bunch of executives from other companies and didn't tell them to wipe their feet off. So they polluted the place with horrible culture.
Finally, Google+. I don't want to get into too much detail there, but I'll mention that 90+ percent of engineers hate, if not the Real Names policy, the draconian enforcement of it. I don't think RN itself is the source of all the anger-- for some it is, but a lot who are on the bandwagon are mad about other things. I think it's a touch-point for a general sense of engineer disempowerment.
That said, Google is a huge company. If you end up on the right project, it's a really great place to be. I know people who've been there for 5+ years and couldn't be happier there, and there are a lot of cool projects the company is doing (although most of the good work is in MTV; I'd avoid applying to any other office). It has a lot to do with where you land and what alliances you're able to make in order to get the things you need.
This sounds like a mess. It's why I don't like working for anyone. Unless you play politics and please the right people, your livelihood will be limited.
This model seems limited to companies that are staffed with highly motivated, highly skilled people. I don't think you'd want, say, a branch of McDonalds or a nuclear power station to be run on this model.
Maybe a nuclear power station, as we currently design them, requires very rigid procedures. But that probably also reduces internal information flow, punishes people for noticing problems, and so on. So perhaps that's really an argument against nuclear power as we know it.
McDonald's isn't designed the way it is because people are stupid. It's designed to maximize returns on capital investment. Workers are made to be interchangeable, and the product is uniform and predictable. For 300,000 years, humans self-organized to take down caribou or whatever to make our own dinner. Is it really likely that we need a system like McDonald's to get a burger made?
Is it really likely that we need a system like McDonald's to get a burger made?
I make a pretty fine burger, myself. And my own bread, for the buns.
But if you want to deliver a consistent product across thousands of stores for a reasonable price, you need standards, managers, guys behind the counter performing to task and standard. So you can walk into a restaurant in Bangor or in Spokane and know what you're getting.
Yet .... I can't deliver a home-cooked burger without the same structure McDonald's uses.
I get my meat from a butcher who gets it from some other guy and so on on back to Bossie in the pasture. That's one thing out of hundreds of bits that make up daily life.
We all of us depend on millions of others doing things to task and standard just to exist - it's baked into the bones of our society.
I don't think you can just get rid of it without building a system to take it's place.
Maybe this tells us that the staff of a McDonald's restaurant could conceivably be replaced by software, whereas Valve will always require human beings to do its work?
But I don't see it, or not real soon. Automation even in a controlled environment is tricky, and random customers are _random_. You have people there to handle exceptions, which are many.
100% yes you do need a system like that to get a specific kind of hamburger made for you in a short amount of time as you drive through their store during very busy hours while fulfilling various quality standards.
It's not about getting any burger made, it's about getting a McDonald's burger made.
AES is an energy company that was run on similar principles for a while.
My knowledge of it is purely based on <a href="http://www.amazon.com/Joy-At-Work-Revolutionary-Approach/dp/... book</a>, which was written by a co-founder who was later deposed. (The book goes into that story but tldr is company prospers, economic crisis hits, company suffers along with all other energy companies, CEO is blamed, fired and replaced with more conventional executive.)
But to give you a sense of core techniques, IIRC pretty much all staff - incl power plant maintenance staff - had major expenditure authority but before they could make any major decision they had to consult with at least two other employees. As long as they could demonstrate that they had done that, it was assumed that they had made a reasonable decision.
There are a lot of good ideas in here, but stack-ranking is a terrible one.
First, it makes people hate each other. Anyone who comes up in the bottom half is going to be looking immediately to move to another group simply because he ended up in the bottom half. And if someone ends up near the bottom and ends up with no bonus or on a PIP, he's going to be spending the next few months trying to figure out who screwed him, which creates this whole side game that has nothing to do with actual work.
Second, it encourages people to work on the projects that are most visible, which are not always the most valuable.
Third, it creates a general atmosphere of distrust. People are constantly watching their back for others who might screw them in the peer review process.
This is an outsider's view and a microgripe, and I think a lot of the ideas in that book are good ones. I just saw the words "stack ranking" and knew I had to speak up. It's seriously not a good idea. If someone's going to get whacked, it should happen for a real reason, and not because that person ended up in the bottom 15% because only a couple people knew what he was working on. Maybe he was working on something important but unglamorous. I've seen that kind of shit happen all the time with stack-ranking systems.
As long as stack-ranking is only done to adjust compensation, I don't really see the problem.
As a more traditional manager, I have to consider salary adjustments for my employees. What Valve seems to be doing is to let everyone consider salary adjustments for (half) of the team.
And since the rankings appear to be averaged out, one vindictive co-worker isn't likely to screw you over.
>it creates a general atmosphere of distrust.
Alternately, it creates a culture of responsibility. You want to do well in stack-ranking, so you're going to do your best work.
Finally, 50% of any group are below average. I honestly wouldn't mind being considered "the dumbest guy in the room" if I got to work at a dream company. See the following quote from Moby Dick:
>And there is a Catskill eagle in some souls that can alike dive down into the blackest gorges, and soar out of them again and become invisible in the sunny spaces. And even if he for ever flies within the gorge, that gorge is in the mountains; so that even in his lowest swoop the mountain eagle is still higher than other birds upon the plain, even though they soar.
A lot of people interpret average as meaning "mean". Really average is a stupid ambiguous word that should never be used. Be clear: say mean or median, but never average.
If it's only used for compensation, I agree that it's not such a big deal. Getting a 10% year-end bonus instead of 20% is not exactly "getting screwed".
The only large (200+) private-sector company where I've worked is Google, where their stack-ranking/Perf system had some serious problems.
The first was a 5% cut-line. If you were in the bottom 5% of the Perf stack, you ended up on a PIP. Who usually ends up here? Some were objective underperformers, who'd been coasting for years, in some cases running at less than 1 CL per month. Most, on the other hand, were junior people on underperforming teams-- and of course, those junior people had the least to do with that team's underperformance, but they were poorly established so they got the shaft. That's how most layoffs actually work: junior people who landed on the least effective teams. It's not atypical, but it's dysfunctional.
By the way, PIPs have nothing to do with "improving performance". They exist to make it easy to fire people without severance. I actually think PIPs are imbecilic, because I'd rather cut a 3-month severance check and separate cleanly than keep a fired employee in the office for 1 month, but that's another rant. PIPs make the finance department happy (look at what we saved on severance payments!) but piss all over morale and make the manager's life hell, to say nothing about what they do for the PIP'd employee.
At Google, a PIP is effectively permanent. Even if you pass the PIP, you become damaged goods and can't transfer. It sticks around on your permanent record until you leave.
Which brings discussion to the second problem with Google's system. It sticks around forever.
When these types of systems get rotten is when they start getting in the way of peoples' transfers. It means that the people who really should be moving to other projects can't get on to them because no one wants to take a chance on that guy who was an "objective underperformer" in Q4 2005.
So, to come around to your point, I agree that if the rankings are only used to adjust pay, there's not much harm done. Unfortunately, it's rare that data collected is only used for the stated purpose. If these numbers start damaging peoples' ability to choose their own projects, it can become nasty quickly.
I suspect that people are interested in an article about Valve's culture not (just) because they'd want to work at Valve, but also to take its good ideas and use them elsewhere. I think talking about how one of those ideas worked well or poorly at another company fits perfectly with this discussion.
It seems foolish to "take" one small part of the thing and try to "use" it elsewhere, while ignoring the massive difference that dwarfs all the others: workers managing themselves. That's what's important and new here, and that, supported by the fact that Valve has been so profitable, is what we ought to be talking about.
This discussion is the HN equivalent of the prospective employee/er who pays lip service to "culture" but is really only interested in salary.
I don't understand how Valve could implement a PIP. How do they even fire people? Is it just your team shuns you and then you end up with nothing to do, so if you don't figure out something yourself, you wither away and are culled by the wolves/robots?
>Is it just your team shuns you and then you end up with nothing to do
I think the "wither away" bit is probably actually the truth. Let's say you're consistently ranked in the bottom and stick to projects that don't add value to the company. Since stack-ranking determines compensation, someone who costs the company money probably gets salary decreases. After a while, an underperforming worker could make more money in a different company, and they take the hint.
Of course, since Valve is dedicated to hiring the right people, they probably don't hire too many duds. Talented people who just don't fit in probably just update their resume and go somewhere else.
To quote Valve's handbook: "This is one downside of
the organic design of the company—a poor hiring decision
can cause lots of damage, and can sometimes go unchecked
for too long. Ultimately, people who cause damage always
get weeded out, but the harm they do can still be significant."
Thanks. Presumably if we're talking about 1 CL / month this is more like a feature checkin to the release branch, rather than individual working commits given the context?
(1 local WIP commit per month really would be slacking off!)
CLs become one perforce commit, but their lifetime is more like a git branch. I try to keep CLs under 100 delta lines. (In contrast, I try to keep git commits around 10 delta lines.)
People that only write one CL a month have probably written a fairly large amount of code, but are being blocked on reviews. When I see a review for more than 100 lines of code, I immediately think, "I'll do this later" or "Oh good, I'm only CC'd on this review; ignore." If the person doesn't have anything else to work on, this blocks him until I feel like diving into 1000 lines of code I've never seen before. Conversely, if I got one 30 line CL every day for a month, I would probably immediately review each, turning the one-CL-a-month guy into a 30-CLs-a-month guy with the same amount of code.
I haven't heard anyone besides mchurch cite number of CLs as a productivity measure. Lines of code sometimes, but not CLs. Sometimes it's just not worth it to break a large, cross-cutting change up into small chunks.
That said I do vastly prefer smaller CLs because the review process goes so much better.
Wow, I'm surprised that google would work like that. Did they actually tell you that you'd get fired if you were in the bottom 5%? I assume you must have been there back in 2005/ 2006 to have seen someone who was an objective underperformer in Q4 2005 but was still allowed to work there. Maybe things have changed since then?
As with all mchurch comments, you need to take it with a grain of salt. He was with Google for less than a year and has been extrapolating his short experience into a generalization of the company.
I think the problem is he comes here every couple of weeks and writes almost the exact same rant [1][2][3]. People are tired of point-by-point responses because they know he'll just be back a couple of weeks later and write the exact same thing again.
Honestly, I don't know why his comments always seems to get voted up. I assume they're voted up by people who have not read the previous exact-same rants...
His comments get upvoted because many readers of HN are looking to hate Google for some reason, and he writes a verbose "damning" description of Google's internal politics that makes Google seem very hate-able. Good writing + what you want to hear = instant upvote.
The only way to really refute what mchurch says is to post evidence of his work from when he was at Google, but that's a massive violation of his privacy, so nobody is going to do that. The only thing to do is dismiss his argument with vague statements like, "no, that's not true", which nobody is going to believe when compared to his well-written rants.
If you want to know the full mchurch story, I suggest you get a job at Google. Then you will have enough information to decide whether or not mchurch's rants about Google make sense.
I don't think people want to hate Google; I just think they're attracted by the controversy. It's like the faster-than-light neutrinos. People weren't interested because they hate Einstein, but because it's some apparently new information that contradicts what they previously thought to be true.
I'm interested simply because Google seems highly influential in the new-school tech sector management. These collections of anecdotes feed into the folklore wisdom held by managers.
As someone who started at the same time as mchurch, and observed what happened on the google-internal mailing lists, the full story probably shouldn't be shared online without his consent.
The problem with stack ranking and PRP is that its subject to capture by groups with in a company that will manipulate it for their own ends - which end up being counter to the longer term aims of the company and share holders - the HR director gets a bonus for managing the pay quanta down but the company loses 10x performers.
For example when I worked at BT the PRP was done - then to make the figures work out with the the increase in pay quanta - the figures where fiddled in secret meetings.
It also leads to people playing the game - for example to help with passing his board one of my colleges at BT made that his goal and play'd the game - but as my boss ruefully commented "he hasn't done any real work for 6 months".
I have also heard of mangers having quotas of people to give bad apr's to to force them out - one rather grim story from a friend who commented "well our unit has 2 people with terminal cancer so they where put down as cat 4's"
Stack ranking comes out of a couple ideas. One is that it's important to always be bringing on new people with a fresh perspective. If no one is leaving the company it's hard to do that effectively, although normal attrition can usually take care of this. Two, it's management admitting that they have hired the wrong people at some point and have dead weight. Of course management never wants to say they screwed up, but if every hire was a perfect hire then there were be little reason to try and remove people.
The problem is that stack ranking on an individual level puts the employee focus on themselves instead of the team and the company. All employees should be focused on doing what's best for the company as a whole and not what's best for themselves. Stack ranking sets up the exact opposite situation.
If there are poor employees on the team then speak with them, put them on corrective action, etc... If you already have a team of great performers, ranking them will only work to align their goals differently from the company and that can lead to all sorts of problems.
To be fair to Valve, it sounds like you're talking about rank-and-yank, which is not necessarily the same thing as stack-ranking. I made the same mistake in my response: assuming that stack-ranking meant that those who come up in the bottom get PIP'd or fired. That's not strictly true. However, most stack-ranking systems end up as de facto rank-and-yank.
Objective, across-the-board incompetents are very rare. Generally, companies that are well run are going to have very few people (at lower levels) who actually should be fired. Oddly, the levels at which firing 10-30% of people make sense are the managerial levels where people almost never get fired (and if they do, they get huge severance packages that include outplacement assistance).
Most hiring mistakes are bad matching, not bad hiring. The right person was brought on and put in the wrong place. So the correct solution is to pivot: help the person find a transfer to a more appropriate team.
In very small companies, this may not be an option. If there's only 1 project, and you hire someone who's a bad fit for it, you have to fire him, because there's nowhere else to put him. But companies at that size generally don't have HR departments or company-wide stack-ranking.
> Most hiring mistakes are bad matching, not bad hiring. The right person was brought on and put in the wrong place. So the correct solution is to pivot: help the person find a transfer to a more appropriate team.
Maybe at google. But objectively bad hires are not uncommon in general.
In "objectively bad", I'm talking about competence.
I've met 5 times as many unethical people as incapable people. Easily. The unethical people should be fired once found out, but that's a given. The problem is that unethical people are usually impossible to spot until after they've screwed you.
Well, I don't think hierarchy is prima facie evil. Conceptual hierarchy is how people think. The problem with human organizations (and "managers" and the bad rap they get) is that hierarchies are easy to corrupt by aiming at the top, and that they usually promote the wrong people-- social climbers instead of leaders.
Managers get a bad rap, but good managers (possibly 10-20%) are worth their weight in gold. Bad managers are disastrous. No managers is rarely an option. "Flat" organizations tend to devolve into young-wolf conflicts and evolve their own unofficial hierarchies. In fact, young wolves are more dangerous than managers; because young wolves' positions of influence are unofficial and therefore unsafe, those around them are direct competitors and they have more incentive to attack. Managers rarely sabotage their own reports, because they have the safety of being a level or two higher. Young wolves frequently do this to people who are technically same-level but haven't been around as long or had as much of an opportunity to establish themselves, but whom they perceive as long-term threats. If nothing else, you need good managers in place to prevent young-wolf conflicts.
The problem with traditional management, though, is that people promotions are pull-based (i.e. people get promoted by conning the top guys) rather than push-driven from below. The result is that people get promoted based on social climbing rather than real leadership, and managerial incompetence sets in very quickly.
I'd get rid of "performance" reviews. The word is loaded, and most workplace conflicts have nothing to do with performance. I've worked in elite companies, so this observation may be unusual, but I've seen maybe 20 people get fired in my career, and only one was for performance. The others were personality conflicts or other reasons. Dressing these issues up as "performance" issues just makes everyone angry.
Instead of reviewing "performance", which is code for "dressing up how I like you as something more objective", there should be a review along two axes: Skill and Impact, which are much more objective. I came up with a half-decent (IMO) scale for assessing software engineering skill here: http://michaelochurch.wordpress.com/2012/01/26/the-trajector... . The difference between 1.5 and 1.6 may be hard to assess, but that between a 1.5 and 1.8 is pretty much objectively visible.
Here's the kicker: these numbers are public. It shouldn't be "sensitive". Management ought to have the balls to say, "we think this person has Skill 1.7 and Impact 1.8 and here's why." What is kept private are reviews more than 12 months old, so that peoples' trends aren't visible for everyone to see. The other thing that deserves to be private (because it is somewhat sensitive) is assessment of a person's potential, but that's not what formal reviews are for. That should be handled informally, in any case.
Ok, now as for how the reviews occur... as I said, the problem with traditional management is that selection occurs on a "pull" rather than "push" basis. So instead of people having "managers", they choose sponsors who are typically more senior (although at the very top levels where "more senior" is hard to find, peers will do). Sponsors keep track of their reports' growth and advocate for them during the review process. The difference is that a sponsor relationship can be terminated at any time, by either side, without requiring anyone to exit the company, and that an employee can (and should) have 2-3 sponsors.
This system allows people to "vote with their feet". If someone's not a good sponsor, people move away from him.
What happens if someone has no sponsor? If you have no sponsor, you go before upper management yourself during review time. You advocate for yourself. If you can effectively communicate what you have done and what you will do, then you may advance. If you can't, you'll stagnate. (The purpose of the sponsor is to be an intermediate advocate with a better understanding of what the company and its management value, but there's no reason a person can't be allowed to advocate for himself.) Of course, if someone can't get a sponsor for a period of months, that's a sign that this person might need to leave.
It's also worth noting that heirarchy, at least in principle, is a very efficient method of communication.
A true peer-to-peer system of n people has a communications graph which is a K_n (complete graph on n nodes). Each node must monitor communications from n people, and there are O(n^2) edges. That can't scale. But for small n it isn't bad - the distance between two nodes is 1.
A tree has n-1 edges, and most nodes only need to communicate with 3 other nodes. The distance between 2 nodes is log(n) so communication costs aren't disastrous.
We love trees in computer science, the only reason we don't love them in management is because our personal experience leads us to compare O(1) communication costs (in a K_n) with log(n) communication costs (in a tree).
Peer-to-peer is only O(n^2) if every node is always connected to every other node. But Valve's organization seems to work by creating much smaller sub-networks on an ad-hoc basis, so that at any given instant, each node is only actually connected to a small set of other nodes. Instead of a hierarchical system which would have each sub-network be permanently defined with clear boundaries, and create a network-of-networks to coordinate them, this method ensures coordination among the sub-networks by relying on most nodes being a part of multiple sub-networks and having a slightly different set of connections, such that there's an overall mesh that does actually connect every node in the graph, directly or indirectly.
Sort of the way torrents work, in fact: there's a pool of seeds and peers - which might have thousands of members - but your client is only exchanging data with maybe a few dozen at any given time. But since each peer has its own slightly different set of connections, data anywhere in the system can still propagate to the entire system.
I suppose it would be an interesting problem to figure out, given n nodes, with each node having a minimum of x and a maximum of y edges per node, and a maximum of z edges per path, what the minumum total set of edges would be to ensure that there exists a path between any two nodes.
I think a flat hierarchy necessitates 'adhocracy', but from a cultural and operational standpoint, I'd expect them to mutually reinforce each other quite well.
There are efficient network structures that are not hierarchical and are not trees. Trees have horrible single point of failure characteristics, where one bad node kills an entire branch.
To be fair, they also have the opposite quality wherein one great person can positively affect an entire tree. Many great companies have been built by a great leader positively affecting hundreds or thousands of people.
Does a young wolf always create conflict? For example, it is possible to avoid conflict and form a lot of influence by playing kingmaker. You do not need to sabotage others of similar technical abilities to you by attacking them directly, you can instead heavily exert yourself in producing massive value to their competitors. This is more stable as it's without conflict. It is the silent death to those that compete with you individually, and a way of finding allies.
Is that a young wolf, a social climber or a sponsor?
That's the way that things work in many political organizations like party committees.If you have the power to create kings, you have the power to destroy a king.
The key to any of this "flat organization" stuff is to keep the organization small enough that you can either keep out nasty personalities, or prevent them from burrowing into the org.
It's not a complete answer to your critique, and I don't have any experience working with stack-ranking, so I'm not sure the following is true. But: it seems like the worst problems of stack ranking might come from not having good people doing the ranking. In other words, it's a system that would be a complete disaster if used in a normal organization full of normal people. But Valve strives to be (and, I think it may be fairly said, is) neither. True?
Back in my days at Andersen Consulting, annual reviews were done by getting everyone at manager or higher level to assess everyone they had worked with over the preceding year and the nature and duration of the working relationship. This weighted your ranking. Within seniority levels, every person's scores were then calculated, sorted, and then assigned to one of five bands which determined raises.
This sounds a lot like stack ranking except it was top down. This was, by far, the best system I have ever seen for handling a difficult and often unpleasant process, and I think making it work across levels versus top down would only improve it. Incidentally, I only found out about this process once I made manager -- but I had consistently been in the top band for my entire time at AC despite having a senior colleague trying to screw me.
As Gore grew, it was apparent that this structure did not work with more than a couple of hundred people. So now, teams are limited to about 200 people (approximately Dunbar's number). I imagine Valve will run into this social limit as well once they grow well beyond their current 260 employees.
Given that Gore still exists, has 9000 employees and is profitable after 60 years is testament that such a structure can work for small as well as larger organisations over a longer period of time.
I first learned about this organisational structure in Malcolm Gladwell's book The Tipping Point. There are multiple descriptions online, here's one that seems interesting: http://ecgi.ssrn.com/delivery.php?ID=61902009302412510712411...