Four Excerpts from the Valve Employee Handbook That Belong In Yours

A link to the Valve Employee Handbook made it to front page of Hacker News recently and I can see why, it makes for very interesting reading.

Four Excerpts from the Valve Employee Handbook
That Belong in Yours

Here are four excerpts you should consider for your company’s employee handbook:

“This company is yours to steer–toward opportunities and away from risks.”
Valve Employee Handbook (first edition 2012)

This recognizes a reality that echoes Kevin Kelly’s “we are all steering.” I sometimes encounter entrepreneurs who want to hire (or have hired) employees who are waiting to be told what to do; it’s amazing how little leverage this model affords a business. It may be necessary for a junior new hire but Valve’s model undoubtedly unleashes a lot more creative energy and insight.

“We are all stewards of our long-term relationship with our customers. ”
Valve Employee Handbook (first edition 2012)

In his 2011 analysis of where Cisco had failed to manage incentives, Larry Lang observed that a mature firm faces serious challenges in maintaining an employee focus on customer relationships when cultivating internal relationships is often a more reliable model for advancement and increased compensation. What is significant about Valve’s approach is that they trust everyone to interact with customers and feel responsibility for the relationship–it’s not just the job of the sales or marketing or customer service group.

Valve’s Design Process

“Everyone is a designer. Everyone can question each other’s work. ”
Valve Employee Handbook (first edition 2012)

Intel has a model for “constructive confrontation” as well; the risk is that it can encourage rude and destructive behavior. In his description of “The Cabal: Valve’s Design Process” (linked from the Handbook) Ken Birdwell outlines some lessons learned from the intense interactive group sessions:

Square Pegs: practically speaking, not everyone is suited for the kind of group design activity we performed in the Cabal, at least not initially. People with strong personalities, people with poor verbal skills, or people who just don’t like creating in a group setting shouldn’t be forced into it. We weighted our groups heavily toward people with a lot of group design experience, well ahead of game design experience. Even so, in the end almost everyone was in a Cabal of one sort or another, and as we got more comfortable with this process and started getting really good results it was easier to integrate the more reluctant members.

Smaller teams initially. For current projects, such as Team Fortress 2, the Cabal groups are made up of 12 or more people, and rarely fewer than eight. The meetings ended up being shorter, and they also ended up spreading ideas around a lot quicker, but I’m not sure I’d recommend that size of group initially.

Include an expert from every functional area (programming, art, and so on). Arguing over an issue that no one at the meeting actually understands is a sure way to waste everyone’s time.

Write down everything. Brainstorming is fine during the meetings, but unless it’s all written down, your best ideas will be forgotten within days. The goal is to end up with a document that captures as much as is reasonable about your game, and more importantly answers questions about what people need to work on.

Not all ideas are good. These include yours. If you have a “great idea” that everyone thinks is stupid, don’t push it. The others will also have stupid ideas. If you’re pushy about yours, they’ll be pushy about theirs and you’re just going to get into an impasse. If the idea is really good, maybe it’s just in the wrong place. Bring it up later.

Because Valve has no formal hierarchy, or has a fluid hierarchy, they need a process like cabals to act as a crucible for making sure that all of the relevant people have been consulted and a decision is quickly communicated widely. I think there are different process needs when you are in discovery or exploration mode vs. delivery or execution mode and the nature of questions or challenges need to align with needs of the project.

Make Predictions and Anticipate Nasty Outcomes

It helps to make predictions and anticipate nasty outcomes.
Ask yourself “what would I expect to see if I’m right?”
Ask yourself “what would I expect to see if I’m wrong?”
Then ask yourself “what do I see?”
If something totally unexpected happens, try to figure out why.

There are still some bad ways to fail. Repeating the same mistake over and over is one. Not listening to customers or peers before or after a failure is another. Never ignore the evidence; particularly when it says you’re wrong.

Valve Employee Handbook (first edition 2012)

I think this model for planning is the single more important take-away. You need to write down in advance what success, failure, and the boundaries of the expected are. In the middle as you are making the switch from discovery to delivery it’s easy to persevere needlessly or pivot endlessly or simply stall. Being clear about what constitutes a success that merits further investment, a failure that triggers plan B, and an anomaly that requires further study make it less likely you will lose your way.

Valve: How I Got Here, What It’s Like, and What I’m Doing

Michael Abrash posted “Valve: How I Got Here, What It’s Like, and What I’m Doing” on April 13, shedding more light on Valve’s model:

So Valve was designed as a company that would attract the sort of people capable of taking the initial creative step, leave them free to do creative work, and make them want to stay.
[…]
Trust is pervasive. All of Valve’s source code is available to anyone in Perforce, and anyone at Valve can sync up and modify anything. Anyone can just up and work on whatever they think is worth doing.
[…]
To be clear, Valve hasn’t magically repealed the realities of developing and shipping products. We’re all human, so teams sometimes argue (and sometimes passionately) about what to do and how to do it, but people are respectful of each other, and eventually get to a consensus that works. There are stresses and more rigid processes when products are close to shipping, especially when there are hard deadlines for console certification. Sometimes people or teams wander down paths that are clearly not working, and then it’s up to their peers to point that out and get them back on track.
[…]
Also, don’t think that people randomly come in every day and do whatever they feel like doing.
[…]
People commit to projects, and projects are self-organizing; there are leads, but they’re chosen by informal consensus, there’s no prestige or money attached to the label, and it’s only temporary – a lead is likely to be an individual contributor on their next project. Leads have no authority other than that everyone agrees it will help the project to have them doing coordination. Each project decides for itself about testing, check-in rules, how often to meet (not very), and what the goal is and when and how to get there. And each project is different.
[…]
It’s hard to believe it works, but it does. I think of it as being a lot like evolution – messy, with lots of inefficiencies that normal companies don’t have – but producing remarkable results, things that would never have seen the light of day under normal hierarchical management.
[…]
Valve’s long string of successes, many of them genuinely groundbreaking, is strong evidence that the hypothesis that creative people are the key to success is in fact correct, and that the structuring of Valve around those people has been successful.

M	T	W	T	F	S	S
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

Four Excerpts from the Valve Employee Handbook That Belong In Yours