Engineering · CTO

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

Porfirio Partida Developer at Nearsoft

January 22nd, 2015

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)?
Growth hacking isn’t about quick wins and shortcuts, although they exist. In this course, we’ll cover the six-step growth hacking framework, how to measure user retention for your business, how to increase engagement and retention, and a bunch of case studies.

Aleksandra Czajka

January 23rd, 2015

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


Ilya Stametau Senior Software Engineer at HubSpot

January 23rd, 2015

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.

Scott Brittain CTO Snap Kitchen (We're hiring!)

January 28th, 2015

One from my recent history:  allowed sales traction to divert attention from poor user adoption.  Compounded the problem by spending a couple quarters building features that increased sales traction while doing nothing for user adoption.

 

Bob Troia Entrepreneur. Builder. Creative Technologist.

January 23rd, 2015

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.

Michael Barnathan

January 22nd, 2015

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 VP/Director. Strategy | Business Development | Operations | Product | Solutions

January 22nd, 2015

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

January 22nd, 2015

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 VP/Director. Strategy | Business Development | Operations | Product | Solutions

January 22nd, 2015

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. 

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

January 23rd, 2015

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.



David Fowler Looking for opportunities, Currently part time APD Chief Engineer

January 23rd, 2015

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.