Valve produced a handbook for new employees at the start of 2012. It’s surprisingly gripping reading, for an employee handbook, and also features some of Valve’s trademark humor:
If you stop on the way back from your massage to play darts or work out in the Valve gym or whatever, it’s not a sign that this place is going to come crumbling down like some 1999-era dot-com startup. If we ever institute caviar-catered lunches, though, then maybe something’s wrong. Definitely panic if there’s caviar.
I wouldn’t be surprised if Wolpaw, Faliszek or other writerly types had a hand in its creation.
I’d like to briefly discuss some of the benefits I perceive in Valve’s approach, and to that end I’ll endeavor to paraphrase some of the most important ideas I took away from the document. The discussion of the “cabal” system, in particular, is relevant to anyone thinking about running a game development team:
- In cabals, design is multi-disciplinary; ‘everyone is a designer’. This has massive knock-on benefits for doing technically feasible and innovative things from the get-go, making use of the expert knowledge of artists, programmers, narrative designers, audio designers, et cetera from the outset, and getting more original and refined ideas by blending disciplines. It’s similar to scrums in that every cabal should have a member of every discipline.
- Design is taken seriously, as opposed to feeling like ‘we’re not doing any work’ if we’re designing instead of implementing. Spending 2 solid days just meeting all day and designing opens up a wider field of ideas and offers more time to look at longer-term effects.
- A lack of top-down design directives means that poor ideas can be shot down by a larger group (avoiding resentment of authority figures, either for shooting down someone’s poor ideas, or even for suggesting them and subsequently forcing bad ideas through), while better ideas can rise upward instead of being suppressed by a higher-ranked ‘vision holder’.
- The iterative nature of cabals, in which intensive design is done followed by a quick prototyping phase, then the cycle repeats, allows ideas to be tested. As long as lessons are learnt from each test, unworkable ideas are never wasted, since they quickly lead to improved approaches (finding the fun/usability/profit) without sinking weeks or months into a bad idea committed to after a single early design session. Thus ‘bad idea’ comes to mean ‘unworkable idea’. Assuming that employees are talented and smart, their ideas are of a sufficient caliber that you should rarely be able to predict whether an idea is ‘bad’ (unworkable) until it’s tested — they aren’t putting forward many ideas which are completely meritless.
- The regular swapping out of cabal members means that everyone has a voice; no one gets burnt out; and rigid, self-limiting patterns of who is expected to contribute in what way in a given group are not allowed to solidify.
- Using the ‘lead’ position in this process means holding all the knowledge about the project, as opposed to all the power about its direction. Theories and desires are tested based on what the group thinks might work, and then when something does work, the group agrees to proceed in that way. The Lead becomes more of a project management position, temporary based on the given cabal, who holds the knowledge about what everyone is doing, what’s been discussed, what’s up to try next, and when tie-breaker or tough decisions need to be made, they can step in. This is based on the principle that no one can be expected to have great ideas all the time, and it’s far more productive to put your eggs in multiple baskets and then keep the ones that hatch.
What do you think about the benefits and risks of the cabal system?
Personally, I think Valve’s results speak for themselves — but let’s remember that these days, they have a towering pile of money with which to fund their projects. The biggest risk to their employees is that the pile of money might fall over and crush them when they’re pulling out funding for a new game.