Cofounder · Technical co-founder

When talking with potential tech cofounders don't judge quickly.

Kent Hamilton Lead UI / Angular Developer (AngularJS Architect) at AT&T - (eHire)

February 24th, 2015

A couple of suggestions for non-tech co-founders when approaching potential tech co-founders:

1. Don't Judge Too Quickly
What I have discovered lately is that I am being contacted quite a bit to consider joining as a Tech co-founder. What is happening fairly early on though is that I am being compared to their "previous tech co-founder" and that failure and or success is be juxtaposed onto me. I am not saying that we should not learn from our mistakes, however I would suggest giving each new tech co-founder the same chance as you'd expect yourself and judge each one separately.

2. Don't try and access their tech skills if you have none :)
I would say start with a small piece of functionality for the potential co-founder to collaborate on and see how that goes from a relationship standpoint and what is delivered from it via the output of something tangible. If you have someone that can help access their skills then, by all means, have them look at the potential tech co-founders past code. A lot of developers though won't and sometimes can't just give you past code. For example, I have worked for,,, etc and can't just fork over sample code from them. When trying to partner for sweat equity alone remember that the developers time figuring out your business and where to enhance/write code is work in itself and don't discount that initial phase.

3. Think through reality of partnership
In the beginning a tech co-founder will put in a lot of time and effort to develop the MVP and or beta product for launch. After that you may hire staff to build out or continue the work. Don't view the initial work as just development. I have found that there is a lot of discovery, architecture and complex problem solving that is not just coding. A lot of developer I know also have great ideas and very valuable insight into growing business' as they have worked for multi-million dollar and sometimes billion dollar business' on their main products. I have worked for 15 year for many top companies and have learned a great deal more than programming to bring to a start-up. So let the tech co-founder contribute in other ways than just coding if they display that skill/gift. Developers are not just coders just like you are not just a business person. We are founders and business leaders.

Steven Schkolne Computer Scientist on a Mission

February 24th, 2015

@Kent great post. Says things that many really need to hear and listen to. One thing to add -- at the beginning, as you say, tech cofounder ends up doing tons of work. I think there's a fear, in the back of the mind of any TCF (tech co-cofounder) that they will labor for 3 months.... and then the product will release.... and nothing will happen. There is a sense that the tech investment is early, esp in ventures when a prototype is needed to vet the basic business proposition. I keep hearing "come be my TCF, build my product for me, and my business will take off my idea is so good".

A non-tech would be wise to demonstrate that they can execute, not just in talk and hype but in real ways. Bringing in money is one great way to show a TCF you can do things. Building an audience for that prototype and iterating, another. Us TCFs have a fear that we are doing all the real work. Show us the work that you're doing, and we'll be more willing to join. If you're saying "I can't do real work without my prototype" then try harder to be resourceful.

Benjamin Olding Co-founder, Board Member at Jana

February 25th, 2015

In my experience, co-founders (technical or not) do a ton of work at all stages of the company.  The work changes at different stages, but the load never does.  I think what the above posters are referring to regarding the early technical workload is the technical cofounder often doing a lot of non-collaborative, independent work up front (not that it's "more" work at that stage - just that it's work that is less collaborative with teammates).

If that's the reason you are thinking of adding a "technical" co-founder to your team (i.e. you cannot do the first implementation of the product idea and you need someone to), I think you should stop and think for a moment... that very motivation is going to screen out your most qualified possibilities.  I'm not trying to position myself as a great technical cofounder - honestly, I'm mediocre - but even I would head for the hills if that's what I thought was going on.  Let me try to explain why:

I like that co-founder & cash flow can both be abbreviated as "CF," but even if there wasn't that symbolic equivalence, I'd still view those two ideas as one & the same.  Here is part of my definition of a co-founder (technical or not): "A person who can create cash flow beyond the level of his or her incompetence."

If you already have a market, a product idea, and the belief you can probably hold down the sales and BD leadership elements of the company for at least several years, yet you cannot raise enough investment to hire an outstanding programmer as an employee, I don't want you as a co-founder.  It's absolutely fine that you cannot code - you don't need to be competent at everything as a co-founder.  However, if all you truly need is one absolutely outstanding engineer coding for one year, yet you cannot raise enough money to deal with that shortcoming on your team, you're also probably unlikely to come through with cash later.  You don't sound like a good co-founder, to me at least.

Ok, that's a little harsh - the problem is not that you haven't raised money.  The problem in my mind is that you are too myopically focused on the next 3-12 months of the technical challenge...  which means you haven't seen a technical team being built before (or didn't notice how it was being built when it happened).  You are selecting for the coding ability and hoping for the best when the MVP is delivered.  Think of it like a technical co-founder trying to hire a CEO in order to make sales numbers for the next 3 months.  I'm sure if there was a post like that, there would be a lot of objection.

A good technical cofounder can increase cash flow beyond the level of his or her incompetence.  There are two sides to the equation - either they are increasing the money in or decreasing the money out.  The two ways I know of to increase the money in are investment and revenue, with investment usually being more realistic.  So, the first screening criteria you should apply is your first impression of the person and their resume as evaluated by title and company brand recognition.  As shallow as this may sound, it can help raise money from investors.  I don't think it's very correlated with coding ability (sometimes inversely so... the more impressive the resume, the further away from the coding the person often is), but it is likely correlated with raising money.  Being able to position them as a "genius" or as an "experienced CTO" helps.

Second area is earnings, which on the technical side usually means a better product (more revenue) or cheaper product (better margins).  This could come in the form of future product ideas, better product management or better technical leadership.  I don't really know how you would evaluate this with someone you didn't know, but think of how you assess this with people you know well... then try to ask those questions of references that seem like the same type of person you are I guess.

On the cost side, here are broad strokes of what needs to happen for a web company's technical team.  Anything the co-founder is good at is less money that has to be spent, identifying, recruiting, hiring, and employing someone else to do these parts (and don't just think of the employment cost - also think of the time spent recruiting the person and the likelihood that you'll have to fire a few of these people; if none of your team can do it, I expect you to mess up a couple hires... don't necessarily accept it, but do build it into the cash requirements of your business).

1) Actual programming (engineer responsibility).  Yes, this is a real expense... but a lot of people can do it.  A technical cofounder that can't bang out an MVP for you in 3 months is not necessarily incompetent or a bad choice.  A person who can sure sounds like a good 1st technical hire, but not necessarily a cofounder.  If you're making this a hard requirement to the role, you're likely just trying to save cash for 3 months.  What is a hard requirement is the technical cofounder be able to implement an MVP with a reasonable amount of money... not the same thing.

2) System architecture (CTO responsibility).  This is how things mesh up to each other.  For most web companies, this usually has to do with how the databases interact with the server code and how either of those interact with the client or front-end code.  For some reason, almost every engineer thinks that not only can they do this, but also that they are good at it, so you cannot evaluate this by asking them.  Look for their experience with systems at multiple scales and get references for each of these scales.  Also, you don't need this really early on - it's ok to throw that MVP away.  However, there are only so many times you can throw away *all* of your code.  At the point you can't afford to throw away 100% of your code (which happens faster than you think if you're on to something on the business side), you need someone like this employed at the company, and your cofounder needs to be ok following them even when he or she disagrees if they aren't it.  This is not a design-by-committee type of task.

3) Technical recruiting (VP Eng responsibility).  No substitute for having done this before - most engineers think they have recruited before because they participated in interviews and/or were given a veto on whether a new engineer was hired or not.  The biggest challenge is the top and bottom of the recruiting funnel.  You should ask how candidates are sourced and how candidates are closed.  If you don't learn something by asking these two questions, then they don't know either - generic answers don't cut it here.  They need to tell you a tactic you've never heard of (it can be minor), or else you're going to have to hire someone else to do this later.  Also, have them full-on whiteboard interview a friend of yours who is technically competent.  Get feedback from the friend on what they thought of the technical questions that were asked.

4) Engineering management (Director Engineering responsibility).  Typical web company management encourages small teams (3-6), each with a leader and some kind of process to keep all the team leaders aligned with product goals.  This is great to have in a technical cofounder in the first 3-12 months, but rapidly becomes irrelevant a skill for your cofounder as the team scales beyond 6 or so.  Ask about their experience and opinions around this topic (again, specificity usually means competence; a 30 minute lecture on the general merits of Agile methodology over waterfall methodology does not), but don't get too sucked into thinking this is what you need.  You'll be better off with someone who can easily hire this position for you.

5) QA (VP engineering & VP product responsibility).  For some reason, this is an incredibly underrated area of expertise.  You know what's more expensive than an incompetent engineering team?  A competent one building the wrong thing.  At least the incompetent one sometimes accepts your criticism.  I don't know how to tell you to screen for this, other than be aggressive about asking questions.  Find whatever product manager the person has worked with before and grill them on the QA procedures they used before.

6) Systems administration (sysadmin responsibility).  Another wildly underrated, under-researched skill set.  The ability to code in python has little to do with someone's competence at Linux.  If someone has never coded in python before yet is a Java expert, there is 0 risk they are going to prove to be a "bad python programmer."  If they've never really had to deal with Linux outside of launching the code they wrote however, this isn't a skill they are going to pick up easily.  You avoid a ton of headaches and mistakes by having someone with this expertise in the company early on.  You don't need a technical cofounder to have these skills (huge bonus though), but you do need them to be able to identify and recruit this ability (and want to) early on.  Again, the sysadmins often get no respect and it hurts the company later on when you have a giant pile of crap you need to sort through.

Ok, well this post is way too long, but hopefully it helped someone...  Personally, I don't think I'd ever cofound a company with someone I didn't already know painfully, painfully well (like, all their flaws); but if you're committed to doing that, here's my best closing advice (which I don't believe is illegal because finding a cofounder is not the same as hiring an employee): go for someone young.  

It's incredibly unlikely you're going to get someone with the really important skills I've listed whom you don't already know: those people absolutely exist, but they like working with people they already trust - being able to hire them is already a questionable sign.  Pressure makes diamonds though... find someone young with evidence for potential on the above skills and give them more responsibility than they've ever had before.  Be positive with them, but be clear on what they need to do (and make sure they work like crazy): they've got a shot at becoming this person.  As we get older, we lose that potential of becoming a new person.  Make sure they don't have a crazy ego and think they are an equal partner in it though... not that you shouldn't treat them that way, but the only way they can learn fast enough is to be a little concerned they aren't actually qualified to be a technical cofounder yet.  If they don't know that, they won't learn fast enough.

Also, use the above criteria to find an advisor - they will likely work with you; then use them to help pick the technical cofounder from your possibilities (you'll still likely have to find the possibilities though - don't count on them pulling a name out for you) .  Be aggressive - former technical cofounders often don't market themselves as aggressively for advisor roles as former ceo cofounders.  You might be able to get someone as an advisor that is well known (or whose company was well known).  this can help you recruit.

Kent Hamilton Lead UI / Angular Developer (AngularJS Architect) at AT&T - (eHire)

February 24th, 2015

Some more things to think about:

There is a transition after the tech co-founder finishes the MVP and/or beta launch when it's go time for the business partner. So while developers do a ton of work in the beginning, the business partner should be doing the ground work to help the launch go smoothly. The business partner may be doing a ton of work in this phase. Neither partner can look at the other and keep score on who contributes what as we all have different skillsets and both are equally important. If the tech co-founder gets you the MVP and beta launch and that's all he contributes, is it worth it? Absolutely, because most startups can't even get to that goal and that is a huge milestone. What if your business idea is not really tech related but needs a web application built? After its built, much will not be needed from the tech co-founder. Is it worth it to bring them in just for that? Absolutely just like its worth paying a Dr $20,000 for an hour of his time for a surgery because he has worked for years to be able to perform and execute like a champ for that hour.

In regards to long term growth of the tech founder and the company just know that after the heavy development lifting is done up front for the MVP and beta launch there may not be a lot of coding left for the tech co-founder. I would say that the other partner/partners should be ready for a the transition period. What does that look like? The tech co-founder can then enter a role of leading and building out the development team with funding and or bootstrapped investment money or may move into a different executive role altogether.

The MVP or beta product should prove out the business model and real potential of the company. There may be a pivot on the business idea based on customer feedback. Based on where the company goes from this point can determine the path of the partners. The tech co-founder may now become the head of R&D or just lead out the development team. They may also be the growth hack expert you need. What I am saying is that the tech co-founder is usually much more than just a coder. If you just want a coder to knock out an MVP then hire a consultant or team to do that, else be prepared to grow with the tech co-founder.

Robert Woodburn Founder at Oncuray LLC

February 24th, 2015

I have two medical sites that are functional, and . Would be interesting in speaking with you regarding partnering. Bob

Alison Lewis CEO/Creative Director

February 24th, 2015

I really like this note. On point #3, what is the best way to engage a tech founder in these activities? Just ask or set it as a goal and present it?

I'd like to bring up a different issue about what about the daily chores and basic things to run a business.Things like organizing receipts, maintaining the books, or keeping up and maintaining a tech workshop.

I've had a hard time in the past getting founders to be involved with the maintenance of the company, not just strategizing. I'm always cleaning up after the tech guys and having to put things away, they leave the tech stuff all over and seem not to want to care about this part of the company. In one company, the head tech left his dirty clothes (that's right, smelly dirty clothes) piled up in the corner as with his other stuff. He's brilliant and we couldn't have done it without him, but he was difficult and frankly had a filthy workspace and personal habits.

I know finding a good fit is always a challenge, but I thought I'd bring it up as it it's something that really upsets me and seems to happen a lot more with tech teams than with my designer teams. I am sure other people have the same issues. Any ideas on how to approach this early?

Alison Lewis CEO/Creative Director

February 24th, 2015

Steven, that is an excellent point. 

Abel SPHR Director, Talent Management at CineMassive Displays

February 24th, 2015

Superior outcomes are only sustainable through respectful exchange between talented people.  Being open to other's ideas (and wiping your own butt) are small concessions for accessing other's brilliance and energy.

Kerry Davis

February 24th, 2015

@Alison. Not that I am Not (sorry for the double negative) sympathetic to your point, I hired a tech contractor once that brought absolutely no value AND left several weeks of dirty paper plates from evening meals IN HIS DESK when we fired him after only a month or two. But if the guy is so key to a startup and he has some quirks, seems to me your are better off paying $100 a week to have a janitor come in and office dry cleaning done for him. God knows the sales guy is gonna waste much more on a last minute flight to who knows where. 

But leaving tech stuff all over, and having a messy desk (and running sentences much longer than you should to make a point), is fairly common in a small start up. Ideas are simply moving too fast and messy just comes with the territory. I wouldn't advise cleaning up his tech stuff unless it is just test equipment left laying around. Tell the guy that every friday a dry cleaning service will be picking up clothes and returning them on Monday (I worked for a couple of companies that had that service even 20 years ago).

Alison Lewis CEO/Creative Director

February 24th, 2015

@Kerry. I Hear you. We have a cleaning crew every Friday. I am ok with MESSY, as I am messy too (we make wearable tech there is fabric and materials all over the place in a fast paced moment).

I think this more about knowing the other people care about sharing the little things that can wear us down when there is little money to do have others do it for us. For example, I have to do all the bookeeping, receipts & paychecks. I absolutely hate hate doing this but don't have the $$ to pay for an acct. and know it needs to be done and it helps me understand the cost of our business. Just get-r-done. 

I look to share a company with others who are willing to stick it out and do the grunt work when necessary and not have to be asked to do it most of the time. 

I find this needs to be brought up early and I am always looking for ways to articulate it better. 

Maria Brandt

February 24th, 2015

Great points brought here.
I saw these issues over and over at high tech companies, when we launched new products. To me, the key to success in any business is the clear and respectful communication about what you are doing, why, what changes need to happen and why.  It is crucial to be in the same page about the vision, and execution plan, and to be honest about the response to your product and how you can change such response.  For example: after developing the prototype: why isn't the customer reaction as expected, get the new customers, figure out solutions to the problem.  This is assuming that the groundwork is set-up, from a tech perspective is the architecture, and basic functioning prototype. From a business perspective is having a canvas, and validating the ideas initially with some customers.
Constant communicating and prioritization of these issues, is extremely important, because it exposes how well you can work with the other person.  I myself, have some issues with engineering firms that are consultants, because they don't wrap their head around your problem, but instead want you to line-up all solutions, and they execute.  However, in developing the right MVP, you need to constantly change the solutions (features, or messages) and you want the TCF to be in-line with that concept.
I am looking for a tech cofounder. The mission of my company is to make event planning easier and more efficient. It is a consumer solution (my expertise from PayPal and Google) to use technology for key processes that are mostly manual, and highly inefficient.
Please send me a message, If you are interested in talking to me.