Tuesday, September 27, 2011

I was asked by a reader how much equity he should give out to early employees and to service providers in a very early stage startup. I'll get to service providers in a later post.

Founders vs. Early Employees

To help with this discussion, let me start with a definition of "early employee." Steve Blank divides the individuals associated with startups as:

Founders

Early Employees (Employees # 1-25)

Later Employees (Employees # 26-125)

The reality is that the definition of founder and employee is not clear. The first few people into a startup are on a spectrum of founder vs. early employee. Founders are likely not paid for a long time and have a sizeable equity percentage for early risk and having the concept. An employee is later, has a greater portion of compensation as cash, has lower risk, and generally does not bring as much to bear in terms of the concept.

Early Employee Equity is an Art

For your first key hires, three, five, maybe as much as ten, you will probably not be able to use any kind of formula. Getting someone to join your dream before it is much of anything is an art not a science.

Equity Formulas

While it's somewhat an art, there has been a lot written about how you can look at equity compensation.
Paul Graham provides what is roughly the core formula for equity at any point in The Equity Equation:

You can use the same formula when giving stock to employees, but it works in the other direction. If i is the average outcome for the company with the addition of some new person, then they're worth n such that i = 1/(1 - n). Which means n = (i - 1)/i.

For example, suppose you're just two founders and you want to hire an additional hacker who's so good you feel he'll increase the average outcome of the whole company by 20%. n = (1.2 - 1)/1.2 = .167. So you'll break even if you trade 16.7% of the company for him.
Let's run through an example. Suppose the company wants to make a "profit" of 50% on the new hire mentioned above. So subtract a third from 16.7% and we have 11.1% as his "retail" price. Suppose further that he's going to cost $60k a year in salary and overhead, x 1.5 = $90k total. If the company's valuation is $2 million, $90k is 4.5%. 11.1% - 4.5% = an offer of 6.6%.

Same Value for Sweat Equity as Investment Dollars?

Jason Cohen in How to think about cash vs. equity compensation (definitely read the comments) provides similar kinds of formulas. The key in his approach is that equity compensation should be viewed the same way that you view investment. In other words, the loss of compensation for the early employee as compared to market rate should be viewed as equivalent to the equity for that same dollar amount from an investor.

Logically, that's correct, but I personally would put a risk premium on equity compensation. I also believe that early employees should be bringing higher value than early investor dollars as they can and should contribute to the concept greater than an investor. They are partially rewarded by the increase in value of their equity. But their contributions raise the value for everyone. I believe that Paul Graham's core formula takes that into account.

The more that those first employees feel like founders in terms of their ownership, emotional attachment, responsibility and overall understanding of the startup process (including financing, running day-to-day activities, etc.) the better the startup will be.

Being an early hire at a startup gives an individual the ability to make tremendous impact on an organization as it grows – and both the founders and those hires should know it.

Of course, all of that assumes that the early employee does make an impact.

Risk Premium on Equity Compensation?

While Jason Cohen suggests that investment cash and sweat equity should be viewed the same, quite a few people suggest that there should be a risk premium for early employees at early-stage startups. A risk premium is a multiplier that says that any equity compensation should be viewed as being worth less than cash for that employee because of the risk.

The risk premiums that I've seen vary widely with seemingly camps of:

None - like Jason

20-50%

3x - 4x

In a way, suggesting there should be a risk premium is just arguing over valuation and expected return. There's also the aspect that the equity that you typically get as part of equity compensation is behind other equity in preference and thus effectively has lower value.

But the more important rationale is raised in the following about why employees most often do not have significant outcomes even in fairly positive liquidity events.

Consider the proceeds of a $50-million acquisition for a 100-person company that has raised $14 million with a typical liquidation preference:

Because of the liquidation preference, the investors get $14 million right off the top. The remaining $36 million is divided according to equity ownership.

Investors own 50%, and get $18 million, split between two firms

The two founders own 33%, and split $12 million

The 3-person executive team, including a CEO if one was hired, owns 10%, and splits $3.6 million. The team gets another $3 million as a severance payment or an earn-out, to sweeten the acquisition offer.

The remaining 95 employees split 7%, each earning $27,000. Unlike the founders, the employees have to wait until their grants vest, working at a company no longer of their choosing for two years.

You get 1%, you sell for $150 million and it’s in 3 years (e.g. you won the lottery). That’s an after-tax gain of $287,500 / year for 2 years. Not bad. Doh! Wait a second. Stock vests for 4 years. You didn’t get acceleration on a change of control? Sorry bud. We’ll have to either cut your earnings in half to $143,750 or you’ll have to complete 2-years at BigCo that bought you making the money spread out over 4 years so it’s $143,750 / year for 4 years.

The reality is that an early employee in a pre-funded startup that eventually raises a few rounds of capital will be diluted significantly, is down the line in preference, and will likely be locked up for a while to harvest it. And that's assuming that it's a fairly positive outcome. If it's anything less that positive, preferences will mean they get nothing other than what's required to keep them working if that's needed at the acquiring company.

Sample Equity Numbers

I personally always like to see some actual numbers rather than basing things on formulas. Because of the Art aspect of early employee equity, I had trouble finding much in the way of numbers for that specific aspect. I did find a few things for later points. Wilson Sonsini and DFJ Gotham Ventures:

It's important to note that this is all post Series A. If the company is pre-funding or only has a small friends and family seed round, then the numbers should go up from there based on expected dilution and greater risk.

Where I Come Out

Again, like Fred Wilson says, early employee equity is more art than science. I would look at the individual involved and factor in:

Domain expertise

Connections

Experience with related ventures

Ability to make significant contributions

Replaceable - are there lots of other people out there who can do the same thing.

Part-time vs. Full-time - doing something on the side is less valuable

In other words, if I find someone who's willing to dive-in, who's going to significantly contribute to make the company a success and it would be hard to get anyone else, then I would provide significant equity, most likely an equity premium. If this is a junior level developer, then likely you can provide significantly less equity. The example numbers above bear this out.

Oh, and one last thing, make sure you figure this out upfront, you have it vest, you have ways to get it back, etc. There's a lot of advice out there on structuring equity compensation agreements. Go read up on that and do it right.

Tuesday, September 20, 2011

One of the readers asked my opinion around sharing your startup concept:

My first question has always been - how do you protect your idea while shopping around for feedback, partners, developers, etc.? Especially if the idea could be whipped-up by a few 24-year olds in a few weeks?

Lots of thoughts here. First, if your idea really is something that a couple programmers can whip up in a few weeks, then you may not have much of a business here. But let's leave that aside for a minute.

There are lots of benefits to talking to people. You’ll get suggestions for improvements. You’ll discover flaws and hopefully correct them. You’ll learn a lot more about the sector/industry. You’ll learn about competitive products that exist or are being built. You’ll gauge people’s excitement level for the product and for various features. You’ll refine your sales and investor pitch. You might even discover your idea is a bad idea and save yourself years of hitting your head against the wall.

In the beginning there are three basic things every startup needs: experts to give you input on your product as you’re building it, users to help you beta test your product in a real-life setting, customers who will give you real money for what you’re building and take real risk in doing so. You need all of these people to bake the cake.

He left out capital sources, but it's still a pretty succinct list of the types of people / communication you should be having early stage.

What is Stealth?

What's also interesting in Niel's piece is that he defines Stealth Mode not as not having conversations, but rather he says it's not make public pronouncements. Seth Levine in To stealth or not to stealth says this pretty well:

There are varying degrees of stealth, ranging from companies that won’t tell anyone what they are up to, to companies (like the one I’m referring to)that don’t have a web site and haven’t made any announcement of their business intentions or funding but aren’t hiding what they are doing in daily industry conversations, etc.

The reality is that Stealth is defined differently in each case. What we are talking about is a spectrum of how you restrict early communications around your business:

Who you will talk to including the public / press / etc.

What you will convey in your conversations

What protections you will place on those communications

For example, you might decide that portions of your concept will be controlled more closely (a secret algorithm). This will only be disclosed when there is an NDA in place. But you will be able to convey other aspects freely, even publicly.

How Stealthy Should You Be?

This is going to be fairly specific to the company. I would suggest that it's best to be as open as possible. My general take is similar to Chris Dixon. In that same post Why you shouldn’t keep your startup idea secret where he argues to make things open, he defines only one group of people that you may want to avoid having a conversation with:

The handful of people in the world who might copy your idea are entrepreneurs just starting up with a very similar idea. You can probably just explicitly avoid these people, although by talking to lots of people your ideas will likely seep through to them.

I might also be concerned about taking my idea directly to a large, well funded competitor who is know for innovation. And I probably will not announce detailed specifics publicly prior to creating them. Beyond that, I want lots of conversations with experts, users, customers, VCs, partners, etc. I may decide to hold back some detailed specifics around algorithms. But generally I'm going to favor being open.

Since I fall into the expert category, my belief is that you should be pretty open with me. Startups that come to me and ask me to sign an NDA in order to get Free Startup CTO Consulting really are missing it. And getting into a discussion but not being able to tell me about your business also hurts you. "We are doing something in mobile advertising." Ummm ... "Good luck with that." What can I say.

NDAs or Other Protection

So you decide you want to be able to share with experts, users, customers, VCs, partners, etc. in order to get the benefits that come from those conversations. You decide what you will convey in those conversations (and what you will not).

Again, relying on StartupRoar this time looking at NDA for Startups, I found some good stuff that you should definitely go through in more detail.

Don't Lead with Protection

I want to close this with one bottom line thought. Please don't make protection of your idea a major topic early in conversations. This is much like condoms. You don't bring the topic up early in conversation. Condoms like protecting your idea can come up naturally later in the conversation. Instead go in knowing what you will share and won't share with this person. Try to be as open as you can, but be prepared when questions reach the border. Simply say that you have some secret sauce in that part of it and aren't prepared to share it. And make sure that does preclude you from sharing enough to make it an effective conversation.

Entrepreneur: Following is an email describing my idea. Since you won’t sign an NDA, you agree that by reading beyond this paragraph you are agreeing not to share my idea with anyone, forward this email to anyone, or discuss the idea without my consent.

....

Feld: You seem to be operating from a perspective of “implied suspicion.” I don’t work this way – I much prefer to operate from a perspective of “implied trust.” Since you clearly don’t trust that I’ll behave responsibly, then I don’t think I’m a good match for working with you.

You can find more here: Startup CTO. And you may also want to review Startup Development.
If you are interested in this topic, I post on it frequently. You can sign up for free email updates using the subscribe box on the right side.

Wednesday, September 14, 2011

This post is admittedly the outcome of a conversation with a few people over some beers. Some of it is a bit tongue-in-cheek and certainly we are greatly simplifying things. The people around the table included a bunch of us who would be prey in some situations. So, please take this in the spirit intended.

The conversation centered around a founder who's key question is "Where Do I Find a Developer for My Startup?" In this case, he had a pretty compelling idea, had very little money, and didn't have the capacity himself to build it. His goal was to find a programmer who would come in as an early partner and work as an Equity-Only Developer. The situation is pretty common it got us to riff a bit around how to get programmers to help him build out a proof-of-concept version for his startup. Along the way, this gradually turned into hunting programmers in the wild.

Before You Hunt - Be Prepared

But before I answer the core question, let me address a few up-front questions. Don't go hunting for programmers until you've answered these.

1. Have you done all you can on paper?

Do you have wireframes? Have you tested the concept with customers using paper? Have you signed some test customers? Have you tested what you can without development? Don't try to hunting programmers until you've pushed this as far as you can on paper and get early customers.

2. Do you know the relative effort to build your prototype or minimum viable product?

The relative size of the development effort will make a big difference in your strategy. There's a cutoff point once you reach roughly 3 person months of development time. At that point, you can't really just try to find someone to build it on the side, do equity only, etc. It needs to be funded to be successful. The grind is too much and too long if it gets beyond that size.

Is this a Wordpress hack? Is it big data? Deep algorithms? Have a rough idea of what you are looking for in terms of talent. Again, if you don't know you should ask people who will know.

4. Is this compelling to a developer?

Be prepared to sell this to the developer. More on this below.

In the case of the entrepreneur that was the genesis of this post, he had done a lot on paper. He had a few early customers ready to go. The size of his initial build was roughly 3 person months and it wasn't particular complex. It was a mobile app, so he ideally would find someone who had experience with mobile development or someone who could pick up a mobile framework. And generally, it seemed pretty compelling for a developer.

In this particular case, because mobile development is hot, it was pretty unlikely that this founder would find someone with experience with mobile development willing to jump on this. So, instead he was really looking for two people: (1) someone with experience who could spend an hour here and there guiding development, (2) an up-and-comer who wanted to get into mobile development. Did we just make his problem twice as hard? Not really. This will still work if you run into exactly the right person.

Getting to Know Your Prey

At their core, programmers are often motivated by a few specific things:

Solve a problem, create something neat from scratch - basically all of us technical people love to tackle problems. The beauty of programming is that you take a concept and turn it into reality with just typing some stuff into the computer. It's about creation. It's really an amazing beautiful thing.

Learn something new - most programmers love learning new technologies or solving new kinds of problems. They don't want to do the same old thing again.

Food and other Rewards - Programmers (like most people) love to be treated nicely. Most days, they toil away and no one really seems to appreciate what they do. If you buy them food (pizza, donuts, coffee) or free stuff (tech gadget, big monitor, t-shirt), they will love you for it far beyond the cost of the actual item.

There are also a few things that programmers really do not like, make sure you avoid these:

Salespeople / Being Sold - Does anyone like this? You are selling them, but be subtle. Ask for help. Enlist them. Don't sell them.

Pretending to Know More Than You Know - When people are speaking a non-native language, they often miss subtle things. I remember how my Swiss German colleagues would say "his English is perfect." No one who grew up in the US would ever say our English skills rise to the level of perfection. That's just too high and there's always more. It tips you off that the person doesn't quite get the nuance. Speaking tech to programmers is the same thing. Programmers will hear your little mistakes and if you pretend you "speak perfectly" - it will immediately lose respect with them.

Not Knowing Enough - Unfortunately, you also cannot get into a conversation with a programmer and not know the first thing about the technology. If you don't understand the basics about mobile technology, then read up on it. Admit you don't know the details, but at least get to a 101 level before you talk to a programmer.

Time Wasters - Don't talk too much. Stay on point. Only go social when they go social.

If you need more help on really getting inside the mind of programmers, two great resources are Dilbert and Foxtrot (the little kid is a budding rock star developer).

Find Your Prey

Urban Legend - Willie Sutton, the bank robber, is known responding to the question "why he robbed banks" by saying, "because that's where the money is." Turns out that's disputed, but it's still the basis for Sutton's Law.

Where do programmers hang out? The answer is that programmers are hard to find. They are generally less social creatures. They tend to cluster and don't like to talk to people who have lesser abilities (i.e., anyone who doesn't program).

Some places you can find programmers locally:

In your company or other companies. Find your dev shop. Find out who the programmers are. Visit your friends and ask them to bring you to their dev shop. Ask your friends to visit their dev shop/programmers on their behalf.

Tech Events / Meetups - There are lots of Networking Events in Los Angeles and Southern California that are techie oriented. In this case, looking for mobile developer events in the local area makes a lot of sense. But it would also be good to look for developer oriented events aimed outside mobile to look for people who might want to get into mobile. You should definitely hit up the Startup Weekend events as well. And look at StartupDigest.com

Make sure you meet the people who run these events. They often can help a lot in navigating to expertise and to possible resources.

Student Groups - Go to the local university and find out what student groups there are for programmers. Ask around for ideas on where they hang out.

LinkedIn - This remains one of my primary tools. It's a bit hard to use for this kind of request, but I would certainly go ask everyone I know to introduce me to programmers they know. And then use them to get to even more. You can certainly do this through Facebook as well, but I would use LinkedIn.

Twitter - You can run searches for various types of techie terms being used in a given geography. Follow them and reply to introduce yourself.

Sites - There are a bunch of sites out there aimed at this or similar issues. Most of them suffer from lack of activity, but it's worth a shot. Some sites to check out:

Oh, and often there are forums for particular technologies where you can look. In this case, these sites didn't pan out all that well for the entrepreneur. Part of the issue was that he wanted someone local.

Approaching Your Prey

Actually, before you approach any programmer, please keep in mind to use caution. Don't scare off your prey. Remember that programmers generally are skittish and don't trust outsiders. You are an outsider. If you come up to a programmer and just ask them to help you build your product. Game over. They will be thinking at that point - "How can I gracefully exit this conversation with my limited social skills?"

Instead think about what will motivate them. If we take the example that was the genesis here, the founder wants two types of people. He wants a person who knows mobile development pretty well who can help direct the action (the expert), and he wants someone who is a good coder who can learn to build out the needed mobile application (the developer). What will motivate these two people?

The first person (the expert) will likely be motivated by being involved in a fun, exciting problem/venture, lots of immediate rewards, not too much time commitment.

The developer will be motivated by getting involved in a fun, exciting problem/venture, lots of learning opportunity.

So, if I'm at an event that's full of prey, I will go around the room introducing myself to people (probably starting with the host) and roughly say:

"I've got a concept defined and some early customers, but I'm not sure if using a mobile framework, building native apps directly, or maybe even doing an HTML 5 app is the right way to go. Who should I talk to here who I can buy a coffee and tell them about my concept and get their input on the concept and especially on technical direction?"

This is intended to find the experts in the room. A few notes about this:

Make it clear that you've done your homework: I already have some people who want this, but I need to get it built.

Present up an interesting question: I need to figure out what my technical approach will be.

Show you also want their input on the idea.

You are willing to buy coffee, pizza as an immediate reward.

By the way, this works just fine if you happen to already be talking to the expert. By the way, if the person tells you that you should talk to a particular person then please say, that's great, "could you introduce me?" and start leaning to prompt them to start walking with you. Most often people are happy to do it and it helps with immediate rapport with the prey.

Once you are talking to a person who's been introduced as a likely expert, the language is pretty much the same as above, but you likely will get into a bit more detail and then ask them if you can get them coffee sometime. They likely will want to try to solve your problem right there (did I mention us techies like to solve problems). Resist this a bit. It would be much better to build more rapport with them.

When I'm looking for the developer, my approach is pretty similar.

"I've got a concept defined and some early customers and have someone who's helping me from a technical strategy perspective, but I'm looking for someone who's a good developer and interested in getting into mobile development."

More Resources

About Me

Dr. Tony Karrer works as a part-time CTO for startups and midsize software companies - helping them get product out the door and turn around technology issues. He is considered one of the top technologists in eLearning and is known for working with numerous startups including being the original CTO for eHarmony for its first four years. Dr. Karrer taught Computer Science for eleven years. He has also worked on projects for many Fortune 500 companies including Credit
Suisse, Royal Bank of Canada, Citibank, Lexus, Microsoft, Nissan,
Universal, IBM, Hewlett-Packard, Sun Microsystems, Fidelity
Investments, Symbol Technologies and SHL Systemhouse. Dr. Karrer was
valedictorian at Loyola Marymount University, attended the University
of Southern California as a Tau Beta Pi fellow, one of the top 30
engineers in the nation, and received a M.S. and Ph.D. in Computer
Science. He is a frequent speaker at industry and academic events.