Valve Handbook for New Employees (2012) [pdf] | Hacker News Reader

Valve Handbook for New Employees (2012) [pdf]

valvesoftware.com

42 pointsAudiophilip17 comments

Whenever this has come up in the past, on other forums, it's been speculated that Valve is so profitable that it can get away with more or less any management structure at all and hence doesn't really serve as strong evidence that this particular style really works well or not.

I think talent also plays a role. Profitable companies are capable of hiring poor talent. Valve hires the best, because they're both profitable and prestigious. A lot of smart, intrinsically motivated people may be able to find a way to organize themselves, regardless of management structure, whereas less talented employees may have different organizational needs.

Where I currently work (< 60 employees), management decided to try to switch to a flat structure similar to what is described in this handbook. We are still in the bootstrapping phase. However, I noticed that I could not find a lot of serious/deep evaluation material, like, companies that really did it and discussed it in retrospective, nor anything similar in management literature. Also, I noticed that there are no good sw tools that help you organizing, the standard SCRUM tools are not enough and instead we would like to have something that allows to easily keep track of who is working on what and how, let's say more about the connections between the "teams" than their progress. Any tips?

Look for literature on "lattice organizations". There are a few case studies published about WL Gore & Associates and how they implemented it.

I think if you're using elaborate software tools to do SCRUM, you're probably doing it wrong already.

I might be having an allergic reaction to the "burndown charts" that were used to micromanage people at Microsoft. But I also think that anything more complicated than a whiteboard and a wiki is over-doing the process.

Github also uses a flat structure. They don't have any official papers, but some of their employees have described their internal tools and workflows.

http://zachholman.com/talks

http://www.slideshare.net/InfoQ/github-communications-cultur...

http://tomayko.com/writings/adopt-an-open-source-process-con...

http://www.fastcolabs.com/3020181/open-company/inside-github...

Big discussion https://news.ycombinator.com/item?id=3871463

So HL³, for example, doesn't get shipped, because noone wants to work on it?

I was wondering the same thing. HL3 is possibly the most anticipated game ever, and so working on it surely involves a lot of pressure. Yet TF2 gets new updates all the time. I'm curious if Valve's structure helped lead to this.

I admire Valve, and think their approach is interesting, but I can't help but feel sometimes a little hierarchy is necessary to force the crummy stuff that needs to get done to get done.

When I work on my own I tend to do easy stuff more often than hard stuff.

So maybe because everyone likes TF2 and creating new content is easy, more teams tend to work on it.

I think that it doesn't just involve more pressure; it's just really difficult to make a game that could live up to the extremely high expectations people have. It takes time to come up with good ideas after all.

I completely agree with your point that a little hierarchy is necessary to get things that absolutely need to get done finished. On the other hand, as a developer I can also see how you wouldn't want to release something unless you are confident it'll be great. The difficulty is finding that balance, but given that they intentionally chose to stay private, it seems to make sense the company culture is to focus on the quality of the product.

I'll admit I kind of admire the freedom from time pressure they have.

No, HL3 should be built by a strong team, led by (and composed of) people who can't imagine doing anything else. Treating it as "crummy stuff" that someone needs to be forced to do will just result in a bad game. We can get bad games from any number of other publishers.

I didn't mean to correlate HL3 with "crummy", I was commenting on two separate things.

For example: I understand that Valve's Steam customer service is pretty hit or miss. Possibly a result of no one at Valve really wanting to own customer service.

If nobody wanted to work on it, yes, it'd not get shipped. That's why there's no Ricochet 2.

What good sources tell me that is happening at Valve is the curse of raising standards. HL2:E2 is much better than HL2 ever was, but it took forever to ship. Portal also raised the bar in many ways. So what they have in HL3 is a game that Valve employees have put so many high expectations on, that getting anything to a state that is good enough to ship is like pulling teeth. Let's also remember that HL3 runs on a different engine than everything else Valve has released in the last decade: Just the new version of Source, plus the updated toolsets to work in it, are a significant cost. It's not as if they are just licensing an engine built somewhere else and rolling with it.

I've been paralyzed by success before in my own projects. I can only imagine what that does to a big organization that has had as much success as Valve has, and that has so much income they don't really have release a game in the next 5 years to remain financially stable.

My (very unreliable) understanding is that part of starting up a new project at Valve is rallying people to your call. Imagine how hard it could be to get enough people to roll with a specific, concrete idea for HL3. The expectations are high enough that I imagine pretty much any vision for it will be contentious and divisive.

cold

Reply on news.ycombinator.com