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)?

Aleksandra Czajka Freelance Senior Software Engineer, Developer, Web Developer, Programmer - Full Stack

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

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

Contracts...
Working up a contract can be a PIA but it is very important and deserves a lot of effort. You may think it's OK, you and the other party really do understand what's needed, the paperwork is a formality, we have a good handshake, etc...

Consider what happens if the other party was replaced by someone you did not know, and that this party wanted to get everything they could from you.  This will happen between businesses if one is purchased. You ( or the other party if you are bought) will be left with your vague contract and a hostile partner.

Having a good contract is not an easy thing to do. There is a reason these things look insane with all the wording and boiler plate. Don/t be afraid to discuss this with the other party.

Anonymous

January 23rd, 2015

built a perfect system, just to find out there was no demand.

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

January 23rd, 2015

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.