Hackers with no equity in company: good or bad?
Does YC frown upon applicants who have hackers on their team but hold not equity stake? How should they be included in the application.
35 comments
I trust that you're not going to complain if they quit your project for a project that does offer them equity.
FWIW, no one is indespensible in a startup; some are merely harder to replace than others. I'll bet that "original idea" guys are getting equity even though they cease to be indespensible.
FWIW, no one is indespensible in a startup; some are merely harder to replace than others. I'll bet that "original idea" guys are getting equity even though they cease to be indespensible.
"no one is indespensible in a startup"
I have been in too many startups that died because they lost or failed to recruit one particular person---or in the case of LMI survived (for a while) because I recruited one indispensable classmate who made their LAMBDA processor work---to believe this.
A reverse example would be the receiving clerk at Intel who single-handily almost killed them as mentioned in Chringley's book.
In my experience, just about every founder of a startup is "indispensable" after you shake things out a bit---make a single mistake with any of them, and you're not likely to survive.
I have been in too many startups that died because they lost or failed to recruit one particular person---or in the case of LMI survived (for a while) because I recruited one indispensable classmate who made their LAMBDA processor work---to believe this.
A reverse example would be the receiving clerk at Intel who single-handily almost killed them as mentioned in Chringley's book.
In my experience, just about every founder of a startup is "indispensable" after you shake things out a bit---make a single mistake with any of them, and you're not likely to survive.
The fact that a startup dies when someone leaves doesn't imply that said person was indespensible.
I am relying on "inside information".
I suppose that means this is an "appeal to authority", but, still, if a person critical to making software work is gone, and the company fails specifically because they can't make their software work, what else am I to assume?
(Needless to say, sometimes I've been that person.)
I suppose that means this is an "appeal to authority", but, still, if a person critical to making software work is gone, and the company fails specifically because they can't make their software work, what else am I to assume?
(Needless to say, sometimes I've been that person.)
I'll buy that a company can be set up so it is dependent. Outside of some special cases (subset of technology and relationships), I think that doing so is usually unnecessary and the "indespensable" label is typically untrue, especially when it comes to biz folk.
Would it hurt to throw them a couple percent?
What would be the reason for "throwing" them an equity stake? Many people believe this makes a person more dedicated to the company, which is absolutely false.
Then why do you think startups have such a thing as options? Do you think everyone else is just mistaken in believing that equity matters in startups?
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.
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.
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?
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).
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.
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.
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.
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.
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?
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.
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.
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.
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%.
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...
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...
A word of caution...100% of zero = zero. If you spend so much effort trying not to share equity with anyone, you may end up owning all of nothing.
If you are paying someone to work an 8 hour day, no problem just paying the programmer.
But if you want someone to work a practically unlimited number of hours as is most often the case then you are going to either need to pay the person to work two 8 hour shifts, hire additional programers, or give the programmer some equity in the business.
But if you want someone to work a practically unlimited number of hours as is most often the case then you are going to either need to pay the person to work two 8 hour shifts, hire additional programers, or give the programmer some equity in the business.
They are paid based on a milestone. Milestone is spec'd out and they are paid based on attaining that goal. So technically I do get unlimited hours.
>Milestone is spec'd out and they are paid based on attaining that goal.
Hacking doesn't work that way; software engineering does. If you don't understand the difference, your startup is in trouble.
Hacking doesn't work that way; software engineering does. If you don't understand the difference, your startup is in trouble.
The only way I see this as possible is if you sit down with a "front end" graphics guy and create every page. Then have the programmer put the code behind it.
But beware the code that is written it will be hard for another programmer to pick up on. Everyone writes code differently and it is just suprising in one language how many different ways there is to create a solution.
But beware the code that is written it will be hard for another programmer to pick up on. Everyone writes code differently and it is just suprising in one language how many different ways there is to create a solution.
Make it vest and you've got nothing to lose...
Why do you think that is false?
There are too many other factors that come into play when it comes to selecting a good co-founder/equity holder. Things such as vision, rapport, dedication, etc. Equity/options are too compensate someone that you want in your company when you don't have the financing to pay them what they are worth.
[deleted]
you will not get accepted.
I think hackers are a critical component of technical teams and therefore should be rewarded with equity/options.
The verdict: "bad" - but what did you expect from this site?