Design at Valve: collaborating and innovating in a flat organization

Earlier this year, Valve released its handbook for new employees (PDF) to the world. The document provides a unique chance to understand Valve, where there are no bosses, no defined teams, and no top-down product prioritization. What’s it like to be a designer in this environment? How does Valve approach product design? We asked Christen Coomer, a designer at Valve, to help us answer these questions in this exclusive Design Staff interview. —John Zeratsky

John Zeratsky: Conventional wisdom says you need a strong leader who cares about design to make good products (with Steve Jobs as the trite example). Does Valve disprove that assumption, or does that kind of leadership come from within rather than from the top?

Christen Coomer: Valve approaches product design very differently from the rest of the industry, resulting in products that I think reflect different priorities.

First of all, we’ve designed our company in a way that allows us to focus exclusively on customers, rather than an executive’s vision or shareholders’ expectations. Design leadership at Valve takes the form of direct collaboration among a cross-disciplinary team of people who are all focused on the customer experience. It’s very decentralized. We optimize product design by hiring experts and enabling them to direct their own collaboration, exploration, trials, and failures; then learn and try again. And we engage customers in the conversation through playtesting, early betas, and frequent product updates, looking to customer feedback and data to inform our next steps.

Our design process really gets going once our products are in customers’ hands. We do our best work in this evolutionary way, where products take on lives of their own through continually evolving, and hopefully improving, services. This process isn’t about executing on a vision. Instead, we define goals, we test assumptions, and we’re continually surprising ourselves with where this leads us.

Our process really gets going once products are in customers’ hands. Products take on lives of their own and continually evolve — it’s not about executing on a vision.

JZ: This reminds me of something else I read in the handbook: “everyone is a designer.” What does that really mean? Obviously there’s a great emphasis on multi-disciplinary teams; in what ways is everyone a designer?

CC: When we hire for any position, we need to see evidence that a candidate has the ability to make good decisions on behalf of customers. This is critical given the way decision-making happens at Valve, where we’re all directly contributing to our products and services. Rather than introduce friction between employees and customers in the form of management, we foster a direct relationship, as it enables us to become more adept at serving customers.

We’re each shipping bits to customers on a regular basis, and in the process, making product design decisions. Should we build this? What are our goals? Who is this for? How should it work? When and how should it ship? When and how should we share and discuss it with customers? What should we do with their feedback? And how will we measure success?

Of course team members are heavily collaborating throughout the design process. We seek input from one another regularly, and we rely on one another to share opinions and challenge our assumptions. We avoid job titles, though, in part because they support assumptions that an individual who holds the title of say, “Designer,” is required to make a design decision, or even holds decision-making authority. This all demands a high degree of trust among us, which we’re able to rely upon given how carefully we hire.

JZ: How do teams assemble around projects? I’m particularly interested in how you assemble a team when people don’t have strict roles. (E.g. we need a visual designer to help with this; how do you find that person?)

CC: It’s everyone’s job at Valve to recruit peers to help ship an idea. If I’m unable to recruit an engineer to help me ship an idea, it probably means either the idea isn’t solving an important problem, or it’s just not timely given our current priorities and ongoing projects. As individual contributors, we’re each constantly asking ourselves “Where is my time best spent?” The answer changes as projects ship and as new opportunities emerge.

For these self-selecting project teams to work, it’s important that we keep up on the various efforts happening around the company. There’s no top-down communication, so this typically happens by chatting with one another over lunch, or checking in with people to learn what’s happening. To your example, there are two ways I might decide to contribute to a project as a designer: a need for design support is identified and I’m asked to contribute, or I spot a need for design support and talk with the group, then add myself to the team. If I’m too busy, yet I believe the project is a priority, I’ll ask around among the other designers, to find someone with the bandwidth and interest to contribute.

Each of our designers is capable of being the sole design contributor on any project. We don’t hire “visual designers” at Valve, instead we hire T-shaped people (PDF, page 32) who offer both a breadth and depth of skills, regardless of their core contribution. As designers, we contribute in a number of ways at every step of a release: planning, designing, testing, marketing and releasing products, then following up with customers to improve them.

JZ: Research shows that multi-disciplinary teams are the most innovative. Do you worry about single-disciplinary teams forming (“birds of a feather…”) or do multi-disciplinary teams form naturally?

CC: We certainly find that to be true; a single-disciplinary team usually isn’t well-positioned to ship value to customers. Teams form around projects, and as ideas take shape, members begin that internal recruitment process. What are our goals? Who do we need to accomplish them? There’s so much expertise to pull from, we all want to take advantage of that. No one oversees this process. Cross-disciplinary collaboration is just the straightest path we know to creating great products, so it happens organically.

JZ: The handbook talks about how valuable it is to learn how to code (or at least learn something about coding). How well do people take that advice? What’s been your experience as a designer learning to code? Do you code as a part of your job or is it extracurricular?

CC: It’s important that everyone contributing to the creation of software has a basic understanding of how it’s written, as this reveals so much about how software really works, what it can do, and what functions are cheap or expensive from a processing or authoring standpoint. We recently held a series of introductory classes in game programming, where a bunch of us non-developers created arcade-style games in C#. I learned how to create a particle system in that class; it was really satisfying to make that work. There’s no expectation that I go on to create particle systems for Valve’s games, of course, but I can certainly build on what I’ve learned and become a better design collaborator for it.

Right now I’m working on creating a new mode of Steam we’re calling Big Picture, which is designed to run as a full-screen TV experience. As part of that project, we defined our own front-end development platform, and we’re now using it to design Big Picture. So I don’t write code, per se, but I do work in a system that’s effectively like XML and CSS to animate and render interfaces. I’m often designing and building UI elements at the same time — I can’t imagine giving up that flexibility to directly iterate.

I often design and build UI elements at the same time. I can’t imagine giving up that flexibility.

JZ: Who do you go to for advice, feedback, etc, and how hard was it to find those people within Valve?

CC: There’s definitely a period of adjustment when joining Valve, as there’s so much to learn as you’re trying to make yourself useful. As you’re adjusting to a culture that lacks formal structure and communication, you’re pulling and absorbing information from people as best you can. After a period of time though, you come to know who’s an expert at what, making it easy to pinpoint your source. When you don’t know, the person sitting next to you usually does, or maybe that guy is in the room and interjects as you’re having a discussion. Sometimes the best feedback comes from a random source, though, so we often review our work with whomever stops by.