Philip

About Philip Rosedale

We had an absolute blast at the soapbox with Philip Rosedale, founder of Second Life, this past Friday. Despite the rain, we had an eager and excited crowd which stayed for a long while after the talk asking Philip all sorts of questions about his new startup. This was also the very first soapbox we streamed into Second Life with over one hundred folks joining us from the virtual world via virtual world television. Fascinating stuff!

The Q&A format gave us a chance to find out all the startups Phillip was involved in before Second Life as well as the challenges he faced finding users and revenue for Second Life. We spent quite a bit of time talking about his newest venture. Below are just a few highlights from the talk. Feel free to watch the video of the full talk and questions or listen/download the podcast.

How do you know you should pursue an idea?

Unless you feel a tremendous desire to see if an idea would work without earning a cent from the idea, you probably should not pursue it. Unless you're so nuts about the idea you’re willing to loose money and take a chance with it, don’t pursue it. You might be the only one who would take such a risk, which is great, this separates you from the rest.

What did you mean by Second Life being unfundable?

Twitter in 1999 was a great idea but it was unfundable. If an investor in 1999 was going to assess if Twitter would replace the telephone or replace blogging the answer would be “no”. This of course does not mean it’s a bad idea and won’t take off and become popular. It just means that investors are reluctant to give you the money to build it. This was the exact situation for Second Life. Philip has always believed the Second Life is a fantastic idea and will prosper and become very popular. However the time and environment was not right for funding the idea. It did not mean that Philip would need to drop the idea.

What’s your advice on finding talent?

Applying traditional approaches to recruiting talent when you're working on these types of projects where the idea is too young to be funded is not always the best fit. For Second Life, people just showed up at the door for example. They were so passionate about the idea that they would come in and say: "I've been watching this for a while now and time has come for me to work here.” Passion around the idea was more of a qualification to source talent.

Nowadays Philip is using an open worklist with various engineering and design jobs open for people to bid on. Workers can bid on any job and if the bid is accepted they complete the project and get paid. Inc magazine recently published a detailed article about this approach and the success behind it.

We’d like to thank Philip for such an engaging discussion and thank all of you who showed up in person as well as from Second Life for great questions and wild energy. Looking forward to seeing all of you for our next events

---

Transcript

Philip: You have to actually be so uniquely compelled by some particular product idea or something or a business strategy or whatever that you're willing to put yourself out there and take a huge risk. Once you take away some of the management process stuff that you used to be doing, you then get to ask the question, are you an effective leader? And I think that is a very important question.

Moderator: Thank you for coming to ZURBsoapbox, everyone. Super excited to have Philip Rosedale here, founder of Second Life. Called him out here because not only did he found Second Life, but he has a lot of startups under his belt, and we just wanted to know more about some of the challenges he's faced and some of the problems building Second Life, building some of the startups before, and what he's working on these days, which is pretty exciting. So with that, let's welcome Philip to ZURBsoapbox.

Moderator: Again, a head start, because we're actually streaming it live into the virtual world. So, in Second Life, there are people that have bought TVs, and they're watching this stream live from reality into Second Life and the virtual world.

Philip: Hey, everybody in Second Life.

Moderator: So that is pretty neat.

Philip: I haven't been streamed into Second Life in a little while. It's been a little while.

Moderator: So let's start from the start. You grew up in San Diego?

Philip: San Diego. I did. Mostly.

Moderator: You majored in computer science.

Philip: I did.

Moderator: And then, what was your first business ever?

Philip: My first company, I started when I was 17, and that company was a database software company. This was before the Internet, practically speaking. It was in 1986, so now you can figure out my age. I was always doing software development since I was a little kid. I got into doing database stuff. I was using FoxPro. I bet nobody here has even ... there's a few people here old enough to remember FoxPro. I was using this database programming language for the Internet. I was networking PCs together and selling them to businesses.

I actually had a system that I built for car dealerships, which strangely, I just sort of encountered randomly through a contact and realized that selling a car is actually really labor intensive. There are all these forms you have to fill out, so I wrote software that would calculate all the stuff you needed to calculate to sell a car and then print all the forms actually on an old Okidata dot matrix printer. And, as simple as that was, it was very valuable, because as a car dealership, you saved a huge amount of time and could get people out the door.

Moderator: So you were a college student?

Philip: That was when I was in high school. I started the company in high school, and then I did it all through college. So I was studying physics in college, doing programming on the side and supporting the customers that I had with this software. That was before I came to San Francisco and fell in love with and discovered the Internet as we all know it today.

Moderator: So you just like ran around knocking on doors telling car salesmen to . . .

Philip: I did. I definitely would cold call. I'm trying to remember some of the great stories. I was the kid who would come to your car dealership and literally walk in and say, "Hey, you guys don't have any computers. Would you like me to tell you . . . I've got this thing, and you could use it here." It was a great way to make money.

Moderator: So you did that, and then you went over to Real? Was there anything before that?

Philip: I wanted to stop and ask, because I'm stuck in a room. There's a whole bunch of people ... the Internet, Second Life can't see anybody else. How many engineering people, people doing engineering, design? Okay, cool. I kind of wanted to tune what's interesting to everybody.

So yeah, I had my little company. I came up to San Francisco. I just got lucky, and I happened to move in right next to one of the ISPs that was coming out. This was literally for guys that had maybe 3,000 customers that were dial-up Internet subscriber. This was late '94, 1995. So they gave me what was at that time a 115,000-bit, 115kb serial connection to the Internet, and I was just completely blown away by what I could do.

So, I kind of dropped everything, and I started working on basically anything I could think of that would take advantage of this unbelievable concept of basically TCP/IP. You could send short messages point to point to all these computers all over the world, and they all spoke the same messaging language. I was just like, what can't you do with that? So, I had always wanted to build a virtual world like Second Life, but I didn't think practically that in 1995 it was remotely feasible in terms of being something that would actually work and a lot of people use it.

So instead, I started working on video compression, because I thought that might be something that would be interesting. Some way of sending video over the Internet. In that time, there were just a few early experiments around that in '94 and '95. There were some really early prototypes that people had done to transmit video over IP networks.

So I started working on that problem of how to compress video, and that led me to selling my very nascent product that I had built around that to RealNetworks. So I joined RealNetworks as an early exec at Real. Real was pretty small at the time. So I was the person who helped develop Real video. That was my responsibility was to make Real into something other than RealAudio, for those who know that story.

Moderator: Real was a big player. I remember that. It was just all over the place. So you were at Real, Real was popular, had a pretty good job. Why did you move from Real? Tell us actually about this idea that you had before Second Life when you were still …

Philip: Well in '99, I always thought that the general idea of building a construction kit where you could take a huge dark space and just build things in it digitally and essentially redo the laws of physics but with digital atoms. There's this great philosophical question of, how would the world be different if we could build it all over again now, given that we're here now? You know what I mean?

The universe has been around a long time, and its rules, so far as we know, and as a physicist I can say this, its rules aren't changing. It's got a basic set of properties that have been around here before us, so far as we can tell. How would the world be different if we rebuilt it ourselves? How would you make things different? So I always thought that was a totally fascinating question. I wanted to work on that.

So when the Internet was around, I was struck by the idea that you ought to be able to get a ton of computers connected together over the Internet and simulate reality somehow inside those computers. So that was the dream, and I was really passionate about that from just after high school on. Books like "Snow Crash", for everybody's that's read that, when that came out, I was already so into this stuff that my wife and my friends were like, "Oh, you've got to read this "Snow Crash" book. This is that crazy stuff that you're so nuts about."

In 1999 though, what changed was NVIDIA came out with the GeForce 2, which was this really good graphics code processor. And the other thing that happened in '99, and it was really easy to see when you were working at RealNetworks, was you knew that connecting via broadband was going to be the only way you connected to the Internet.

So with those two things being true, I thought that maybe I could leave RealNetwork, start my own company, and build something like Second Life and get away with it. Do it without having to raise too much money and just being able to make it happen. I wasn't sure, but I was somewhat more sure than I was in '95.

Moderator: How do you make sure that you're sure? I mean there's so many . . . there are so many people out there that just, they have a hunch that something might work. How do you actually run with it and be like, "I know I've got to go and do this." You stated this thing there. There are competitors.

Philip: It was out there. They had started two years prior.

Moderator: Yeah, scary stuff, right?

Philip: That was terrifying, yeah.

Moderator: So, how do you go about making sure that what's — ?

Philip: I'm always asked about entrepreneurship, and I talk a lot about entrepreneurship. I think that unless you feel a tremendous personal desire to see something work as an entrepreneur, you probably shouldn't do it. Unless you're so nuts about the idea that you're willing to take . . . I think you should be led by your willingness to lose money or your willingness to take a chance.

If you actually feel that way, and you're that passionate about a particular idea, you might be the only one, which is really good. It might be time to try and build that thing. I know that a lot of entrepreneurs, especially here in Silicon Valley where I did not grow up, kind of come at this with the idea that that's just what life is here. You're an entrepreneur.

People are bankers in other cities, and here, you're an entrepreneur. That's like a job. It's not a job though. It's just not a job. You almost always fail doing it, so it's not a very sensible job. Or career. Entrepreneur is not a sensible career.

You have to actually be so uniquely compelled by some particular product idea or something or business strategy or whatever that you're willing to put yourself out there and take a huge risk in terms of your self-image, your money that you invest in it and everything else to do it. I think that's really the checkpoint.

Actually, I think it's pretty easy. If you just use that one rule, people wouldn't do a lot of things, and that would probably be good. They wouldn't do a lot of things that are destined to fail.

We talked a little bit in your write-up of this. My apologies if I mis-articulated this to people in Second Life. In the masthead for this get together, we talked about Second Life being unfundable. What did I mean by that? What I meant by that was not that it wasn't a good idea. I thought that Second Life was then, is now, will be in the future one of the most important transformative changes that we make as a human culture, to essentially start digitizing the physical world around us. I thought that was a huge idea.

But when I say that it was unfundable, what I mean is that — and I think this is a really interesting conversation in general about entrepreneurship — there are certain types of ideas that involve making something completely new where you have no idea whether or not it might be compelling to people, or it might have utility sufficient to justify its cost.

Those types of startup ideas fall into a certain category, and you've got to really think about whether in your efforts as an entrepreneur you're in that category or not. That category is the kind of unfundable category. And what I mean by that is ... and there are lots of examples of companies, great companies, not just Second Life that are like this.

I would say even something like Twitter actually would probably be a pretty good example of that. Because if you had described Twitter in '99 or something, it's not that you wouldn't find it intriguing. It's just that it would be rather unfundable in the sense that an investor trying to look at it with the perspective of, what practical utility will this serve? Will it replace the telephone? And, of course, the answer would be, no. Not in any obvious way.

Twitter's not going to replace the phone. What will it replace then, blogging? Well, not exactly. The nature of how one blogs, it's not 140 characters. It won't do that either. So it's just this giant question mark. Would it have utility? Would people like it? Would it be compelling? Would it be viral?

Second Life was just like that. It was this idea that yeah, some crazy guy named Philip wants to build a digital world, but would anyone want to be there? Will there be any positive utility to it relative to the amount of effort you have to put it to getting there? We didn't know that. So, that's what I mean by that. There are projects like that.

Those projects, you shouldn't undertake unless you're unbelievably passionate about them, one. And then two, you should fund them in a very incremental way. You shouldn't raise a whole ton of money. You're not going to be able to anyway. You should approach them in a very gradated way.

In fact, when we were competing with There.com at Second Life, that was a real element of the difference in our strategies. There also had the good fortune, or bad fortune, of starting the company at a time when it was much easier to raise money. So they had raised a huge amount of money around the idea, which was as Second Life shows today, a really big idea.

But again, very early, and they raised a ton of money. And their investors were saying, "Where are the revenues? Where are the users?" They said that our investors said that to us, "Where are the revenues and the users?" early on, but we had only invested $11 or 12 million. I think we had probably invested about $12 million in Second Life that we had spent in mostly our salaries and development at the point where we felt like it was probably going to work, which was sometime in 2004, probably later in 2004.

By the time that the company reached its first quarter of profitability or where it looked like we were about cash flow breakeven, I think we had spent at that point about $20 million. So to give you an idea, I think $20 million is a huge success to have managed to get people to invest in an idea as far out as something like Second Life that's really hard to quantify. So I feel proud that we as a company were able to actually even raise $20 million.

But, as you know, many great ideas entrepreneurially today can raise lots more money than that. But what I was trying to say is that those ideas generally fall into this case of, they're differential competitive ideas. That would be something I was thinking about. Jack Dorsey who I have met and know, fantastic entrepreneur, one of the Twitter founders, started Square up.

Square is an example of something that is a little easier to explain and understand, right? Take credit cards on an iPhone. Very important idea, very obvious in its positive utility, very fundable idea. Probably going to work. Somebody's going to do it.

Maybe it's not Jack. Maybe he doesn't do quite right, but it's going to be somebody, so if you look at that as an investor, you can really understand the competitive thesis there. But Second Life was just, perhaps like Twitter, was just in a totally different category.

Moderator: So you self-funded it when you started it up.

Philip: Right.

Moderator: And then, how big did it get? How many employees do you have working at Second Life?

Philip: Today, Second Life has about 250 people, and it was about that size when I left as the CEO, like three years ago now.

Moderator: How do you recruit talent? How do you build culture? It's a huge thing to manage. You had the idea. Had you managed huge teams like that before?

Philip: I had not. It was very fun, and I'm still learning. I had no idea. For the most part, I think especially with these projects that are like Second Life, the proper answer to that is I don't really know. I think that applying some of the traditional strategies for talent acquisition, for getting people to come work with you when you're working on one of those types of projects is kind of a dicey proposition. I don't think it necessarily works exactly the same way.

Again, I think when people understand really well what they're working on, when it's a competitive differentiation thing. We're going to have to work 12 hours a day, and we're going to build a better thing than this other company over here, and that's going to generate untold riches for us as a team. I think you have a different acquisition and recruiting strategy.

Again, with a project like Second Life, I think we have less human history and knowledge around how you do that. I can only say that for Second Life, people literally just showed up.

Moderator: At your door?

Philip: Yep. And they were people that were passionate about virtual worlds. They had a particular vision that was maybe not so far off of mine that they wouldn't come, and they just would show up and say, "The time has come for me to be employed here now."

The greatest people we had at Linden Lab were literally just people. I can just remember multiples of them that would just sort of come in and say, "I've been watching this for a long time, and now it's time for me to work here." So I don't think we really knew how to recruit people, but I think the people who were passionate about that kind of idea just managed to kind of come together as if at a concert or something, just would show up to see what was going to happen.

Moderator: So you had teams, right? You divided things into teams. People showed up, you probably put them through some questions?

Philip: Yes, we interviewed people.

Moderator: Good.

Philip: We had some good days as interviewers. We were pretty good. But yes, we did offer conventional employment to people and all that, although I don't do that now. We have experimented very successfully with my new company in not doing conventional employment. There was just an article in Inc. about this, about what we've been doing in that sense, and it's very fascinating. So I don't want to laugh too much at that, because I think there is a place that work is going that's different than the way it works today.

But, at Second Life, I would say it was pretty much like what you would imagine in Silicon Valley or San Francisco. People came in and interviewed, but I just think that a lot of times, we didn't have to really have headhunters running around trying to find them. They would just show up and say, "I'm a specialist in this. I've been thinking about this all my life, and I want to work on it."

Moderator: Talk more about what you do now.

Philip: Well, I always believed that software development in general . . . and taking on Second Life really illustrated this. Let me explain why. Second Life, as it turns out, as a software project just falls into ... not only does it fall under this crazy, uncertain idea where you don't really know whether it's going to work or not until you build it.

It also falls into another category that's really important, and sometimes people get this about Second Life, and sometimes they don't because they're less technical, so they just don't get it.

Second Life falls into the very complicated technology category. I see some nods. Second Life's like an operating system. There's things that are at the scale of an operating system with all of these little appendages and parts set up to work at the same time. And then there are things that are not that. I don't know about everybody here, but at least me as an engineer, you just kind of know that.

You look at a project, and you kind of go, well, this is a pretty linear, understandable thing. We need to move this message from here and put it in this database. Then you need to be able to look at it here. There's a number of different ways to do that. You're not going to fail as a company because you failed to build the technology.

But something like Second Life, you could potentially fail. Or an operating system or any kind of big complicated distributed client-server system. You could fail if you didn't develop it the right way. So Second Life had that property.

As we developed it, I was very struck by the observation that the traditional way that software development and management happened didn't fit very well with the problem that we were trying to solve. We were trying to solve a problem where there were 50 little moving modules all flying in close formation, and we were trying to manage the company ... to a certain extent, we were aggressive about trying not to do this. But we certainly went at it and a lot of the early employees went at it in the traditional way, which is highly planned, a lot of top-down.

So the most creative risk-taking and ingenuity was happening at the top, at me. And then you sort of were delegating with less freedom at each level below that. And when you get to the person who's, for example, writing the code or writing a test harness or something like that, they have absolutely no decision control about the nature of the project. I don't know if that's an adequate summary, but that's kind of been the traditional model that we use as human beings to manage and build things when there's more than one of us involved.

I looked at that, and I looked at what we were doing with Second Life, and I said, this is not the most efficient mechanism here, because I'm not delegating freedom of design and decision-making rapidly enough through this kind of a pyramid. So we got really interested in what the alternatives were. So you could look at open source. You can say, well, that's an alternative.

You have a bunch of people with a kind of peer interest in a shared asset, and they're all going to basically make changes to it, and there's not really going to be a lot of regulation. They're not making any money doing this, and kind of everything that everybody does is going to get checked in. So it's going to get lumped in with a project. So that results in a certain type of software, but it's different than building it from the top down.

So what we did with my new company, which is called LoveMachine, which has taken from one of the cultural tools that we built, the name of a tool that we built inside Linden Lab when we were trying to manage differently. It's called the LoveMachine, and you can look it up. We can talk about it later.

The thing that we did with the new company when we started it was to say, we're not going to hire anybody to do engineering in a conventional, salaried way. Instead, what we're going to do is we're going to try to build a system that's kind of a hybrid between something like eLance, like a contracting system, and something that's more like an open source project. We're going to actually build a new piece of software and a management strategy that falls in between.

So what does that mean? It means we are going to essentially break our project up into a whole bunch of little contracted pieces that are much smaller — this is what we use the technology for — that are much smaller than the traditional contract you might come and do for a company.

So if you're working as a contractor on a site like eLance as a developer, you might do a project or be part of a small team that works on a projects that's like $10,000 of work over a couple of months. Indeed, I think the average contract size on most of these freelancing sites is about $5,000.

So what we said was, what if we use technology to make it so easy to negotiate with, get paid, check in, do your code review? What if we use technology to make that so easy that the average contract size would drop down to like $200 and just a few hours of your work?

What if we made it possible for you as a person who'd never seen our code before to come and help us rewrite a login screen using, say, your lunch time over a few days, and then we would just pay you with PayPal as soon as you were done? But we would use the kind of open source strategies that people have traditionally used to drive quality.

So, for example, we would have you do your work in a shared code sandbox, where a lot of other people could see what you were doing all the time. So we could entrust you to be pretty aggressive about what you were doing, even as a newbie to our environment, but a lot of other people could see what you were doing and tell you if you were screwing something up.

The other thing was, what if we pay somebody else who you don't know a little bit of money to review the code that you're about to check in? If we trust that both of you want to continue to be employed by us and do stuff, can't we just trust you to review each other's work product? Do I even need to look at the code that you're writing as, say, the founder if I can get that to happen in a distributed way? No.

So we built that system, and it's this thing we call the work list, and it's what we've used to do about a half million dollars of software work at an average contract size of about $160 over the last year. And what I'll tell you is that, at least for certain types of projects, more kind of ground up prototyping, let's see this work and play with it quickly, I would defend that our speed, quality, fun cost per screen of new code is strikingly better than the traditional approach. That's even putting us up against the three people in a garage.

I'll take them on any time. We'll wipe them out, because we can call on . . . where you start with a project three people in a garage, they better have all the competencies you need, because those three people are going to sit down. What if you want to do SMS, and nobody knows anything about SMS on that team of three? You're done, because that team of three already split up the equity of the company, had that tough conversation about who got what, and they and their egos are now stuck in a room trying to build whatever it was they said they were going to do.

I can do that in a quarter, a fifth of the time using 25 people who are doing it in their part time. We always joke about the expression, lots of little parts of more people. It's almost like that's what ... I don't know if there's a brand there. We're trying to build a company where we're little chunks of people rather than whole people in the way that you would traditionally approach it.

Moderator: That just would be counter to everything we've ever believed in, because usually you've got your tech guy, your developer, and you've got to kind of marry him. It's you and him together. You're developing this thing. If you start hiring a whole bunch of other developers, the lines of code, it's going to be hard to keep up, and everybody has their own style of coding. It's just going to be a big mess.

Philip: That's right. That's exactly the right question. A piece of software, a substantial piece of software built in the manner I just described, how does it compare in terms of, say, code quality and architecture to something that was done in the conventional way?

Now, I'll be the first to tell you — and don't believe me. Go to the work list, because as I described, all of these projects, including the stuff we're working on right now, including a new project that's kind of a secret project that we're getting ready to launch, they were all built in an open code base.

So you can actually look at the code. In fact, especially with a room like this, I would very much invite communication afterwards to give me your assessment of what you actually... I would love to have anybody here that wanted to look at that code and tell me what they thought about it.

So, is it as high a quality a code as you would do if you designed it all yourself from the top down? Of course not. It's heterogeneous. It looks more like an open source project, or even a more distributed thing than a traditional open source project, which in some cases has a high degree of architectural leadership of it.

So no, the code quality is not as good. But the question I ask you is, are the benefits worth the costs? In other words, is it less scalable though, the solution that gets built with these people reviewing each other's code? In other words, will it scale to a million users worse than that other top-down architected thing? I'd tell you to take a look and see for yourself.

So what I think is, yes, there are these sorts of problems that we are naturally afraid of as designers and leaders. But surprisingly, those problems aren't that big compared to the tremendous advantages in speed that you get. You can go back in using the same contracting method, and we do this.

We write tests that are these little contracts. We rewrite the code. We refactor things to improve code quality using the same strategy. So you can use this same, very rapid- fire small piece of strategy to do all the quality improvements. I think there is one thing that is still true, which is you've got to have people with the right architectural sensibility writing these little contracts.

So I'm the person, my partner Ryan, my other co-founder Fred. The three of us, Ryan and I in particular over the longest period of time, have written all these little contracts. You've got to have a sensibility for what you want to get out. It's that garbage in, garbage out type of thing. If you had no engineering skills and you were writing these little contracts, and what you were building was highly sensitive do being architected the right way.

Like if you tried to build Twitter. Go back to Twitter, which we know as engineers. If you tried to build Twitter in this way, and you weren't engaging or dictating at all in these contracts how you wanted the architecture to be done, you'd be in trouble. But how much of my time and how much of my skill has it taken to kind of maintain a reasonable architecture with the stuff that we've built? It's really not that hard. Most of these projects don't take that much architecture.

Moderator: Instead of putting something like, "I want a site that sells bunnies with a share button on it," and sending it out as a contract, you'd put something like, "I want a form that is validated with a button."

Philip: Exactly. The first contract on the LoveMachine, which was this commercial app we built that was the thing we originated inside Linden Lab, was a contract I wrote where I said, "I want a form that posts to a database in MySQL with the following rough schema. Give me back this form." And somebody did that for me in a couple hours, and I had that. And then we just built the whole thing on top of that.

We've done everything like that, exactly like you said. Start with a login page. Start with the settings page. Get the home screen up as a framework that just has a skeletal data display that's live. And then deploy it and have everybody that's working on it just sitting there using it.

That's the other thing. I'm not a big believer in multiple staging systems, because you want to have everybody literally just sitting there. The other key thing we built, which is part of the work list if you go check it out, is this thing called the journal, which is basically IRC. It's a very capable live chat environment that's constantly telling everybody that's sitting in the chat environment what builds are happening, who's working on what, when people get paid.

If we had hours, I could talk about all the psychological motivations to this stuff. We have a bonus system where I can kind of anonymously give you a bonus as a developer, and it literally says, "Philip received a $100 bonus," in this chat system. So you see that pop up. Everybody else can see that. So there's all kinds of fascinating things you can do if you bring the transparency up, put everybody together in a shared space, and then break the project up into very small pieces.

Moderator: Cool. Let's open it up — we have about 10 minutes — to questions from you guys.

Audience Question: What was [inaudible @32:52] in the system? Did you build the work list yourself?

Philip: Yes. So the work list itself was built using this system. We built the LoveMachine, which is an internal messaging system for companies. It's kind of a multi-tenet infrastructure on EC2, where you essentially deploy an instance of this messaging system where you can send each other these short messages of recognition inside a company. You get tools like word clouds that show you what everybody is saying about each other in your company. Very, very interesting stuff like that. That was an app.

The work list itself, which has SMS payments systems built into it, all kinds of interesting search and form displays on it. We've built several iPhone apps using this approach. We're currently using Titanium as a framework for doing the iPhone and Android apps. We've built a few backend ... we built our own word cloud at one point, because we wanted a word cloud tool that did 2D physics. We've been able to build a lot of different things with it.

Again, I said we spent about a half million dollars in development time. We've spent that money on probably about 120 different developers around the world, developers, testers, program managers. We do program management in a very similar way. So you can literally have somebody who's looking after the contracts that I'm writing.

We have one primary person, given our scale, that does this. He's in Belgium, and he's literally constantly doing the program management. Did this check in? Did it match the spec that Philip wrote? Does it work? Did the final commit actually get pushed, and does it look right?

Again, all that stuff, he literally does that and then adds a fee, which everybody else in our community can see him add, to the project that's saying, pay me. This is what you owe me for that work. So he's regulating.

This idea of people regulating their own pay in a shared environment where everybody can see what everybody else is making is very, very interesting as a different model for managing people's behavior basically.

Audience Question: So, do people bid on these contracts, or do you have to [inaudible @35:07] employees or set of people you're always working with?

Philip: Both. So as a developer, if I put a project in that might say something like . . . I just did this. "Send a message when a new user signs up to our chat system, so everybody in the system can see that a new user signed up." So I'll write a contract like that that was basically a couple paragraphs of that description. You get bids on it.

I get SMS's telling me literally while I'm driving down here telling me what the bids are, and then I accept one of those bids based on my assessment of, obviously cost, but also is it the right developer for the job. If it's somebody new, I might ask myself, "Is this really hard? If you're brand new, are you going to get into it and just get chewed up by how difficult the project is?"

On things like program management, code review, those things are fees that we just ask people to just be wise. That's where we take advantage of the fact that everybody can see what everybody else is doing, and we just say, "Just add a fee that you think is appropriate for your time to this." But know that everybody can see this, and obviously if you're not adding fees in a way that's the same, we're not going to keep calling on you to do that work. But you're right, we do both things. We just trust people to pick the numbers.

Audience Question: So, how much visibility do you give folks, whether they're [inaudible @36:25] your program management into the components they're going to be looking at? What I mean by that is, someone goes to Linden Labs and says okay this is the component I'm going to work on.

For a new entrepreneur who's starting MyBunnyStore.com, how do you compel and attract talent to work on those specific components if you're trying adhere to this kind of model? You're a new, hot, sexy thing. It's easier for more established, more renowned projects. What would you say to folks how are trying to figure this thing out?

Philip: Well, I think the appeal, and I'm not sure. Let me try and ask that and see if I'm asking it right. The appeal of this kind of a granular contract type development system, really it doesn't matter what kind of project you're working on. The appeal is it's really easy to get in, do something as a developer, get paid for it. Like code reviews.

Anybody here that's a developer or that it's under the right conditions and you feel like coming in and doing code reviews for us, please do. It's a great way to make extra money. We pay you with PayPal every time each one of these little jobs is complete, which is a bunch of times a day that they roll through. So I think the appeal of it is also just functional in that it's easy to do. And I'm not really worried, actually, about recruiting people.

But I do think . . . I hope maybe I'm explaining this a little bit. I do think the other thing that happens that's really healthy is you see people move around their efforts, according to whether something really is useful or good. You know what I mean? A lot of times, you'll put a feature idea in, and nobody bids on it.

Part of it is because we are all communal animals. When you're part of a project like this, regardless of whether you have stock options or how you're paid or whatever, you feel a sense of ownership and of protection and nurturing of the thing you're building. So it's really interesting.

A lot of times, I have been so humbled as a designer — and designers need humbling — that I'll write some feature idea, and it's just no bids. Crickets. Two days will go by, and I'll just turn to my partners and be like, "Well, I think we know about that idea now." Whereas in a conventional organization, that sucker would get built, and it would suck and nobody would use it.

Audience Question: This is all very focused on engineering. I'm more of a community manager, people person communicator. What do you do with people like me? Do you have them on you're team?

Philip: We've run contracts around things like, communicate with new users that are coming in. I think it's pretty amenable to that whenever you've got a well-described task and a well- described expected outcome. I'd like you to talk to the last 10 people that signed up for the LoveMachine and see how they're doing. You can write a contract around that. It works.

I don't think that we have as much road time, as much test experience with that. I'm always respectful of there are a lot of different pieces of a real business, and I'm not certain that every one of them can be automated necessarily using an approach like the work list. But I do think that things like that can actually.

I do think the customer support, community management, different types of outreach, evangelism, and sales can be managed with this type of a system. I don't necessarily believe that everything can. Like I said, I don't think that vision is crowd sourced in most cases. There can be aspects of it that are, but you still have great leaders.

In a way, systems like this that are more market-based are harder core, make it more obvious who the real leaders are. I think you were mentioning that in the write-up to this. I was also very passionate about teasing out what the aspects of real leadership are and then measuring them, rather than having most of leadership be management, be human performance management, which again has its place, but I don't think we need to do as much of it nowadays as we used to need to do.

We all like our jobs a little more. There are many, many wonderful transparent ways of assessing performance that we should avail ourselves of as business operators. And then, once you take away some of the management process stuff that you used to be doing, you then get to ask the question, are you an effective leader.

I think that is a very important question and one that the leaders of organizations should be scrutinized in the same means that these sort of transparent peer review and payment mechanisms should be.

Moderator: One more, and then people can ask questions after.

Audience Question: Actually it's a two-part question, but the first one is really simple. I'm wondering how you're handling taxation for the payments you're doing. Do you send 1099s out?

Philip: Yeah, we are.

Audience Question: The second big question is I'd appreciate, Phil, how you've be more descriptive than prescriptive so far, and I think I hear in that humility. But if we pushed you to give us some advice based on your experience, would you push people doing new ventures right now to do the same kinds of things you're doing across the board? If not, what would you say we should think about as we evaluate whether to use some of these techniques?

Philip: The simple answer to the first question is yes, we do 1099 people. So we keep track of that and we do it. That's obviously an ongoing interesting question as to what the right treatment is and all that. But yeah, as it stands today's, if you pay somebody a couple thousand dollars, you need to report it.

The second issue, what's my advice to people. I think that it's possible to reduce the cost of developing ideas and increase the speed, enjoyment, and empowerment associated with it significantly enough that I would suggest that people that are thinking about early stage new ideas in potentially competitive and fast-moving environments to at least think about these strategies. Because I think what these strategies do is they really just reduce risk.

Like I was saying, the crickets experience of having nobody bid on something, that's a great risk reduction for us as a company, for me to get that feedback that quickly. And that's going to translate into a competitive advantage if I'm going up against somebody else's team and I'm trying to build, like I am right now in several different ways, a new product and I'm up against another team. I think we'll win, because we've just moved so much fast, because we're so agile and we have such lower ego. We just have to back out of stuff that's the wrong direction.

So again, I think if you're doing something novel, you're starting from zero lines of code ... and of course, I can't help but do this a bit as a salesperson, because as an inventor of this type of process, I really want to see it work with other projects.

One of the other things we're doing — again, absolutely welcome participation and involvement here from people, especially with a group of designers and engineers like this — we're just starting to run other projects in this system, and we'd love to have you and your projects come to me and we'll give it a try.

So what I would say is if somebody is contemplating doing something where they're basically starting from scratch right now and they're going to design an idea from the ground up, boy, come and talk to me, because this kind of approach is fascinating. Whether you build your own system that does what we do or you use our software, I don't care. I'm more interested in continued validation that this kind of an approach to product building is going to be better in the future.

Moderator: Let's thank Phil for coming out for this awesome talk.