Think Tank

Getting Real: An interview with Jason Fried

By Khoi Vinh

Periodically, I’ll hole myself up in a room and build a website as a personal project, working late on weeknights and all weekend, designing, coding and learning through rapid trial and error. This is the way that I first learned the medium, it’s the way that I often make the most strides in developing my skill set, and it’s also the method that has produced the results that I tend to be most proud of in retrospect.

But it’s not the way I make my living. This approach has long been considered anathema to my day job as a professional web developer. After a decade in this business at firms large and small—first at a momentarily high-flying, dot-com agency during the late 1990s, then as a founding partner of a design studio in New York City from 2001 through 2005, and now as the design director of NYTimes.com—the trend has always been to add more people, procedures, and documentation, not less.

Through the years, I’ve accepted the idea that, to build a serious, professional, and successful Web application, you need more of everything. You need to parcel out the various tasks among many specialists, you need to labor over extensive forms of documentation, and you need to set a long and deliberative trajectory with numerous milestones, all before producing anything that anyone can use, touch, or play with.

This plan first, build later approach is an effective way to win over clients and colleagues and convince stakeholders that everything will be done very carefully, and everyone will have his or her say in the matter. And yet, for all its benefits and for all the successful projects it’s produced, it’s rarely as satisfying as the projects on which I labored alone at a much smaller scale to produce a result with which I had a much more intimate connection.

About a year ago, I started reading and hearing more about an approach that, counter to common wisdom, insisted that it was in fact possible to build better web products with fewer people, that you could spend less time planning and more time building, that embracing limitations—the resources and people that you don’t have—produces the best end results.

The principal author and undisputed champion of this approach is Jason Fried, president of 37signals. Originally a boutique design studio founded in 1999 to build Web products on a for-hire basis, Fried has led 37signals through a startling transition over the past two years, transforming the seven-person company into a hugely influential publisher of subscription-based, web-hosted software. In the course of this change, Fried and his team have uncovered some basic truths about how organizations of all sizes work when they want to work more efficiently: They reduce the scale of their teams, and they build iteratively.

Fried and his company released a string of critically and commercially well-received applications: Basecamp, an online project management system, Backpack, an unorthodox personal information manager, and Campfire, a group-chat and collaboration tool for businesses, among others. Taken together, these applications share unmistakable common threads—a designer’s eye for detail; an unyielding adherence to simplicity; a sleek, unfussy efficiency; and a focus on clear, unambiguous usability—that have provided the template for a whole generation of web applications.

In the course of releasing these products, Fried has become an evangelist of his company’s novel approach to web development. Along with his team, he writes regularly on the topic at their popular blog, Signal v. Noise, and Fried makes frequent and closely watched appearances at industry conferences. The company has even offered its own seminars on the topic, with tickets priced at hundreds of dollars selling out in a matter of hours.

Interest in this approach has been steadily growing, and today Fried finds himself at the helm of what might almost be called a real movement in methodological thinking. Having dubbed it “Getting Real” because of its careful attention to avoiding abstract procedures and documentation, the company recently codified its central tenets in a book of the same name. Even the book was released in a manner typical of 37signals’ independent spirit: The 171-page publication was available only as a PDF download at a price of $19, and sold over 5,000 copies in its first three weeks.

Even for a commercially distributed book printed on real paper, those would be impressive numbers, but for a book distributed only from 37signals’ own website and in purely digital form, the figures are a clear signal of intense interest in a more efficient, less hierarchical approach to turning creative ideas into viable products. “Getting Real” represents a maturation in thinking about the way the Internet can be built; if not a turning point in our actual approach, then at least a milestone in the ongoing conversation about how to harness creativity. For some it’s a revelation, while others have labeled it unrealistic and didactic. Over instant messenger, I sat down with Fried to learn more about “Getting Real,” how it came about and how it works in practice.

An interview with Jason Fried

Can you give a brief overview of “Getting Real” for those unfamiliar with it?

Sure. Getting Real is the name of our methodology. It basically means getting rid of all the abstract stuff, and replacing it with the actual real stuff instead. So, instead of drawing boxes and arrows that represent a real screen, we just dive in and design the real screen. And tweak, iterate, and adjust.

How much of this methodology was the result of necessity and improvisation, and how much of it was the result of a conscious effort to improve the way you work?

It came from what felt right. In our previous lives as designers for hire, we used to go through lengthy processes, draw lots of abstract diagrams, spend lots of time on documentation. But what we realized was that that made the “process” better but it rarely made the product better. So we decided that we'd be better off staying as close to real for as long as possible during a project than approaching real towards the end. You never know what's real until you see real, and often times it's too late.

How did you come to that realization? Was it a particularly disastrous project that followed the “old method”?

It was a slow realization. At the end of every project we would be staring at these things we never looked at again. And then we kept saying, “If this stuff is so important, and we spend fifty percent-plus of our time on it, why do we forget about it later?” So we just started leapfrogging our process, leaving things out, and realizing that most of the busy work and charts and documentation just didn't matter. We kept shedding things and we enjoyed the work more, and when you enjoy the work more you produce better things. We optimized for happiness.

So we know it's a method that works for you. But have you seen this method work for other teams and companies, and if so, how closely have they mirrored your own experience?

I have, yes. A lot of people have been giving this a shot as of late, and people find it a far more rewarding and satisfying way of working. The folks at Firewheel Design released Blinksale using this method. Since we released our book we’ve been getting all sorts of emails from people who are beginning to put Getting Real into practice.

How about in Fortune 1000 environments?

There's a nice quote in our book from Sanaz Ahari, a friend at Microsoft that was involved with the Start.com site. They built on the fly, no specs, no big teams, just a lot of iterations. Our methods are definitely optimized for smaller teams, and smaller teams are one of the tenets of the Getting Real process. So there are plenty of small teams inside large companies that can benefit from this agile way of working.

There's an unspoken thread that suggests that, to make Getting Real work with just three people or so, one of them should be a David Heinemeier Hansson. Which is to say, it's helpful to have a programmer on your team who can create software as innovative as Ruby on Rails. What if you have a team of pretty good people, none of them brilliant? Does Getting Real apply? Is there a different trajectory?

Oh sure it does. Getting Real isn't about rock stars at all. It's about a few good generalists. We actually don't advocate building a small team of gurus. Instead we suggest a small team of people who are passionate, motivated, curious, and willing to learn. Sure, they have to have skills, but they don't need to be the best of the bunch. David isn't the best programmer around. I'm not the best designer around. We're all good at what we do, and we work well together. But we're not the best of the best.

But the team members should be multi-disciplinary?

Yes, absolutely, we don't advocate hiring specialists. It's better to have people that can roam. People who can move between the disciplines.

Yes, you state that an information architect, for example, doesn't make sense for a small team. Can you elaborate?

Sure. We don't think there's room for specialists on a small team. If you have four people, and one person can do only one thing really well, we think they're wasting space. You are better off with someone who can code HTML/CSS, design UI, structure information, and write copy. We think all of that is a designer's job. Not the job of four separate people.

Bigger teams afford more specialists, but they also increase overhead, muddle communication, and put up more walls. When one person has to toss something over the wall to someone else, and they have to toss it over another wall, and then yet another wall, things quickly get confused. It's like a game of telephone—the more people you have the more garbled the message gets by the end of the line. So we think it's better to find people who are good at a few things, not just great at one thing.

What about the tools you use, aside from the ones you're building for yourself. Is it essential that your collaboration tools are standardized in a small team like that? Or is it less crucial?

I think it's pretty important to have information centralized (which is what our products are about). I don't think it matters if one person uses BBEdit, another TextMate, and another Vim. What matters is that everyone can communicate clearly. We think project management and collaboration is about communication, not file formats, charts, graphs, reports, and statistics.

That's what's great about the web. It's the great standardizer (or, theoretically it is). Put something online and everyone can get to it in his or her own way.

And further, since we Get Real, our “deliverables” are real—they're HTML, they're copy that you can read, they're forms that you can fill out. We don't have to worry about whether someone has a specific program to open a specific type of file to take a look at a diagram somewhere. They just have to visit a URL and see the real thing.

So seeing the real thing is the key, irrespective of one's tools or location?

Yes, seeing and interacting with the real thing is the key. It's not about seeing, it's about using. You can see an Adobe® Photoshop® mockup of a site or application, but you can't use a Photoshop mockup. That's the point of Getting Real. To experience the real thing early and often. That's the best way to improve the real thing. You can improve a Photoshop mockup all day long, but your customers don't buy products or search or make a to-do list in a Photoshop mockup.

Following that specific example: Is there a tension between creating something real (moving beyond just sketching the end result) and maintaining a low “cost of change”? Do you do one sketch and then just start coding? Do you spend time exploring different directions?

We explore the directions in HTML/CSS. We almost always iterate in Real mode. There are times when we'll take a screenshot of the rendered HTML screen, paste it into Photoshop, and move a few things around quickly just to see what it would look like, but we try to stay in HTML as much as we can. I'd say over 90% of all the design explorations we do are in HTML.

We also sketch on paper a lot—much more than we go into a program like Photoshop. Paper is fast, cheap, and low resolution enough to get ideas out without having to worry about the details too early on. Worrying about details too early can kill you, and paper helps you skip the details.

In Photoshop you worry too much about pixels and alignment and colors. On paper you can get rough ideas out quickly without worrying about all the stuff that just doesn't matter yet.

Can you talk about how your team works remotely, especially with regard to methods like paper sketching? How important is it for new team members to be local?

37signals has seven people. Five of us are in Chicago, one of us is in Provo, UT, and one of us is in New York City. One of the five in Chicago was in Copenhagen, Denmark up until the end of 2005. Our feeling is you should hire the best people you can no matter where they are. Don't pass on the right fit because the right fit is 800 miles away.

There are plenty of ways to be close enough these days. In fact, we think close enough is better than too close. Too close leads to too many meetings, too much B.S.’ing, and too much wasted time. When people are apart they tend to get more work done because they aren't bothered as much. Bothering someone by walking over to their desk and just saying hi can really take someone out of their flow.

Now, that being said, this isn't for everyone. You have to have the right people for this. Motivation can be an issue with remote workers, so you do have to find the right fit.

Are you working long hours these days?

We all work as many hours as we feel like working. As long as the work gets done, that's all that matters. Sometimes we have to put in twelve-hour days. Sometimes six. But we definitely don't encourage people to work too much. That's not healthy for the people or the company. And last summer we experimented with four-day work weeks. Just as much work got done, plus everyone was happier since they got a little extra time off.

Optimizing for happiness.

Right, optimize for happiness. People do better work in an environment like that. And we don't count vacation days either. We just try to be fair with everyone so they're happy. No point in cracking the whip.

With a small team like that—with any small team—how important is it to form a personal bond outside of work tasks? How important is it to like the person you're working with?

It's very important to like the people you work with. Everyone has to understand and trust each other. We often say we'd rather have someone who's happy and decent over a frustrated and negative guru, and we mean it. Motivation and morale are so important if you want to do good work. Pissed off, frustrated people don't do good work. And that's one of the benefits of having some distance between everyone. It's harder to get sick of someone

At the New York Times, we certainly don't have a Microsoft-size crew of designers and developers, but we're clearly larger than 37signals. Since I've been there, I've been consciously and unconsciously applying a lot of your philosophy to developing new products. One thing that strikes me is that, when it's been most successful, the project and team have been set up in a kind of “pirate” operation. Which isn't to say rogue, but it's been set up around, again, someone who's been exceptionally talented at software development...

So the question is: Is this the only way to integrate your methodology into a big organization? Can a big organization ever fully integrate it except in pirate exceptions?

I can't really answer that because I don't have experience trying this within large organizations, but I would encourage large organizations to ask themselves why they are so large. Maybe they can be smaller. Maybe they can break up their teams into smaller teams. Maybe they can have more “rogue” units to get things done quicker.

The faster you know if something's going to work—or not work—the better off you are. No sense in wasting eight months if something's a bad idea. But you really don't know until you Get Real with it to find out.

Another thing I find interesting is that when big groups really want to get things done, they don't make the group bigger, they make the group smaller. For example, when Lockheed wanted to design the Stealth [bomber], they didn't scale up the team, they scaled the team down. When Congress really needs to consider something important, they form committees. When the military needs to conduct an operation with absolute precision, they usually call on the best small team they have. I think there's a lot corporate America can learn from that.

And I think it also begs the question: Why have small teams as exceptions? Why not make them the norm? If they do better work, and communicate more clearly, why not encourage more small teams?

What about in the cases of design studios who are providing design services to clients to build products—web apps, increasingly these days. Does Getting Real make sense as a methodology for consulting?

I believe it does, but it's certainly a harder sell. Clients often find comfort in process. They think getting their money's worth means a lot of deliverables, not just the right deliverable. So it's a tough sell, but it does work. I know some great designers who just dig in and start designing. And don't think too hard. Don't write too much. Don't promise ten pounds of paper. They just get going and see where it goes.

But yes, it's a challenge, but it's a good challenge. And remember, clients always want to see the real thing sooner. So showing them real progress sooner will build their confidence. And they'll trust you more as you move forward in the process. Each time you work with them it will be easier to skip the formalities and dive right into the real thing.

And what about 37signals—when you gave up client work, did you stop being a graphic design company and start being a software development company? Was there a noticeable shift of mindset?

Yeah—toward happiness. There's nothing quite as satisfying as building something for yourself. It's great to wake up and do something that you believe is right and letting the market decide rather than having a client or politics decide.

But I will say it's not for everyone. And it's not easy. But it's never been easier.