Tom Preston Werner at Startup School 2012
Hi everyone! It's awesome to be back here. Was here in 2010, two years ago. Lots changed since then. I'm actually gonna put this on the ground. This is my timer. You see, part of being a founder of a company is solving your own problems.
So, I was thinking about this talk and what I would talk about; what the big questions would be for me about GitHub, where we've been, where we're going, what does it mean to start a company today. I figured most of you, and especially after watching Ben's talk, might be asking: how do I, as a budding entrepreneur, raise a hundred million dollars just like GitHub did? Maybe that's the question that you're wondering. Pretty much anywhere I go now, everyone says, "Hey Tom, how's it going? What are you gonna spend a hundred million dollars on?"
But this, I think, is the wrong question. I'm not actually going to tell you how to do that. I'm gonna tell you something different, and I think that's because at the end of the day, money isn't actually what matters. Money is irrelevant. What is money? Money is just a number in some bank's computer that says how many slides you can buy for your office, right? But that's not what we care about. That's not what we're trying to do here. We're not trying to just make more slides happen in the world.
So what does matter? I think what matters is not the money; it's other things. So let's think about this. I forgot my clicker; I need my clicker. This is gonna be less impactful if I don't have my thing. Okay, thank you, sir! All right, you guys are in for a treat.
Okay, now that I have this, let me make a positive statement for you guys: a company is nothing except the decisions that it makes. Decisions are made by people. Okay, with me so far? So the only thing that matters are people. People are the only thing that matters, and those people then had better be the right people.
So let me tell you about GitHub. In the very early days, GitHub was started by myself and my co-founder, Chris Wanstrath. Initially, there were two of us. What I did was the design, the front-end, the visual, and the UX. I also did the very back end, which is how Rails code accesses Git repositories on disk.
So I'm kind of this weird creature; I do the front-end stuff, and I do the back-end stuff. But I've been doing Rails for a long time. Before that, I didn't really like it. I really like Rails—you can tell the world I don't actually like Rails that much.
And so, being in the Ruby community and going to Ruby meetups, this is how I found my co-founder. Chris Wanstrath was very big into Rails. He had a blog post that outlined everything about how to be the best Rails developer you can be. Everything about it was amazing. I said, "This is a guy that I can start a company with because we have complementary skills. I'll do the front and back end; he'll do the middle part, and together we have the whole thing." And that worked out really well. We just started hacking on it as a side project.
But then, shortly thereafter—and here’s a little tidbit about how you can tell whether your startup idea is actually gaining traction—how can you tell if people enjoy it? One thing that was really effective for us was when people came to us—this is in the private beta phase—and they asked, "Can I pay for this?" We had no billing system, and yet they wanted to pay for it. They wanted to make sure that it would continue to exist, so that it would continue to solve their problems.
So if you have customers asking you to pay for your company's product before you can even sell it to them, that's a good sign. So in order to get this company to a place where people could actually buy it, we hired our third co-founder. He came on board just a few months after we had started, and his first thing was to build the billing system. This is PJ Hyatt.
So now we had two Rails guys, essentially, and me still doing front and back end. We're building out a better mix of people and skills to accomplish what we need to get done. Our first employee that we hired, Scott Chacon, is a Git expert. So we reached a level in the company where we kind of maxed out our Git knowledge. None of us were really Git experts, and yet we were building this site, GitHub, which is for hosting Git repositories.
So again, through meetups, we met Scott. We talked to him about product, about how he would go about building things, and he was the one that built Gist, which is the snippet-sharing site. He built that from scratch as his first task, bringing his Git knowledge into the equation.
So you can see we're assembling a broader diversity of people who can accomplish more things. We maxed out our Git knowledge; let's bring someone in that can augment that. And you'll notice that none of these people—none of the four of us—were business people. None of us had ever really gone into business all that much.
I'd done some consulting, but that doesn't really count. None of us had created large businesses. None of us had an MBA background or a business background like that. So none of us either were executives; none of us had this really broad experience in creating a company that you might, as a person starting out, think: "Well, how are we gonna solve this problem?"
Well, let's hire an executive because they know what they're doing. Now, you have two problems. Here's the thing: There are executives, and they're awesome great people, but they know so much—they know so much—that it can be detrimental, I think, to a startup where you're really trying to solve a new problem in a different way.
You have to come to problems with a beginner's mind. Right? Not knowing something can be a very powerful tool in accomplishing it because you don’t know that it’s not possible. That's what doing a startup is—not realizing that something is impossible and doing it anyway.
Something else that was a commonality between us—the people in GitHub in the earliest days—was having worked for bad companies before. Having worked in places where they did things wrong. Examples of how not to do something are just as good as examples of how to do something.
And I think this is what companies are for: companies solve problems. Great companies solve real problems. If you haven’t ever experienced problems, then how can you know what are the right ones to solve? So you're all here to do startups, to join startups, to create startups.
I think that if your options are creative startup or try to work for another company, going and working for other companies is not so bad because it gives you this really excellent perspective on things to not do, actually. So getting experience elsewhere? Not so bad, right? A lot of great people that start startups had a bunch of full-time jobs before that.
I had five full-time jobs before starting GitHub. So suffering can sometimes lead to a better product for having that information. Something that’s great with people is getting together. We would meet for beers all the time, and we talked over the problems that we had. We go to a bar called O'Reilly, up in North Beach, San Francisco, and we just talked through the big problems.
Right? People are very important. Having the same ideas for the product direction is important. Getting on the same page for that stuff is what's gonna allow you to push forward. If you find yourself in a situation where you're not getting along with your co-founders or the very small team that you've created to begin with, really step back and evaluate that problem, because I don't think you can push forward effectively if you're fighting each other.
Right? Look at that. You should be getting along. If you're not, really, really think about what that means. Hiring is hard; hiring the right people is incredibly hard. Sometimes you'll screw it up. We hired a sales person in the very early days, and we had to let him go because he wasn't the culture fit.
It was because we hadn't had experience with that kind of hiring before, and that's okay. You’re gonna screw up hiring. You have to be in a place mentally where you can fix that later on by letting someone go. It sucks; firing people is the worst! But if you're gonna start a company, you have to be the kind of person that can do that when it needs to get done.
And as your company matures and you go through these different phases, things are gonna change. Your role is going to drastically change over time. In the beginning, I described myself as the janitor. I was fixing things. Things always need to be fixed. I was always cleaning things up, fixing things, documenting things.
Things were going so fast that someone has to come back and fix things up every once in a while. I was the janitor! And this, I think, is why titles—especially in the beginning of a company—just throw all your titles away. Don’t even worry about it. Don’t bicker about who's gonna be the CEO, or the CTO, or the CFO—all that stuff is crap!
All that stuff is crap in the beginning. There's way too much to be done to specialize that early on. Things change a little bit when you get bigger; you start to specialize a little bit more.
And then it's really important to think from the early days, do you have the right mix of personality types? So for us, if I look at the different people who are in the company in the early days and why we've been able to stay together as a team—all four of us are still there today, five years later—I'm sort of the logical, pragmatic one of the group. Chris is more of the product visionary one. PJ is kind of a business operations-minded person, and Scott guards the culture and creates as much happiness as possible.
These are four sort of different vectors, and in having a discussion, all our decisions we would make by sitting down over beers and coming to a conclusion that was sort of in the middle. We would all check and balance each other, so think about when you're collecting the right people: do they have the right kind of mix to be effective in the long term, because that's what you're going for?
So always think about how every person can effectively push the company forward. If you're gonna hire someone, how are they gonna push the company forward? Because companies don't do things; people do things. And that's why people are all that matters.
And so I'm gonna have the audience help me for this real quick. I want everyone from here over to, on the count of three—so one, two, three—and then go read this off and say, "People are the only thing that matters." Okay, are you ready? One, two, three: "People are the only thing that matters!" Thank you! You're an excellent audience.
But wait! Customers don’t interact with people—not when you're building a product. So how can they be the most important thing? Product is actually the only thing that matters. Ah, things are getting interesting!
I think when you're thinking about your product, you need to start with design. It's how your customers interact with your products. It's what they see; it's what they feel. Think of it like an automobile. We all understand cars and trucks and things, right? This is your experience; this is what you're creating.
You're creating something that is like a vehicle. Vehicles, to us, make a lot of sense. They've been refined year over year for a large part of the last century, so they become very good. We all understand them. This is what you're going for: a product that feels so natural that it's like a car. You can just get in, you can drive it off; the steering wheel's here, this pedal makes you go, and this motor pedal makes you stop. That's the product.
And what you exclude from your product is just as important as what you include in your product. Take, for instance, Volkswagen—the bug that had the little flower vase. Right? What the hell was that? Now every time you get in your car, it smells like dead organic matter, and you wonder if Volkswagen, the company, is just the same thing: is this a dying company that's including these crazy things into their product? What you leave out is just as important.
Everything that you add makes everything else less important. So if you've got your awesome car, right? And you put that big spoiler on the back, then your neon ground effects aren't gonna be as awesome because people are distracted by the spoiler.
So think about that—everything that you add dilutes the entire product. Our designer, our first dedicated designer that we hired, Kyle Neath, has a very nice way of putting this: he says, "Focus over features." And I think that's a very important thing to remember, especially when you're early. You can't do everything, so the things that you do had better be awesome. They better be the right things and not diluted by just tacking on every possible thing that you can think of, thinking that users want just as many features as possible.
People want great products; not as many features as they want. If you screw up your design, then you screw up your product. So make sure that one of your co-founders is design-minded. For us, it was me.
If you're gonna do a startup and you're thinking about, "Okay, I'm a technical guy, and I'll hire my technical friends, and we'll start a company together," now you need a designer. Go find a designer. Someone who's gonna make your product something that customers want to use instead of stuff like the administrative screens of open source projects that we see today.
This is a big problem with open source: there’s not a lot of designers involved. That's not what you want your company to be like. Another thing is to think very much about your mission: what is the mission of your company?
And I think that you should be able to say your mission in one sentence and, in fact, probably in less than ten words. So for us, when GitHub started, our mission was very simple. In fact, it was on the website. Some of you might remember it said, "Git hosting: no longer a pain in the ass," because that was the core problem that we were trying to solve—make Git hosting really easy, so you can share code with your friends. It was a very simple mission.
Over time, once we got further down the road of accomplishing that, we started thinking more about developers as a whole: what do they need to do to be effective at creating software? It's more than just getting repositories online. Now it's about collaboration; it's about them working together.
And so we changed our mission. We stated it as, "Make developers' lives better every day." So we expanded the scope of what we were trying to solve. Then we started building internal tools for ourselves: things that are beneficial to creating a software business.
And we started thinking about things a little bit differently still. So we were going broader. We started saying, "We use GitHub to build GitHub," because it's more products than just GitHub.com—things like some things that you have seen, like the job site jobs at GitHub.com, things like just a bigger suite of products that can help you solve more problems.
And now the final vision that we have now is what we call, "Making it easier to work together than to work alone." You'll see that it’s completely divorced from software altogether. And so I will actually answer your question: what are we gonna do with the hundred million dollars?
It's that: how many people in the world use code? How many people in the world write code? Thirty million? Maybe forty, if you're lucky! How many people are there in the world? There's a lot more room to fix collaboration than just software.
But this took a long time to get to. We didn't start with this idea of fixing collaboration for the world; we started with the idea of getting a repository from your computer onto the internet. That was it.
So remember that when you're solving a problem: pick something that you can solve. Hopefully, there's a direction that you can go that becomes bigger, right? But choose something small in the beginning that you can actually solve.
If you bootstrap like we did and your product becomes popular, then you'll also be faced with a choice, which is: are we going to do this as a lifestyle business? Is our product going to be a lifestyle, very niche kind of thing, and yet it'll make your lives really good? You can live with that way—that's awesome! Lots of people do this; that's great.
But you'll also be faced with the choice: do we want to blow this out? Do we want to change the world? If people like your product, you've got a bunch of users—that's a choice that you will have to make.
I like to think about it like the TV show "Lost." How many of you have seen that show? Lots of you have seen that show, yes! I think the saddest thing in the world is a squandered opportunity, and that's what "Lost" was.
So that's the question: when you're faced with that choice, think about: what do you want to do with your life? What are we trying to accomplish? I think you're all here today to solve big problems, so maybe you've already made that choice. But you might have to make it for real down the road: don't squander an opportunity. Go for it! Don't be like "Lost."
For us, it was the decision to reinvest everything that we made in the company into the company instead of banking it out or putting it in our bank accounts. This is also why we raised a hundred million dollars: because GitHub is an opportunity. We don't want to squander it!
Don't worry too much about when you enter a market; almost every product in the world is terrible. Look at the list of products, the things that use it every day—most of them are just downright crap! If you know this—and this is something that Apple knows very well with devices like the iPad, right? How many tablet computers were there before the iPad? Dozens—all terrible!
Apple comes along and, through making a good product, day one—that's what product means, and that is why product is all that matters.
So, center section, on a count of three, please help me in saying this phrase: one, two, three: "Product is all that matters!"
But wait! Products only come into being when people make decisions, like we started with, and the best decisions are made according to a consistent philosophy. So philosophy is all that matters!
Philosophy derives from your people. At GitHub, we never set out to create a specific culture. The people that we hired created the culture. At some point, you might want to codify this culture that is inherently created through the people that you hire so that you can communicate it well.
Let me briefly explain what, to me, the five core values of GitHub are:
Number one: optimizing for happiness. If you want to learn more about that, watch my talk from two years ago. Optimizing for happiness means think about what you're doing and how it's going to create more happiness in the world for your customers, for your team members, and for your shareholders. If you do options like most startups do, then your team members are also your shareholders.
If you raise money, then your shareholders are part of that equation as well. If you do those things, if you optimize for happiness, my theory is that profits will result naturally, and it puts you on the right path to do things that matter.
Number two: best argument wins. This means that it's not about ego; it's not about who you are or where you came from. It's about making good arguments, backing them up, and being open to other people's arguments. This is critical to avoiding politics within a company. If you can argue about something that matters and the argument is the thing, and not the people behind it, then you can have good results. You can create good product, and you can avoid politics.
Number three: working from first principles. Everything that we do, we do from scratch. You might think this is very inefficient; sometimes it is. But we think through every problem that way because GitHub is a unique company, just like every company is unique.
You can't just take the ideas that work for some other company and apply them to yourself. And in fact, you can't take the ideas that I give you today or that anyone gives you today and just copy them and expect them to work for you. You have to think about what it means for your company. This is how you create something new, something better.
Number four: create superfans. Travis's talk about Uber and how they delight their users on certain holidays by giving them a motorcade—that’s the kind of stuff that I'm talking about. For us, we do drink-ups; it's like a meetup except at the bar, and we buy you beer for developers. This turns out to be incredibly effective. That's just one of many things.
How we deal with support: what I love about our support team is that we measure our success—the success of a support interaction—by counting how many explosion exclamation points are in the response from an end user. That’s creating superfans—creating that kind of experience that goes above and beyond what is expected.
And number five: be awesome and change the world. That one's pretty self-explanatory!
So if you have a strong culture, you can use it as a hiring tool. It's amazingly effective, and this is really critical today as it becomes more and more difficult to hire, as all of you who would normally be entering the workforce are instead starting your own companies. The pool of candidates is smaller; the competition is higher.
Since the early days of GitHub, we've evangelized our way of working, our culture, and our values, and the philosophy that gives us that higher purpose. All of this allows you to attract the kind of people that naturally fit your philosophy.
And so those people that you're attracting through this communication will make the right kinds of decisions. And since decisions are how people make products, the philosophy that guides those decisions is all that matters.
So please, third segment of the audience, on three: one, two, three! Philosophy is all that matters! I'm not convinced that you believe it, but okay!
So I've told you three things that are the only things that matter. How can that possibly be? Which of these three things is the only thing that matters? I don't think I have to answer that question; I think it's a false trichotomy.
Someone really enjoyed that joke! Thank you! Hold on, I'm not done yet! Hold on, hold on, hold on! I'm not just gonna end on false dichotomy.
In reality, just like the three quarks of an atom cannot exist on their own, people, product, and philosophy are also inseparable!
So do you guys remember what was the only thing that mattered? PEOPLE! Do you guys remember the only thing that mattered? PRODUCT! Do you guys remember the only thing that mattered? PHILOSOPHY!
On three, everybody say what you said before together: one, two, three!
If you master these things, then you will finally have the answer to the question: how do I raise a hundred million dollars? Thank you!