Live data from Hacker News

Hackers with no equity in company: good or bad?

news.ycombinator.com

21–30 of 36 posts

Re: Hackers with no equity in company: good or bad?

#21
post #15

Earlier quoted context omitted.

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.

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.

Re: Hackers with no equity in company: good or bad?

#22
post #12

Earlier quoted context omitted.

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?

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.

Re: Hackers with no equity in company: good or bad?

#23
post #15

Earlier quoted context omitted.

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.

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.

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.

Re: Hackers with no equity in company: good or bad?

#24
post #21

Earlier quoted context omitted.

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.

Milestones are comprised of objective and goals. Hacking can easily be structured as either a goal or objective.

Re: Hackers with no equity in company: good or bad?

#25
post #13

Earlier quoted context omitted.

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.

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%.

Re: Hackers with no equity in company: good or bad?

#26
post #21

Earlier quoted context omitted.

>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.

Milestones are comprised of objective and goals. Hacking can easily be structured as either a goal or objective.

If you have all the answers why ask the questions?

Re: Hackers with no equity in company: good or bad?

#27
post #4

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.

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.

Re: Hackers with no equity in company: good or bad?

#29
post #9

Earlier quoted context omitted.

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]

Re: Hackers with no equity in company: good or bad?

#30
post #17

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.

"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.

Post reply on HN