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.