Annotations
QUOTE
A fearless adventure in knowing what to do when no one’s there telling you what to do
My rationale for annotating another company’s handbook is to demonstrate that Valve’s flat organization structure does not exist in isolation. It is one piece in a broader system of culture, expectations, and processes. Without those pillars, Valve’s structure — and yours, if you’re seeking to cut out the middleman(ager) — is untenable.
It starts here: the first line that a new Valve employee will see. A declaration of how an individual is expected to see a flat environment — an adventure — and how they’ll be expected to act.
QUOTE
This handbook does not constitute an employment contract or binding policy and is subject to change at any time. Either Valve or an employee can terminate the employment relationship at any time, with or without cause, with or without notice. Employment with Valve is at-will, and nothing in this handbook will alter that status.
An aside before diving in — the fact that this is placed before any actual content is absolutely hilarious to me.
You will now be embarking on the adventure of your life!*
*all adventures may be subject to your at-will employment contract
I’d love to know if Valve’s in-house counsel received any writing contracts on Portal 2’s corpo-optimist language.
QUOTE
Welcome to Flatland
Alright — here we go! “Flatland” is a term I’ve seen tossed around a bit — let’s dig into what it actually means.
QUOTE
But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, t alented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish.
The use of “entertainment company” holds some weight, here. Historically, productions for creative works are short-lived, borderline ephemeral — it’s unusual to retain talent after a project has been completed. This pattern has, since 2012 (when the first edition of the handbook was made publicly available), become commonplace in the games industry, where it isn’t uncommon to see a team get laid off after a release — regardless of the release’s success.
From Gabe Newell:
QUOTE
One of the lessons we had taken away from Microsoft was that no matter how good you are as a set of individuals, after you’ve worked together through multiple shipping iterations, you’re adding more value to the underlying capabilities of the people on the team. The more stable you can keep those high-performing teams, the better.
To this day, we’re startled by how Hollywood creates and destroys their production teams multiple times over the course of making a film, which to us just seems like madness when we know that working together only improves over time. So the key question was how to find these incredibly talented people, convince them to come, and then convince them to stay together over time.
QUOTE
A flat structure removes every organizational barrier
Posting the diagram here at the correct orientation, for clarity:
Not totally certain who Chet is — poor fella.
QUOTE
Any time you interview a potential hire, you need to ask yourself not only if they’re talented or collaborative but also if they’re capable of literally running this company, because they will be.
Here, we have the first nail in the don’t-shitcan-your-management-too-quick coffin. Everything supporting the ability to maintain this structure starts, fundamentally, at the ingest point. Are you hiring people with the ability to self-manage?
Keep this in mind when you see something like Amazon culling off hundreds of L3-L6 employees, gutting their middle management in an attempt at “gaining efficiency.” I don’t work there, nor do I know anybody impacted by this. They certainly employ more qualified economists than myself.
However, you might imagine a situation where Amazon doesn’t have this ingest-point culture. If you gut the middle of your company and are left with LLMs, L1-2 employees, and a bunch of L6 managers, chaos may ensue. Their calculation is “does this chaos lose us less money than we saved on management salaries.”
QUOTE
The fact that everyone is always moving around within the company makes people hard to find. That’s why we have http://user—check it out. We know where you are based on where your machine is plugged in, so use this site to see a map of where everyone is right now.
An intranet mapping system of physical devices in the office? Lemme shoot straight — that sounds cool as all hell, and I envy whoever got to make that.
QUOTE
We’ve heard that other companies have people allocate a percentage of their time to self- directed projects. At Valve, that percentage is 100.
Another example of how, in the spectrum of management decisions, Valve lies on an extreme libertarian end — which is why it’s important to critically evaluate how it actually works for them.
QUOTE
Strong projects are ones in which people can see demonstrated value; they staff up easily. This means there are any number of internal recruiting efforts constantly under way.
This does, in some regard, reflect the economics of open-source projects. Nobody has to help with an OSS project — they choose to.
You can imagine a general, global market of open-source talent: engineers who are willing to dedicate their free time to a software project. If you are the maintainer of an OSS project, then, your job is not just to build the thing — it’s also to sell it, not just to users but also to the engineers making decisions on how to spend their time.
QUOTE
(In fact, at times you’re going to wish for the luxury of having just one person telling you what they think you should do, rather than hundreds.)
Aaaaand there’s the inversion!
Think about it this way: in a traditional manager-agent setup, you have the process of:
- Manager delegates task to agent what to do
- Agent does it, reports back to manager
- Manager updates state of a project according to all agent updates, and delegates out new tasks
There’s a centralized planning, there. However, in this model, it’s:
- A hundred pseudo-managers — project or product “owners” — pitching what they need done
- The agent decides on which sounds the best
- A relationship is formed between the agent and their chosen pseudo-manager.
QUOTE
Got an idea for how Valve could change how we internally broadcast project/company status? Great. Do it. In the meantime, the chair next to anyone’s desk is always open, so plant yourself in it often.
The other implication of this structure is that you effectively have two “hiring” phases — the initial one to get in the door, and then a constantly-looping re-hiring as you wander.
This isn’t exclusive to Valve — anybody who has worked towards a promotion knows that it, too, is effectively being re-hired for a new role at your own company. It just takes a different form, here.
QUOTE
Specifi-cally, if we’re not careful, these traits can cause us to race back and forth between short-term opportunities and threats, being responsive rather than proactive. So our lack of a traditional structure comes with an important responsibility. It’s up to all of us to spend effort focusing on what we think the long-term goals of the com-pany should be.
This, along with the rest of this section, does address what Evolutions and Revolutions addresses in the Phase 1 (Creativity) stage of organization:
- You have a lot of people who are excited to be working here, and cover a lot of ground to get tasks done; but
- There can be a tendency to slip into reactivity, not proactivity.
QUOTE
Accepted truisms about sales, marketing, regionality, sea-sonality, the Internet, purchasing behavior, game design, economics, and recruiting, etc., have proven wrong surpris-ingly often. So we have learned that when we take nearly any action, it’s best to do so in a way that we can measure, predict outcomes, and analyze results.
And here’s the second pillar: systems.
Valve is, effectively, setting up a free-market labor system within their own company. However, free markets do not work without feedback, and feedback requires data. This is likely one of the biggest difference between Valve and another Phase 1, creativity-based organization: their systems are more mature than you’d see at some startup.
QUOTE
A process that many assume must be treated only as a “soft” art because it has to do with humans, personalities, language, and nuance, actually has ample room for a healthy dose of science. We’re not turning the whole thing over to robots just yet though(see “Hiring ,” on page 43).
People problems are the hardest engineering problems — but they can still be engineering problems.
QUOTE
- Start working on it, or (2) Start talking to all the people who you think might be working on it already and find out how to best be valuable. You will be welcomed—there is no approval process or red tape involved. Quite the opposite—it’s your job to insert yourself wherever you think you should be
I do like this. On first glance, it feels like it’d be a red flag to establish a culture of “Just insert yourself wherever.” However, this isn’t advocating for people to simply insert themselves — it’s a call to either a) gather enough information about a project you want to join, in order to make accurate contributions, or b) simply start working on it.
This relates, tangentially, to Programming as Theory Building — you either need to develop a theory for a new project well enough to recruit others, or ask and learn enough about the theory of an existing project to know, accurately, how your talent can fit into it.
QUOTE
Cabals are really just multidisciplinary project teams. We’ve self- organized into these largely temporary groups since the early days of Valve. They exist to get a product or large feature shipped.
Here, we start getting into the reality of the situation: Valve’s structure is not actually flat.
Well — it is, and it isn’t. “Flat” really isn’t describing the actual, material structure of their organization: it’s describing a lack of top-down enforcement. It’s more of a general philosophy — that the structures should form naturally, rather than by mandate — than a material, graphical description.
We have, then, the first superstructure: cabals, which any other company would call a project or product team. This is a valuable distinction! One of the two structural decisions a company can make is whether to form teams by discipline, or by product:
- Discipline means having a team based on what their focus is — backend, frontend, devops, etc.
- Product means having a team based on what they’re making — an app, an internal library, a product, etc.
This isn’t quite a higher-order mandate to new employees, but it is undeniably prescriptive: “When we hired you, we may not have hired you for a specific product team, but we did hire you to be on some product team.”
QUOTE
Often, someone will emerge as the “lead” for a project. This person’s role is not a traditional managerial one. Most often, they’re primarily a clearinghouse of informa-tion. They’re keeping the whole project in their head at once so that people can use them as a resource to check decisions against. The leads serve the team, while acting as centers for the teams.
Here we are! Back at Programming at Theory Building. All roads lead to Rome, right?
The second bit of prescriptive hierarchy: there are teams, and those teams have leads. In terms Naur might use: the job of a team lead is to keep the theory of the product in their head, and keep the product focused, clean, and pure to its ambitions.
QUOTE
they can and often do have clarity around the definition of their “job” on any given day. They, along with their peers, effectively create a job description that fits the group’s goals.
I’ll be honest — part of the reason I’ve cracked open the Valve handbook is because “We’re like Valve!” can, occasionally, feel like a shorthand for “We’re not organized!” This feels like a bastardization of the effort required to maintain a free-wheeling structure like this one.
It’s also meant to address some of the feedback I’ve gotten from peers when voicing frustration at the lack of organization and clear-cut responsibilities: “Just stick to your job description!”
They feel like two sides of a similarly disingenuous coin. I see my job as an engineer as generally solving problems — that ambition is not limited to a narrow set of job responsibilities. If I need to solve a problem, but solving that problem is not explicitly laid out in my responsibilities? I’m still gonna fix the fuckin’ problem. Not fixing a problem because of some piece of paper is an entirely unhelpful form of malicious compliance, and when I see people rationalize inaction in that way, I do think a bit less of them.
BUT! It is very important to recognize that there are right and wrong ways to solve a problem. The systems we design, and work in, dictate whether or not a solution is right or wrong, even if it does solve the problem. The issue with a lack of organization is that it can often lead to solving the right problems in the wrong way — ways that may not play well with other long-term goals, or that are not maintainable.
QUOTE
either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers.
Another very important callback to Evolutions & Revolutions. In that text, it specifically addresses organizations that are too stuck-in-their-ways to change, which hinders the ability to revolve into a structure that best fits their goals, or best reacts to changes in their market.
This details the subtlety of the philosophy that “flat-org”-ers can miss: that structure should not be flat — it should be adaptable.
QUOTE
rent-seeking
Oh, hell yeah — get their asses, in-house economist.
Worth noting: the first edition of this handbook was released when Valve’s in-house economist was Yanis Varoufakis, who later went on to be Greece’s Minister of Finance in 2015, where he was tasked with renegotiating debt and winding down austerity measures brought on by the Greek financial crisis.
QUOTE
Dina loves to force people to take vacations, so you can make her your first stop.
Who is Dina, and how can I ask them to force me to take a vacation?
QUOTE
All these things are here for you to actually use. And don’t worry that somebody’s going to judge you for taking advantage of it—relax! And 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 start-up. If we ever institute caviar-catered lunches, though, then maybe something’s wrong. Definitely panic if there’s caviar.
Oh, to be an engineer in the 2010s.
QUOTE
Nobody has ever been fired at Valve for making a mistake. It wouldn’t make sense for us to operate that way. Providing the freedom to fail is an important trait of the company—we couldn’t expect so much of individuals if we also penal-ized people for errors. Even expensive mistakes, or ones which result in a very public failure, are genuinely looked at as opportunities to learn. We can always repair the mistake or make up for it
This is tangentially related, but is absolutely worth noting: Valve has been notably absent from the 2020s increased layoffs and downsizing in the tech industry. Their last round of layoffs was in 2019, and focused on their VR hardware vertical.
This was not entirely unexpected: a 2014 Harvard Business Review case study focused specifically on how their organization structure could extend to hardware, a field where there’s far more rigid capital investment than software.
Since then Valve has moved towards more mobile and HTPC focus, releasing the Steam Deck with quite a bit of success and currently touting a release for a new HTPC, the Steam Machine, a controller reminiscent of the Steam Deck, and — ope! — the Steam Frame, a new VR headset.
QUOTE
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.
Back to the second pillar: strong systems.
Mistakes happen — more mistakes happen when there is less data to work with. My personal philosophy is that the first time a mistake happens, it’s a systemic failure. Maybe there wasn’t enough data, producing a blind spot. Maybe there was a lesson to be learned that could occur only after the mistake happened.
As per Programming as Theory Building, it’s surprisingly hard to codify mistakes and their solutions in a way that remains in long-term recollection. That is a distinguishing feature between book smarts — reading to learn — and street smarts — doing to learn.
This is also an issue with AI agents. Short of a couple odds-and-ends smoke-and-mirrors around “memory” (read: files. what a concept.), AI agents are currently the antithesis to Valve’s keep-talent-around: they start each session with virtually zero knowledge. They don’t know what mistakes have been made. They don’t retain lessons long-term.
This is not a knock against them — it’s a knock against human-designed systems that do not do their best to catalog, maintain, and make accessible previous lessons.
QUOTE
Over time, we have learned that our collective ability to meet challenges, take advantage of opportunity, and respond to threats is far greater when the responsibility for doing so is distributed as widely as possible. Namely, to every individual at the company.
The jelly bean approach to corporate governance.
QUOTE
We have two formalized methods of evaluating each other: peer reviews and stack ranking. Peer reviews are done in order to give each other useful feedback on how to best grow as individual contributors. Stack ranking is done primarily as a method of adjusting compensation. Both processes are driven by information gathered from each other—your peers
I consider this to be an extension of the systems pillar. It’s another prescription: in order for this system to work, each individual needs to have candid feedback from peers. The stack ranking is interesting — if it means what I think it means, I’m going to fucking love this section.
QUOTE
Each project/product group is asked to rank its own members. (People are not asked to rank themselves, so we split groups into parts, and then each part ranks people other than themselves.) The ranking itself is based on the following four metrics:
This is such a fucking cool way to do this. Even without nitty-gritty details, compensation calculation is straightforward in broad strokes:
- What projects is a person contributing to? and;
- What are those projects’ monetary value; and
- How much do they contribute to those projects?
It then becomes a matter of answering: given the projects they’re on, and their stack ranking within those projects — how much money are they generating, and how much should they be paid?
This has a few free market-style implications on incentives. The top of the handbook says that you’re free to work on whatever you want, based on the pitches that you’ve received — but the quiet part, here, is that there is a financial incentive to what you pick. Let’s say you have two options: working on an obscure internal library that generates no revenue, or working on the Steam store page, which generates… basically their whole revenue. If your compensation will depend on the monetary value of your contributions, which would you pick?
This also poses an interesting question about how C-Suite executives at Valve could potentially put their thumbs on the scales — and also why they even needed an in-house economist in 2012. Earlier, they talk about long-term strategies versus short-term gains. A bounty mechanism — a from-the-top subtle financial incentive to work on less directly-revenue-contributing internal projects that are more important for the long-term strategy — would be such an interesting problem to work on.
QUOTE
By now it’s obvious that roles at Valve are fluid. Tradition-ally at Valve, nobody has an actual title. This is by design, to remove organizational constraints. Instead we have things we call ourselves, for convenience
Regardless of whether or not an organization tries to take on Valve’s full set of philosophical values around organization, this is one of the nice things about working at companies where your work covers a lot of ground — they’re not particularly picky about what you call yourself.
I’ll be honest — I’ve been pretty liberal about what I put on my resume, or what I tell people, depending on the… conversation? context? hour of the day? The “I just try to solve problems” career philosophy opens up a lot of perfectly valid ways to describe my job or career in shorthand — backend engineer, developer experience tooling engineer, data engineer, etc — and I’d consider it to be a very fulfilling part of what I do.
QUOTE
s in, writing code. If your expertise is not in writing code, then every bit of energy you put into understanding the code-writing part of making software is to your (and Valve’s) benefit. You don’t need to become an engineer, and there’s nothing that says an engineer is more valuable than you. But broadening your awareness in a highly technical direction is never a bad thing. It’ll either increase the quality or quantity of bits you can put “into boxes,” which means affecting customers more, which means you’re valuable.
This is, from my vantage, one of the best promises of LLMs — the same promise that I’ve seen freak out some software engineers, admittedly. That was my whole point in reading and annotating Programming as Theory Building — while reading and writing code is valuable for anybody who works with computers, the distinction is that an engineer focuses on the theory while other occupations focus on the utility.
QUOTE
One thing that’s changing as we grow is that we’re not great at disseminating information to everyone anymore
I’ll be digging into this section hard. I think that every software engineering company is running into this issue, now, because of LLM agents.
Specifically — I think that a lot of companies’ communication infrastructure has proven lacking. When you begin working with agents, you’re effectively:
- Adding a bunch of new virtual intern developers; that
- You have to rehire multiple times every day.
It also pushes up the current engineering cohort into a managerial position, which makes coordination and communication harder. How can two engineers properly coordinate what their squads of interns got up to? When you’re working faster, how can you ensure you’re not also creating problems faster?
QUOTE
Hiring well is the most important thing in the universe. Nothing else comes close. It’s more important than breath-ing. So when you’re working on hiring—participating in an interview loop or innovating in the general area of recruiting—everything else you could be doing is stupid and should be ignored!
Alright — now we’re digging into the hiring pillar!
QUOTE
We value “T-shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow disci-pline—the vertical leg of the T)
This is one of the other things that I’m interested in the deeper theory, on — the original, from-the-source definition of T-shaped people.
Now that I’m typing it out, I realized that this term may or may not come from Valve — that’s worthy of some extra digging. However, I often find it in close association with Valve.
QUOTE
A generalist who doesn’t go deep enough in a single area ends up on the margins, not really contributing as an individual.
Woof. I tend to describe myself as a generalist — I suppose this is something to watch out for.
QUOTE
A: Well, it’s really hard. Mainly because, from day one, it requires a commitment to hiring in a way that’s very different from the way most companies hire. It also requires the discipline to make the design of the company more important than any one short-term business goal. And it requires a great deal of freedom from outside pressure—being self-funded was key. And having a founder who was confident enough to build this kind of place is rare, indeed.Another reason that it’s hard to run a company this way is that it requires vigilance. It’s a one-way trip if the core values change, and maintaining them requires the full commitment of everyone— especially those who’ve been here the longest. For “senior” people at most companies, accumulating more power and/or money over time happens by adopting a more hierarchical culture.
Ah, they do state the quiet part out loud! This structure requires from-the-start commitment, it requires long-term maintenance, and it’s highly contextual.
QUOTE
The design of the company has some downsides. We usu-ally think they’re worth the cost, but it’s worth noting that there are a number of things we wish we were better at:
I may do some extra digging. This book was written 14 years ago, now, which now makes Valve twice as old now as it was then. The hardware case study from HBR is what brought me here — I would be genuinely curious to see what resources exist now on what solutions went, or still go, into solving these problems.
QUOTE
WFH—Working From Home. What to do if a single snowflake falls out of the sky.
Huh — ahead of the curve, there
I’ll fully admit: this seems out of left field. I’m not an employee at Valve — I think I applied there once out of college, to no response — but among engineers, Valve has a somewhat mythic status as a company with an unorthodox approach to management: simply don’t manage.
This annotation relates specifically to Evolutions and Revolutions as Organizations Grow, which pertains to general management structures across companies, in general. The entire field of management research is an investigation into how best to coordinate human efforts and enterprise, and there are many solutions across that spectrum that work well. Take a look at two successful companies, and you’d certainly find differences in their organizational — sometimes subtle, sometimes not, but certainly there.
However, it’s obvious that Valve’s solution to management (“simply don’t manage”) is novel, to say the least. I’ve seen it hailed in a few places, now, of the potential for decentralized teams. It’s no secret that tech companies have spent the last few years “flattening” their hierarchies, specifically trimming out mid-level management.
However, it has to be appreciated that Valve’s solution is not to simply not have managers. If you, running your current company, think that you can flatten your organizational hierarchy for efficiency by shitcanning the entire middle management of your company, close your laptop, and come back tomorrow to an efficient paradise? You’ve got another thing coming.