[prime0196]

Equity should be given to individuals who are critical to the success of your company, individuals who are indispensable. Too many companies give equity to individuals who can be replaced once the company becomes self-sustaining. Equity shouldn't be given to "good" coders just because they contributed in the beginning. Equity should be saved for the "great/exceptional" coders that you may attract as your business grows.

[pg]

The empirical evidence suggests startups don't work that way. All the most successful startups had great techical people from the beginning. If you don't have good technical people at the start, you never reach the point where you attract them.

[prime0196]

I don't dispute that. What if you have great technical people in the beginning who happen to have no equity stake? A talented developer is a talented developer (regardless of how they are compensated)...equity doesn't make them any better, does it?

[pg]

If they're de facto cofounders and they have no equity, then either you're cheating them (and they don't know they should have equity) or they don't have much faith in the project (and prefer salary to equity).

[mynameishere]

What if you have great technical people in the beginning who happen to have no equity stake?

They leave as soon as something better comes along. Giving them equity [with vesting] prevents that from happening. If the person is okay with just a salary, he'll go work at Microsoft or Google and additionally collect the "intangible" benefit of job security.

These aren't difficult concepts.

[nostrademons]

I was in this position in my last startup (they offered me a fat salary instead of equity), and it's a terrible position to be in, both for the employee and for the startup. Here's why (bear with me on this, there's a lot of setup):

Economists like to divide all spending into two categories: consumption and investment. Consumption is spending for things you'd like to have now, that'll give you an immediate benefit. Investment is spending for tomorrow, in the hopes that you will gain more benefits later.

Technology organizations face the same tradeoff, but with time rather than money. Developers can work on features that immediately benefit users and pad the bottom line (consumption). Or they can work on refactoring, infrastructure and tools that will make it easier to add features in the future (investment). There's always a tradeoff. If you spend too much time on investment, you're customers will wonder why you haven't done anything for them recently and stop giving you money. If you spend too much time on consumption, you'll wonder why it suddenly starts taking 10 times as long to implement each feature, why the system is grinding to a halt, and why your developers have no clue what's causing your latest dozen bugs.

In my experience, the best developers spend 80-90% of their time on investment and 10-20% on consumption. They'll apparently do nothing for 3 months and then crank out an app in a week (for an extreme example, check out PG's On Lisp: he writes a whole book on building up tools, and then in the very last chapter, he's like "Oh, by the way, here's a Prolog interpreter. In 50 lines. Done"). The worst programmers reverse that - they'll spend 80-90% of their time implementing your feature requests and only 10-20% cleaning things up, moving common code into functions, etc.

So here's your problem: under U.S. law, all "investment" that an employee creates is owned by their employer. Meanwhile, their salary is dependent upon how good you think they are, which depends upon how much they've done to improve the bottom line. In other words, they have every incentive to "consume" (push out quick features for the boss) and no incentive to "invest" (clean up code, setup infrastructure, build tools). The only way to rectify this is to make them part of the company's capital structure, so that they are effectively part-owners of the code they build.

You might think that you know better and can compensate people based on how well they actually do, but in practice it's virtually impossible. Ask yourself: how would you feel if your development team did nothing for 3 months. Because that's what it'll look like if they're doing their jobs properly. You say that you've got a terrific programmer who's working for no equity, but you're seeing him at his best. It's easy to crank out impressive stuff on a small green-field project; it's much harder to keep it working as the project grows. The choices he makes now will determine the future development of your software, even if you fire him and get someone else later.

Don't do this to your startup. If you're a tech company, spend your equity getting a top-notch tech person, then give him the discretion he needs to do things right. Otherwise (assuming you've gotten all the marketing/PR/idea stuff right), I can predict the path your startup will take. You'll get lots of buzz and lots of users, and they'll love you for cranking out features quickly. You'll dominate the market. Then, about 1-2 years in, you'll hit a brick wall, and every feature you add will result in lots of mysterious bugs. Fixing these will result in dozens of new bugs, and you won't be able to add any new features at all. Competitors will arise and start catching up to you. You'll fire your tech team, thinking that they must be incompetent. You'll start a rewrite-from-scratch project, which you'll abandon when your investors come calling. Then you go out of business.

I've gone through it once and probably would've gone through it a second time had I not just left my last employer. It's not pretty.

[far33d]

You don't think a founding coder is indispensable to your company? Are you saying that if this person decided, one week from launch, to quit, it wouldn't matter? If so, why have them on the team at all?

[prime0196]

Web applications are a lot easier to develop. I think too many people are still applying methodologies that applied to more "traditional" forms of software development. If I have a good JavaScript hacker bail on me a week before launch, I don't think it would be extremely difficult to find another good JavaScript hacker.

[matth]

This is just my perspective, but if you're hiring and treating programmers like temps, don't expect any works of beauty. They're going to push out what they need to push out, probably very hackishly (because what do they care?), and then bail with check in-hand and let the next guy deal with the mess.

That's not such a big deal with JS, but it's a very big deal when your backend is in the toilet. You may as well flush.

[shiro]

You're right about "development" part, especially for the initial feature set. I do consulting, and I estimate efforts for initial development vs maintainance as 5% : 95%. If you aim at millions of users, probably it should be 1% : 99%. It might be easy to find or replace somebody who does that first 5% or 1%. It will be difficult to find somebody who has commitment to hang on for the rest of 95% to 99%.

[sudhirc]

you are talking like a MBA and a manager. As per your learnings people are machine so you can easily replace one malfunctioning part by another.

I am not involved in any startup but like to do my job with creative energy and scripted quite a few time saver solutions for my group. Until now all my manager were thoughtful enough to allow me but this new guy thinks that he can replace any person with any person without looking at the unique attributes of each of the person. He wants me to do the work others can do without looking at what i can do and others cannot... I am sorry but you are sounding like my manager so get a job in big company. Startup make you respect your talent and looks like you do not want to do that... Coders may be dime a dozen but believe me true developers/hackers are not...