11–20 of 69 posts
This statement is potentially an indicator that you're not great at fairly measuring others' contributions.
> This fear gets amplified when the co-founder is not a technical person, which means I'll certainly need to take care of the development aspect myself, while the other person focuses on the business aspects, which in my opinion are much less demanding on software related projects. This statement is potentially an indicator that you're not great at fairly measuring others' contributions.
If he's doing all the code AND most of the pitching, I think that his fear is justified.
If he's thinking that the code is more important than the business early on...maybe. Both need to be there in spades but there are probably more good business people floating around than there are coders.
What he probably wants is a business unicorn who can either code or at least understand data normalization - and why not, higher success rate that way and lower co-founder friction.
You only cofound a project with someone you have worked a long time with and already know things will be balanced. There are many more details to this incredibly interesting question.
You can only find out how the dynamics of the team will work once you try it, so work with people you already know, or try out new people for an extended period of time before comitting.
[0] Http://slicingpie.com
If you must absolutely have a co-founder, then I would find someone else who is technical. Their skillset should complement yours, i.e. if you are a GUI developer they should be a backend developer. Of course finding a developer who is serious is another matter. Most people talk big when it's just an idea, and they are fantasizing about the success like one does with a lottery ticket. It's quite another thing when you have to keep at it, like I have alone for almost 2 years.
1. You don't. This is a legitimate fear. You get through it through communication. You say to the other person: "In the past, when I've co-founded projects; I felt I was doing a lot more than my co-founder. For instance, once we had the prototype done we started pitching it to clients, but for every 10 clients I pitched the product my co-founder would pitch to 1. I decided to abort the project as I didn't want to do…
> As an aside, the best co-founder relationships are formed on complimentary skill sets. You can do what they can't (or struggle with), and vice versa. As such, I would encourage you to find a sales person/designer/hustler, as opposed to another developer. On the face of it, this advice seems reasonable. But this advice will result in precisely the asymmetry to OP is worried about. If you have a technology product, I…
You found a terrible co-founder. A terrible co-founder, business or otherwise, will generate terrible outcomes.
One thing that is very important to understand is that a great business co-founder is as rare (if not rarer) than a great technical co-founder. If you happen to find someone like that, having an attitude that they won't do any work, and they won't "do much meaningful work", will not endear them to you.
If they're a great business co-founder, they will have nearly unlimited options, much like great technical co-founders. They might also have great market knowledge, plenty of inside connections, and experience on what to do, and how to do it. And as you brought it up, experience on how to get to product market fit. All of which is invaluable. Further, and please don't take this the wrong way, but their experience in connecting with and evaluating people might have prevented you from choosing the clearly incompetent person that you ended up selecting.
There's innumerable scenarios we can concoct but I think the point is that there's no industrial-labor model for quantifying "effort" in a knowledge-based business.
As a software developer my value increases exponentially beyond the menial tasks I face at my job as I learn to curate good ideas, cultivate processes for generating new ones, and avoiding bad ideas. Any attempt to quantify my value based on lines of code, number of repository commits, or any other indicator is essentially meaningless without context. I may only make a single commit after a couple of weeks that changes two files and less than a dozen lines of code... but the network effects of the efficiency I just introduced allows to process N^k more data points per second which may pad your bonus with a couple of extra zeroes in the next quarter.
So I would recommend:
1. Learn how to value people differently. They bring more to the table than just a warm body.
2. Model the contractual obligations and profit sharing based on the core values of the business. Does working 1 hour have a directly positive impact on profits of some constant (or near-constant) amount? Split profits on hours worked. Is it more ephemeral based on the experience and qualities of the individual? Split it based on responsibility and risk (as a rule of thumb).
> Practical Aspect: How do I structure things with my co-founders. Have a written scorecard with specific team member accountabilities, review weekly. The People Component, getting the right people in the right seats will be a your most critical task. It's helpful to understand your core strengths vi-a-vis your co-founders. And making sure everyone is operating in areas of their unique abilities. Recommend reading Tr…
This seems like the business equivalent of judging performance based on lines of code written.