Management at Valve, as seen through the Valve Employee Handbook


The Valve Corporation is a Bellevue, Washington based company known for its award winning Half LifePortal, and Team Fortress games, as well as the extremely popular digital distribution service and multiplayer framework known as Steam. Valve employs a unique management structure based on little to no formal hierarchy, emergent order, and peer relations. Yet this structure demands an extremely specific type of employee, making hiring and firing a complex and burdensome affair. Despite that, it has amply demonstrated its enormous advantages, and should be examined by more software developers for good practices to emulate.

Exploring the Valve Employee Handbook

In 2012, Valve deliberately made its handbook for new employees public by uploading it to the Web. The company had long been secretive about its internal structure, with the best look inside coming from Michael Abrash’s blog post on his first days at Valve. Valve’s handbook is written in a casual and quirky style, yet it provides a fascinating look into the structure and day-to-day operations of one of the world’s most successful game developers.

Valve is a company with a totally flat hierarchy. While the company does have an owner, the CEO Gabe Newell, he takes pains to avoid interfering in the day-to-day management or even larger decisions. There are no managers, no centralized plans, and little in the way of formal positions. All employees are free to do whatever projects they find most interesting, and to form or dissolve groups as they see fit to pursue these projects.


Valve refers to its internal project groups as “cabals”, but these groups are not created by managers or other dedicated decision makers. Rather, they form spontaneously by employees agreeing to accomplish a common goal – often when they observe another employee working on an interesting project. Cabals are non-compulsory, and employees are encouraged to join and leave them as they see fit in order to provide the best benefit to the company and themselves.

Within cabals, employees can gain some level of management authority by adopting that role within the group, but the position is both non-explicit and temporary. An employee was was a manager in one cabal might end up being a programmer in the next depending on his skills and the project’s needs. In the end, the most important thing is to make productive use of your own skillset in whatever way seems best.

Peer Evaluation, Ownership, and Funding

Valve uses a stack ranking system inherited from Microsoft, in which employees periodically give performance evaluations for their teammates and adjusts compensation accordingly. These are then fed into a company-wide system, which determines the allocation of funds across projects. Disputes are adjudicated on a case-by-case basis, and are usually settled amicably. These evaluations are supplemented by repeated, anonymous peer reviews of each employee’s progress, as well as a culture which encourages repeatedly polling your peers for feedback on progress and ways to improve.

Valve is wholly owned by Gabe Newell, with no external capital to make demands on the company for higher returns, and Newell has demonstrated a repeated ability to avoid dictating the company’s direction from above. Valve also possesses a constant and huge revenue stream in the form of Steam, the dominant digital distribution system for PC games, which allows it to explore a variety of projects in its own time without fear of running low on funds.

Hiring and Firing without Hierarchy

Valve repeatedly emphasizes throughout their handbook the importance of hiring. Hiring is noted as the most important function in the company – and one that every employee takes part in. After all, with no dedicated jobs (like hiring manager) or managers (of departments like HR), there’s no particular group who could be relied on to hire new employees. Due to its unusual nature, Valve places extremely heavy emphasis on hiring employees who will fit into the company culture and actively contribute to its projects. The process is slow and deliberative, and employees are actively encouraged to comment and sit in on interviews to help determine if the new applicant meets their standards.

Valve never explicitly discusses firing procedures in the article, which is an interesting topic to skip. However, their in-house economist discussed the topic in an interview, and recent news about layoffs confirms that they do occasionally fire employees. Exploring these sources (and others) helps us build up a picture of why Valve is so careful when hiring new employees, and so evasive about how it fires underperforming ones – firing is extremely long and painful.

As a company with a flat structure, a critical consensus has to build before an individual is let go. This usually requires offering multiple opportunities for turning things around, including meetings and evaluations so that the employee in question can improve. Once the decision is made to terminate, there is no protocol or managerial authority to hide behind – the employee has been kicked out of the company by his peers, which even in the best case is likely to result in social tension. So Valve institutes a rigorous system of vetting potential employees to avoid the pain of firing them, their own model of employee management forcing them to ensure that every employee hired is also an effective manager of themselves and the company as a whole.


Despite these limitations, Valve is an enormously successful company with tremendous market dominance and a strong future. Their flat model clearly works, even if it requires an owner willing to allow employee management and a strong company culture. Some suggest that Valve can only function this way due to its extremely high profitability per employee, but this ignores that Valve’s flat structure was adopted long before it was successful. While exporting the entire model might be difficult, anyone interested in software management should look to Valve for an alternative model of management and organization.

Incentives Can Be Poisonous, So How Do We Fix Them?

In “Incentives Poison Extreme Programming Values”, Craig Innes explored the dangerous effect external incentives can have on the decision to use an Agile methodology, using the third year SDP project as an example of such a scenario. In this response, I intend to expand on his article by explaining why these incentives existed and how their goals can be met in a less damaging way. I will then generalize principles from this example that can apply to a variety of situations (work environment, assignment structure) in which authorities need to monitor or incentivize work, yet do not want to disrupt the Agile process.

Milestones, friendlies, and stack ranking: why were they used?

In order to understand how to improve SDP, we have to understand why the course implemented milestones, competitive friendlies, and zero-sum marking. Only then can we redesign the course to achieve the same ends without interfering with the Agile process.

The milestones in SDP primarily served as a way to measure the progress of student teams, but also as explicit short-term goals to aid team planning. Measuring the progress of teams not only allowed for intervention if progress was slow, but also allowed for a relatively standardized set of grading against an objective measure of success. The fixed goals also allowed teams of students who were new to major project planning to have some idea of what capabilities they should have at certain dates.

The competitive nature of friendlies was another incentive to ensure that teams took the opportunity seriously. If doing poorly meant a worse seeding in the final tournament, teams would be incentived to work at performing well at these events.

Finally, the competitive marking at milestones ensured that individuals did not freeride off of the group’s efforts, while at the same time it prevented the group from conspiring to give each other high marks. The limited number of high marks ensured that the group could not grant everyone an undeserved high score, and the resulting competition incentived denying freeriders a high mark.

In summary:

  • Milestones and competitive friendlies were meant to ensure that teams took their responsibilities seriously, and provide fixed, short-term goals for members to target.
  • Competitive marking was meant to both ensure individual effort, and defend against widespread mark-fixing within groups.

How do we fix it?

Milestones are a serious problem, as they are critical to measuring and maintaining the team’s progress. Yet this can be achieved, as Craig himself suggested in his reply to a comment, with group’s setting their own milestones. Each group has a mentor, a student who has previously taken SDP and who signs off on major decisions (such as allocation of marks), who could help the members of a group decide on a reasonable milestone to target next. Teams could then adjust their milestones to measure progress which is relevant to them – some teams may want the traditional feature-by-feature approach, while others might adopt a more Agile strategy of frequent, iterative releases. Either way, this approach would grant much more flexibility to teams, while retaining a grounded approach thanks to the mentor’s input.

The solution for competitive friendlies seems obvious enough – make them noncompetitive, or even end them all together! Tournament seeding can be random, and teams will have an existing incentive to take any opportunity to simulate the conditions of the final tournament seriously. Friendlies can either be organized by the course organizers as mandatory or encouraged matches with no stakes, or it can be left up the teams to organize their own friendlies.

Finally, zero-sum marking is both understandable (the organizers want to avoid collusion and freeriding) and deeply perverse (similar to Microsoft’s “Stack Ranking”, creates an environment of mistrust and hostility, incentives hoarding code and “low hanging fruit”). This problem is much harder to patch than the previous ones, as it is a symptom of a larger issue with a dissonance between the intent and practice of SDP. The easiest patch is to simply remove the limitation on high marks, and give more authority to mentors and the course organizers to review and modify the marks given. This does generate more work for those in charge of the course, but allows teams to focus directly on rewarding members as best makes sense to them.


While SDP’s milestones, competitive friendlies, and stack ranking seriously interfered with Agile approaches, they can be revised or eliminated in a way that allows for a variety of team methodologies. Even in an environment like SDP, which seeks to assign each student a grade to determine their grasp of the material, structures and incentives which undermine an Agile approach can be dealt with if the course organizers are willing to meet students halfway.

Video games are art, but we don’t code them like it.


Games are software-driven projects, that employ hundreds of developers to create a complex product for a competitive market. Yet the entire mindset of software developers in the game industry, including the development methodology they use, is not up to the task of grappling with the deep thematic and artistic consequences of the systems they construct.

Games as software: Large-scale and long-term?

Video games are big – really big. Not just in terms of the size of the industry, but also the scale of the projects delivered. Major releases are hugely complex software projects which take years to develop, and are expected to serve as the baseline for expansions to the original product as well as sequels that use the same components. Some games are intended to never end, virtual worlds that are constantly debugged, updated, and tweaked by the developers. Games also stretch horizontally across disciplines, bringing together dedicated game designers, programmers, musicians, artists (both concept and asset), voice actors, and support staff to try and produce a single, seamless work.

Despite their interdisciplinary nature, games have tended to be approached primarily as software development projects, which makes some sense given video game’s nature as software-driven projects. While the single highest cost continues to be art assets, much of the technology that powers the artist’s work is developed by the game’s programmers. And code is critically important to one of the key elements of any game – its mechanics.

Programming is a fifth of the budget, but much of the art budget goes to software development as well.

Mechanics as Code

Mechanics are the structures (usually systems of rules) the player experiences in his interaction with a game, and are what helps contextualize the contributions of all other disciplines. They are implemented by programmers in the game’s code, and further speak to the critical importance of software in tying games into a coherent whole. The critical community spills gallons of ink arguing about what mechanics are and how they should be used, but generally agrees that they are the benchmark for deciding if something qualifies as a game (this is ignoring the vocal contingent who are against defining games at all, in the interest of brevity).

For example, in a game about a square-jawed hero mowing down waves of horrifying demons, one of the major mechanics might be how input is translated into movement and shooting. In a game about leading a civilization from the first cities to modern history, there would need to be a mechanic to model technological change – and to allow the player some degree of influence over its progression. And in That Dragon, Cancer, there’s a mechanic for you to try to comfort your confused, weeping child as his cancer progressively worsens. That Dragon, Cancer also ensures that you can never succeed – that in the end, you’re always left listening to him sob desperately with nothing you can do to help.

Mechanics as Metaphor

As that last example makes clear, game’s mechanics are not just rope to tie the real, artistic components together – to some extent, *they* are the real component. The deliberate and designed interactivity unique to games arises from their mechanics, and the core elements of traditional media (such as narrative and art) are ultimately contained within one structure or another. Critical theorists within game studies have become increasingly interested in how the mechanics of games work to influence the overall artistic work, and how the mechanics can make their own artistic statements. Naomi Clark’s piece on Gone Home‘s use of mechanics, specifically the way it deliberately denies the player access to one they normally use freely, is a good example of the power mechanics have to make significant statements. Just as a character in a novel can be a significant sounding board for one of its themes, a game’s mechanics can be a powerful thematic device by deliberately including or excluding options.

In the end, mechanics are fundamentally tools of control, which often present an illusion of choice as a disguise for their real purpose: to constrain the player’s choices into carefully chosen vectors. In our demon shooting example, the player would probably be given a variety of different weapons to choose from – but no option to put his weapon down. The choice offered is fundamentally illusory, as each choice has in turn been deliberately included in the game so that the consequences can be properly programmed. The Tyranny of Choice is part of the latest round of debate on how much agency players truly have within this constrained structure, but that mechanics are as much a part of the game creator’s toolkit as narrative elements is clear enough.

Ludonarrative Dissonance: A break between mechanics and story

Ludonarrative Dissonance in Bioshock kicked off the debate about the thematic implications of mechanics, as well as introducing the term used to describe what happens when the themes of mechanics and narrative clash. Clint Hocking discusses how the game Bioshock, which by its narrative was ostensibly a critique of individualist Objectivism, was deeply weakened by the incredibly individually empowering nature of most of the game’s mechanics. Players are literally a one man army, able to tear their way through hordes of enemies – and this in a game which is purportedly attacking Ayn Rand’s vision of an independent hero figure! A mechanic which emphasized the need for community and mutual charity would be better, and would complement the game’s narrative instead of undermining it.

Yet despite this, games continue to pay little heed to their mechanic’s effect on the work – a fact that is making the critical community sharper with its comments. Bioshock was released five years ago, yet there is still little progress in trying to ensure that the mechanics a game has complement its artistic intent. Even smaller, independent titles are routinely criticized for ignoring the message sent by their core mechanics, and how it might clash with the purported message of the game’s writing.


Around this point, most readers are not only likely to be extremely patient but also rather confused – isn’t this an assignment for an Informatics course? Am I perhaps some Arts student, who accidentally posted his essay on the wrong course blog?

Stop being a software developer, start being an artist

So let’s bring it back to software design: I believe that the cause of this consistent and concerning inability to engage with the artistic nature and thematic consequences of a game’s mechanics originates (at least partially) from the developers of these mechanics themselves – the software developers and programmers who build them, usually using common software design principles. Susan O’Connor, a writer for video games, noted in an interview that “A lot of times, what ends up happening when you have a room of primarily tech-oriented [staff], it becomes like a software development environment”, and went on to decry the technically oriented thinking that many software designers who work in the games industry continue to hold on to.

Games are developed as software projects – yet they’re not at heart. They’re pieces of art, even if it’s often high budget, commercial art. The design and development of the game’s major and minor mechanics, as implemented in the game’s software, can have an incredibly important effect on the final result. Yet they continue to be approached as if they’re any other software project, where the design does not have to take into account the thematic implications of decisions but can instead be aimed towards a more objective goal. For example, unthinking application of HCI design principles has been critiqued harshly for effectively eliminating certain kinds of experience from the table – what if the goal of the game is to actually provoke frustration? Or to provide a challenge itself? Any interface which did so would violate the most basic tenets of good design, but might be absolutely critical to the intended message of the work. Approaching a game’s user interface like any other HCI problem fails to take into account that form may need to triumph over function when creating a deliberate, artistic experience.

“Just add art to the spec! We can get to it after we write the unit tests.”

So all we need to do is tweak our existing methodologies, right? Just add “ensure resonance with thematic and artistic intent of game” to our Waterfall requirements, or create a use case for the player’s experience of the theme, or keep it Agile so that we can quickly rework mechanics that feel wrong. Those are all good ideas, and more acknowledgement of the importance of these kind of aesthetic concerns couldn’t hurt, but the core of the problem remains. While composers and modellers who work on games acknowledge their role as artists, software developers continue to act as if they don’t need to adopt a similar approach. Software design methodologies are important to developing a game’s mechanics efficiently and on time, and should continue to be used. But by themselves they are incapable of mimicking the critical understanding and close reading that is required to grasp the artistic consequences of design decisions, let alone understand how to create an intended effect on the player.

Tabletop Games: From D&D, to FATE, to Fiasco

We can look to a similar medium to see how this might occur – tabletop role playing games. These are games played in person around a table, in which players follow a set of rules to act out their adventures. Early games, such as Dungeons & Dragons, often failed to treat their mechanics as anything other than conflict resolution and simulation mechanisms. Yet recent generations of tabletop games have increasingly used their own mechanics to reinforce the intended mood of the game, and as a result mechanics have tended to simplify – not only to enable better control over their exact effect, but also because the increasing understanding of the intended theme of a game enables unnecessary and overcomplicated systems to be stripped down or removed. Instead, each mechanic is deliberately developed with the intended effect in mind – conflict resolution by random elements  (such as dice) are introduced to games where the player is meant to feel particularly powerless or surprised, while group voting is used in games where negotiation and consensus is important to the setting.


On the other hand, the mechanics of tabletop games are far simpler than video games as a rule. Often, one or two people can develop an entire tabletop game, which makes a holistic approach much easier but is all but impossible for larger video games. What is needed is a software development methodology for games that looks to how writers write and painter paint for inspiration and seeks to encourage developers to embrace the artistic nature of their work. This could be a modification to an existing approach, but it can’t slot “ponder the artistic ramifications” as a step between coding and testing. Instead, consideration of the code’s effect on the mechanics has to be holistically and continuously assessed, and given as much weight as meeting more mundane requirements. Until this happens, developers are likely to continue ignoring the thematic consequences of their code, and mechanics will continue to ring against narrative.