Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

What are the biggest mistakes you've made as a technical cofounder?

I'd love to hear from people who are/have been technical cofounders or just in engineering management positions about the things they learned as they went that maybe other entrepreneurs can avoid. I'm especially curious if the majority of learnings are on the technical side (e.g. would have used a different platform or language) or more management/people based (e.g. would have hired differently)?

13 Replies

Michael Barnathan
1
0
Michael Barnathan Entrepreneur • Advisor
Co-Founder of The Mountaintop Program, Google Alum
As a co-founder, and not the founder of my own startup (having done both at different times), I would have insisted on more control of the product roadmap, instead of leaving that control with the rest of the (nontechnical) founding team. Taking directions from someone who had no idea how the product or the development process worked was extremely frustrating.

Also, I would have been more cynical and realized that there are a lot of scumbag founders out there sooner. (i.e. been more selective about the people I worked with).
Chris Carruth
0
0
Chris Carruth Advisor
VP/Director. Strategy | Business Development | Operations | Product | Solutions
Now that is a loaded question, and of course, the right answer is "it depends".

In contrast to Michael, I have seen:
a) cases, close up, where the founder maintained such close control of all decisions that he doomed the company to failure;
b) cases where the founder felt he "was the market", to the extent that he dismissed research to the contrary and the company cratered;
c) a case where a room full of incredibly smart tech guys debated which app to create first...without having any idea whether any of them could ever turn a dime of revenue, but hey, aren't these cool!

So regardless of situation make sure you have a team that understands ideas are great, but an idea that won't "sell", no matter how carefully executed on, is only that - an idea...with a lot of angry shareholders behind it.

Chris
Michael Barnathan
0
0
Michael Barnathan Entrepreneur • Advisor
Co-Founder of The Mountaintop Program, Google Alum
I never said the tech cofounder got a pass on understanding business drivers and markets as well :). Ideally, a founder knows both the market opportunity and the product development that needs to take place to fill it, or involves people who know each side in a collaborative process.

Too much founder control / not letting go does become an issue later on in the lifecycle of a startup.
Chris Carruth
0
0
Chris Carruth Advisor
VP/Director. Strategy | Business Development | Operations | Product | Solutions
Agreed, or at least that's the way it should be. Tech's control of development, working with a sharp business mind who has in-depth experience in business models and consumer insights, is the founder's best way to mitigate product risk. I think founder's do not typically really understand the issue of risk and how seemingly innocent actions can raise the risk profile to way beyond what it should be, even in the early stages.

Aleksandra Czajka
3
0
Aleksandra Czajka Entrepreneur
Freelance Senior Software Engineer, Developer, Web Developer, Programmer - Full Stack
Mistakes I have seen many start-ups make, not necessarily the tech co-founder themselves, with regards to technology a few common ones...

1. choosing technology because it will be faster to build a particular prototype not considering the future. And, I don't mean the vast future, but the immediate future. Everyone says to build your MVP fast, see if it works then re-build. Well, my friend, that is a huge waste of time. I say this with the idea/fact that building an MVP in one language over another might be a little faster here and there and depending on who's building it, but it won't make that much of a difference. I mean, are you guys planning to win? If so, then you would plan for when that win happens. And if you choose technology like ColdFusion because it's fastest at the beginning, you will be re-building and re-investing efforts very shortly in case of a win. Not to mention you will have a hard time finding awesome, start-up minded, tech-minded technical members.

2. not having a tech co-founder that is in-fact a co-founder and not just a free/hired gun, chugging along for equity. Don't let your business partner act like your boss with regards to technology. Sure, justify your tech decisions with him just like he should justify his business decisions with you. But, don't get to the point where he chooses ColdFusion because he heard it's the fastest. You are an equal part here. Don't forget that.

3. choosing the right people as your team, even contractors. At the beginning, start-ups want to hire the cheapest. Big mistake. A mistake that will actually end up costing you more than hiring the right talent for the right price. You will end up with crappy code and it will be hard for you to get any good people involved with it. You'll end up re-writing and losing time.

Mistakes I've made:

1. accepting a deal where i work for equity right off the bat. If someone is searching for a tech co-founder and doesn't want to pay them to build the MVP, it tells me they don't believe in their idea. It tells me that they're saying, well, it could go either way, so, might as well not waste any money on it. Well, that's not a very respectable thing to do, is it? And doesn't give me confidence in the success as it puts the co-founders in a no-binding agreement with the start-up, meaning, the co-founders will not be devoted to the success of the company as much as they would be if they were monetary stakes.

Hope any of that helps.
Best,
Aleks


Bob Binder
0
0
Bob Binder Entrepreneur
Member of Technical Staff at Software Engineering Institute | Carnegie Mellon University

Avoid technical fads; be conservative in your technology and platform choices - no oddball languages or open source stuff that is coolness for its own sake. Stay in the safe zone of Java, C++, or C# and their stable infrastructure. Don't make unforced errors that drain energy and distract from product value. Here's the story my use of Tcl http://robertvbinder.com/what-i-learned-building-a-software-product-with-tcl/that illustrates the point.



Bob Troia
2
0
Bob Troia Entrepreneur • Advisor
Entrepreneur, Founder/CEO, Emerging Technologies

One mistake I've seen is over-committing to a given technology stack. From languages to frameworks to libraries to tools, what's popular/hot today may fall out of favor in the future - better solutions come out, developer communities move on and code is no longer maintained. Regardless of the technology you decide to use today, my advice would be to always keep an eye towards the future and think about how you could modularize your system in a way that allows you to swap out out pieces and easily adapt to changing (and often yet-unknown) needs.


Another piece of advice would be to sit down every 6 months with your engineering team and say, "based on what we've learned to date, if we were to build this again from scratch, how would you approach it"? In some cases, you may be able to start implementing some of these ideas into your current solution, and at the very least begin laying the groundwork for a fresh v2. We can all agree there's a big difference between building something new (fun!) and maintaining existing/legacy code (not fun!) :)


And lastly, don't re-invent the wheel if you don't have to. These days, most of the heavy lifting has been done for you already. If your team needs to spend weeks implementing your own proprietary OAuth/database/Javascript UI solutions then you might want to rethink your architecture choices.

Ilya Stametau
3
0
Ilya Stametau Entrepreneur
Senior Software Engineer at HubSpot
1. Focus on people over technology. Build the team that can:
a) create value
b) grow sustainably

common mistakes:
a) valuing raw technical talent over interpersonal skills
b) only managing down, and not managing up and sideways

2. Use technology to move the needle for the business as a whole. What "moving the needle" means should be well understood and agreed upon by every single person in the company.

common mistakes:
a) dividing the company into business and tech sides too early
b) trying to solve problems that don't exist or don't matter
c) worrying about scale too much too early
d) prioritizing universal design over incremental learning

3. Technical components that you design should satisfy JUST 2 requirements:
a) they should provide for the cheapest and fastest way to achieve present product requirements given the resources and talent at hand
b) they should be localized and easily replaceable without requiring massive refactoring

everything beyond that is a waste of time.

Lastly, always remember: EVERY SYSTEM IS A HUMAN SYSTEM FIRST.

David Fowler
0
0
David Fowler Entrepreneur • Advisor
Looking for opportunities, Currently part time APD Chief Engineer
Married to your business partner/cofounder...
Consider very critically your partner/cofounder. It will be very hard to separate yourself from your partner when the business is profitable. Ask questions like how would you handle a situation where you were contributing far more to the success of your company then this partner etc.. Be a serious devils advocate, discuss this with your perspective partner. If they can't see a reason for concern and you do,You may actually be setting yourself up for a bad future.

I suggest that you have a partner that is reasonable about the notion that a founders contribution to the total success is on par with their ownership.
David Fowler
0
0
David Fowler Entrepreneur • Advisor
Looking for opportunities, Currently part time APD Chief Engineer
Delusion....
Delusion Is a reality. Make sure you evaluate yourself very carefully. We are all Delusional to some degree, have more confidence in our abilities then we actually deserve. I think this is healthy but you must be good and knowing your own limitations and judging others.

The key thing here is that you can not judge your own level of delusion. if you are delusional about your skill at X, you will always figure that you are good at X. You need an outside trusted party to give you an honest evaluation.

When you are hiring someone, you are not likely to be qualified to evaluate that person. Usually you are hiring a skill that you don't have. Maybe you are a business guy needing an engineer. Find a way to get a trustable evaluation from someone else you can trust to have knowledge in that domain. At the very least, a third party with no conflict of interest.
Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?