One other thing to consider, besides the rational aspects to equity assignment, is fairness. People will talk about their equity allocation sooner or later and if there is a major differential between people who perceive themselves as similar (e.g., similar skills, similar job, came on board around the same time), it could hurt productivity and morale. People know the world isn't fair but they still get angry/demotivated when they are on the wrong end of the perceived unfairness.
this is brilliant point that many founders underestimate. fairness and motivation. it happens left and right when inexperienced tech founders just "calculate" equity. it might be calulated 100% corectly and co-founder might agree with it, but something will "not feel right" for him and greatly affect his performance. please pay attention.
The article likens the building of a skyscraper to the design of software. I think that the analogy here may be wrong (having made the same incorrect analogy myself).
Perhaps the correct analogy is that the building of a skyscraper is akin to copying software (i.e., building a new replica of a design). In this regard software is the ultimate engineering. Once you have the blueprint (the final source code), stamping out copies is perfectly reproducible. The program applies to many more environments than a skyscraper design.
On the other hand, designing a skyscraper is alot like writing software. The designer doesn't know what the building will look like. There is an iterative process where ideas are thrown around, design errors identified and fixed, etc.
In terms of quality measurements, the same measurements don't apply to software since each copy is a perfect replica. There is little need to measure how closely a copy reproduces the design, it is often perfect. The design may have flaws, but so may a building design.
Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"
Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"
That's a good question. Off-hand, I would say that part of the reason has to do with experience. Humans have been constructing bridges and buildings for thousands of years. As such, engineering of this sort is generally well understood. Occasionally, when working with new materials or grander scales, past experience fails, e.g. Tacoma Narrows Bridge.
There is another important way that designing software differs from designing structures. Whether a building stands or collapses is governed by the laws of physics. On the other hand, software design takes place in an entirely abstract world, where the laws that govern it are sometimes subject to change. That combined with the sheer scale of much software makes it difficulty to thoroughly reason about it.
Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"
I'd say it is that way because for many use-cases, the point where software becomes useful is much lower than it is for bridges. If my MP3 software has a bug, worst case is I have to use a different one and import my library. If my stereo has a problem, it could electrocute me.
I've contributed to several open source projects in the past (Linux kernel, gnome, etc.), but doing so is hard work, even if the changes are trivial and you don't have a reputation in the community for the project. Most recently, it took almost a dozen emails over 4 days among 3 different people to get a 3 line patch committed to a driver.
The truth is contributing to open source is a social problem. You have to get to know the maintainers, build their trust, and over time, it gets easier to get patches in. If you can meet the maintainer for an hour or so at a conference, it lowers the bar but maintainers of popular projects are often swamped at these events.
More often than not it is easier to fix the bug for yourself and move on, using git to keep up to date with new releases.
I've come down to a rule for wine - price correlates well with value in the $15-$25 per bottle range, you get what you pay for. Outside of that it seems random. Two-Buck chuck is pretty good, especially for $2. I've also had expensive wine > $50 which was, in my opinion terrible.
(This is for store bought wine, for restaurants multiply prices by 2 to 4).
There seems to be a lot of mythology around the ascetic entrepreneur. My experience is that many founders begin startups from a place of financial strength. They either made money as employees of other startups before starting their own (after the startup was funded, greatly reducing risk), made money in industry before starting their own company, had a large inheritance, etc.
Does anyone have any concrete data on the finances of entrepreneurs when they start their first company, especially successful entrepreneurs? This study is the closest data I could find. http://www.kauffman.org/uploadedFiles/FactSheet/EduTechEntr1...
It states that most entrepreneurs are older (median age 39) and have college degrees, often from good schools, and often advanced degrees. This suggests that they may have quite a bit of reserve cash to maintain much of their lifestyle, and/or a working spouse that helps do the same.
I grew up poor, extended family scraped some money together (plus me working) to put me through college, worked at a software company for 6 years, saved up, and now I'm burning my savings every day bootstrapping. Here at Hacker Dojo, every day someone walks in the door, and I hear a similar story. That's my experience. Which is clearly the opposite of yours.
I find it sad that, to this day, one has to spend so much time worrying about memory management to get decent performance. I've yet to work on a performance oriented project where I didn't need to write at least a couple custom allocators to reduce memory management overhead.
GC systems are no better in this regard. I was told of an interesting hack in a Java program that implemented a large cache of objects by serializing them into a large memory block so that the GC saw it as one big object and didn't traverse it. This resulting in dramatically reduced GC pause times (10x+). When needed, objects were deserialized from the array. Disgusting, but effective.
I call this "poke it with a stick" debugging. Let's poke the code like this and see if it works now. This approach is so wrong yet so common it's infuriating.
I think this last point is a really good one and is something that people who haven't been on the selling side don't really appreciate - it is often difficult to decide what to charge for and how much since different customers derive different amounts of value from a product in different ways.
I wouldn't say they capture all the value, they return a huge chunk of it to customers, often through lower prices. But, I agree that shrinking a $20B market to a $2B market where you control $1B in revenues at much lower costs allows you to pay employees well.
dotBen has it about right. It sounds like your startup operates in a specialized domain, so most investors won't have the expertise to understand it - which means they likely won't invest as you've discovered (and as hard as it is to believe, it turns out you don't want them to).
The startup I co-founded struggled with exactly this issue for the same reason - the company operates in a specialized domain. Just like you, customers got it but investors didn't. After about a year of fund raising (and working with customers) we found someone with the ability, desire, and domain knowledge to invest and we got a funding commit after a 1 hour first meeting. With the help of the lead/early followers, the round filled out shortly thereafter.
If you have something valuable as measured by customer interest and, ideally, adoption, hang in there and keep looking. Try to figure our quickly who will lead a round and who won't. Unfortunately, it is hard to tell the difference until you experience the process with someone who decides to lead.
