How to find a technical co-founder

This post is part of the Nontechnical Founders Series – a set of posts aimed at helping would be nontechnical startup founders get answers to their questions around the technology side of starting a company.

So you’re committed to founding a tech startup, and you know that you need the right technical co-founder to come on board to build and launch your product, right? Good. Now where do you find this mythical co-founder, and how do you know what to look for?

I’m not gonna sugar coat this. Finding a technical co-founder to partner up with you and build your product from scratch will be a long, time consuming process. Unless you have plenty of money to offer up front in salary in addition to large amounts of equity to give away, expect to spend about 2-6 months on the hunt for the right co-founder. Since you won’t be working on your product in the meantime, the best things you can do are to get smart on your business, and to contribute intelligence to the community.

The worst thing that you can do is try and recruit a technical co-founder based solely on the idea that you came up with the previous day. If you’re not really smart on the idea, and already well connected within your market, there won’t be any incentive for a technologist to join up with you and build your product for you for only 50% or less of the business.

Getting smart on your business should be a given. Do the market research, talk to as many people with knowledge on the subject as possible, come up with a set of assumptions around a strongly crafted model that will need to be proven, and then collect data on those assumptions. 

Contributing intelligence to the community is a little bit less intuitive. The easiest way to get your voice out there in the open is to start a blog. Write often about your business, your thoughts on technology, marketing, distribution, and existing business models. Comment on other well read blogs, and engage in the discussion. Aside from writing, actually participate in community events, attend meetups, speak on panels, and schedule frequent meetings with potential candidates for the co-founder position.

You’ll meet plenty of these candidates through the startup community in your city if you put the time and effort into immersing yourself into the experience. Contact people from the online communities like Hacker News, email people you’re connected to on LinkedIn, set up followup meetings after you meet a potential candidate at a meetup. 

 

When you actually talk with technical candidates, how will you know you’ve found the right one?

First of all, look at what they’ve already built. This will be the best evidence of what they’ll be able to build again. If it looks like, sounds like, and acts like the product that you want to launch for your business, then that’s a great sign.

Secondly, ask them what their specialties are, and what they contributed to their previous projects. At the early stage of startup life, it’s important that you hire generalists and not specialists. That means that you’d rather have someone who’s built an entire application from beginning to end, instead of someone who was pigeon holed into just working on the design, or the front end, or the database, or the API. A key word to use here is the full stack. This means that they’re comfortable working in almost every area from the database all the way up through the front end design. The right technical lead for your team will have worked on all of them a little bit. They needn’t be an expert at any one area, and in fact they may be really weak at certain areas, but they need to be confident that they can at least find the right person to help them out when needed.

So if the candidate seems to get along well with you, they’ve built something interesting before, they have the commitment and tenacity required in a co-founder, and they seem to have confidence in their own technical ability, do you sign them on the spot? No. There are still two more steps that I’d recommend. 

You’ll want someone technical who you know and trust to interview them to vet their technical ability. Your trusted friend will be able to dig deep on technical ability to make sure that they really will be able to live up to what they told you they will. Even if they pass this test, I recommend you’ll want to work with them at least on a trial project to see how the two of you work together. Pick a small project (it can be unrelated to your business), and you work on the business related strategy while they work on the technical side. After a few days if everything still feels right, it might be a match.

I’ll leave you with a high level checklist. All of these needn’t be fulfilled, but the more that you can check off, but more likely the long term partnership will be successful.

  • They’re highly technical
  • They have active projects online that they’ve built and can show you
  • You get along personally (don’t need to be best friends, but at least need to tolerate each other)
  • They’re a good communicator
  • They’re around your age
  • They’re located in your city
  • You have similar financial needs over the coming years
  • They come with strong references that you can check out
  • You both have similar goals about what you want out of the company 

Good luck. As a highly technical developer who’s joined up as a co-founder with a nontechnical partner, I can vouch for all of the above from the side of the person who’s being recruited. Disagree or have any thoughts? Let me know in the comments or on twitter.

Do I need a technical co-founder?

This post is part of the Nontechnical Founders Series – a set of posts aimed at helping would be nontechnical startup founders get answers to their questions around the technology side of starting a company.

Do you need a technical co-founder? The short answer is yes.

Jobs-woz-garage

If I have one piece of advice for an aspiring nontechnical startup founder, it would be to find yourself a technical partner. Nothing will accelerate the process of getting your product built, shipped, iterated on, and improved than having core technical talent within the founding team. This is hardly an original idea, and it is often preached around the tech community these days.

But why is this so important? Can’t you just hire a technical employee or outsource development?

You can, but it will be slower, more expensive, and far more unreliable than having a partner who has the knowledge, drive, and incentive (being a partner in the company) to put out the best product possible. 

As an early stage founder, presumably on a tight budget, your goal should be to get version one of your minimum viable product (to be discussed later), launched as quickly and cheaply as possible. Until your product is out in the open and you’re getting feedback from your users, you don’t even know whether you’ve build the right product. Sure you could get an agency to build your prototype within your budget, but after you get feedback and need to make changes, the bills will start to add up. It often takes many iterations to get the product on the right course, and iterating on a per-hour or per-project budget is not the way you want to preserve capital in the early stage. For this reason, I’d advise that outsourcing your product to an agency is the worst way to launch a business.

Hiring a technical lead, who’s not a partner/co-founder, is a slightly better alternative. If you have the funding to do so, and you find the right candidate who’s willing to be incentivized by salary instead of equity, then this can work. There are at least three reasons I can think of why this is subpar to having a technical cofounder. It’s going to be more expensive cash wise, the employee won’t be as incentivized to work above and beyond their expectations of what they consider standard, and they’ll be far more likely to leave when a better offer comes around.

But having that right technical partner will pay dividends many times over in the early stage when your product gets prototyped, released, and iterated on a daily basis. When you want to test something out or try a different direction, your co-founder will say “can-do” and you won’t have to worry about making the stressful decision about whether to put another 5-10K against an agency developed prototype feature. Imagine this scenario playing itself over time-and-time-again in the early days of your company, and trust me, you’ll be glad that you have a technical partner to go to battle with.

Of course it’s important to find the right partner, and not just settle for the first one that comes your way. What should you look for in a partner and how will you know when you’ve found the right one? More on that in the next post.

If you’re interested in following along with the Nontechnical Founders Series, or know someone who might be, you should subscribe to stay up with future posts, or follow me on twitter.

The Nontechnical Founders Series

Do I need a technical co-founder, and where can I find one?

How long will it take to launch a product?

How do I recruit and interview developers? 

How do I know what programming language to build my startup’s product in?

 

As a technical startup founder in New York City, I get asked these questions and many like them all the time. There are a lot of smart, young, ambitious, first-time entrepreneurs without any technical background, who seem dedicated to building a tech company. I admire their ambition and their willingness to learn, so I’m always glad to help. 

A large part of building a tech company is the technology. It’s very important. There is of course, a large part completely unrelated to the technology – the strategy, marketing, fundraising, recruiting, and so-forth. These are all great roles that the nontechnical founder can excel at, but I truly believe that the core of an early stage tech startup is its product, and without some semblance of knowledge surrounding the technology piece, you’ll put yourself at a severe disadvantage. 

I have a technical background. A computer science education, a passion for learning and playing with new technologies, and a history of launching products quickly. As such I’d like to write a series of posts dedicated to helping nontechnical founders get up to speed on the technical issues they may be faced with in starting a company these days. Note that I say “starting” a company and not “growing and selling a company.” Unfortunately I won’t pretend to yet have had that experience, and as such I won’t get unsolicited advice about things that I’ve yet to test out myself.

 

Table of Contents

1. Do I need a technical co-founder?

2. How do I find the right co-founder?

3. What technology should I use to build my product?

4. How long until my prototype will be ready?

Coming soon – What should I do while I’m waiting for the product to be ready?

 

Every time I add a new post to this series I’ll update this page with the link.

If you’re interested in following along, or know someone who might be, you should subscribe to stay up with future posts, or follow me on twitter.

 

Viral, Open, and Consumable – Twitter Annotations and the Social API

Sprint-twitter-birds

Twitter’s big announcement this week about annotated tweets and the new metadata that developers will be able to attach to tweets is a welcome one. This means that tweets about music will now be able to contain information about the artist and song name, tweets about finance will now be able to contain semantic information about the stock symbol and price, and tweets about sports will now be able to contain the teams and score, just to name a few examples.

While this will no doubt enhance the information and usefulness of any single tweet, it is also a two way street. There are no declared standards around how to use and interpret this new metadata, and therefore companies and developers can very quickly go down a confusing hole of creating protocols which conflict with those created by other companies and developers. It has been suggested that Twitter itself act as a somewhat benevolent dictator and help standardize certain popular usecases (defining the metadata format for stock based tweets for example), however Twitter has said that it will take a step back and instead look to see what emerges from the community around this role. And I think this is a good thing.

Metadata in tweets is only useful when there are two parties or more who agree to use it in one way. One party can attach this data to any tweet that their applications produce, and another party or product can consume these tweets and use the information in a meaningful way. Sticking with the stock example, someone could build a desktop stock ticker application which scrolled stock prices using current tweets about the stock within a hover effect. This only works if the company building the ticker app knows the standard metadata format that the applications producing the stock related tweets will use. Twitter won’t specify this format, so I believe there is room for the early movers in the space to create the standards themselves, and thereby create a social API in the process.

What is a social API in this context? It’s an API embedded semantically within the context of a social message. In this case, a tweet is a social entity which moves through the internet passed from friend to friend. But when its underlying data conforms to the API specification as well, it is also creating a platform upon which other services can be built. 

It is at once viral, open, and consumable.

What are the advantages to creating a social API in this manner? You are establishing a new content consumption mechanism with your service as the platform. If useful, it is already spreadable purely by existing in the twittersphere. You’ve done all of this without coding your own internal API, access points, error handling, or monitoring.

What are the disadvantages? There are a couple. First off, you’re pretty constrained by a lightweight API. I don’t believe we know the limits yet on the size or structure of the data you can include within an annotation, but it likely won’t be enormous. Second, by outsourcing your API to twitter’s universe you are making yourself replaceable. Anyone else could annotate their tweets with the same standard you defined, and they would be equally as consumable as yours. In this case, your content would have to be unique enough and important enough to remain relevant.  

Exposing a social API via annotated tweets surely won’t be for every service, but I’m interested to see those that step up early and pioneer new ways of consuming content that haven’t yet existed.

 

For more unnecessary insight, you should follow me on twitter.

Intuit + Mint made my life surprisingly easier

Intuit_mint

When Intuit purchased Mint I was pretty worried that one of the most useful web apps was going to stop evolving and gradually get absorbed into the Quicken/TurboTax behemoth. So far, to my surprise, the opposite has happened. Mint has continued to evolve, has rolled out new and useful features, and has continued to make tracking my finances enjoyable instead of burdensome.

Last night I sat down to file my ’09 taxes, and used TurboTax’s online edition. It was impossible not to feel the Mint influence. First of all, the process was interspersed with Mint ads that didn’t exactly feel like ads. Instead they felt like favors. In typical Mint fashion everything was posed as money-saving offers, ranging from tax deductions to IRA contribution offers. Not once did this seem annoying, and instead, it opened my eyes to money saving opportunities. Well done.

The second way that I felt the Mint influence was with regard to the automatic importing of tax documents and tax information. I’m not sure whether the Mint team influenced this (functionally or design wise) within TurboTax, however the process was very Mint like. Instead of entering my W2 and 1099 information tediously by hand like I’ve had to do in the past with other online tax tools, I could simply enter my online bank credentials and TurboTax magically pulled in all the data within seconds. Major time saver.

Big ups to Intuit for taking the ball and running with it. Hopefully the Mint team stays in tact and Intuit looks to it for product guidance going forward on TurboTax, Quicken, and its other products.

Sharing the iPad

Love the iPad. Here’s my biggest feature request for version 2:

I’d like to be able to share it. 

OS X has separate accounts, so that different members of a family or office can log in, sync their email, sync their iTunes, photos, and content. They can save their documents in different spaces, and they can arrange their desktop and their applications to their liking. The iPhone lacked this ability, as there was only one user space. This was completely acceptable however, because people generally carry their own phone, and don’t necessarily care about sharing a phone with their spouse or children.

The iPad on the other hand seems like a device that is meant to be shared. It’s to be used around the house not only as an entertainment center, but also as a newspaper, an e-book reader, and a social media hub. However right now it’s restricted to only one user space. If I sync my email with iPad mail, then my wife can’t sync hers. If I sync it with my iTunes and kindle account, then we can only access my content and not hers. If I sync it with my twitter and facebook, then it’s useless to her in interacting with social media. Sure some of these programs support multiple accounts, but then you get into complexities around usability and privacy.

I’ve heard a lot of talk about people clamoring for background processes, or a built in camera, or flash support in future versions, but I’d just like to put multi-user support on the radar as well. A family of 4 shouldn’t need 4 iPads just so that everybody can check their email.

Making thank you notes modern

Formal_thank_you_notes_card-p1

Right now thank you notes are necessarily old fashioned. They show that you care. If someone can take time out of their schedule to attend your event, and spend their own money to give you a gift, then it’s important and necessary to show them that you appreciate it. 

 
The way that we show this gratitude is to write out a handwritten note of about a paragraph in length, stuff this note into an envelope, address it to the recipient, slap a stamp on it, and send it through the mail. This could easily be accomplished in far less time, for far less money, and for far less impact on the environment through a digital medium (like email). However, this just wouldn’t carry the same sentimentality, or indicate as much gratitude quite yet. Society isn’t ready to accept that someone really appreciated the gift and time that were given if the note isn’t handwritten.
 
I’d like to think that this transition is inevitable at some point however. Many people have always fought the digital migration of things like newspapers, books, invitations, and it’s only a matter of time before the thank you notes migrate as well. Maybe there’s something we can do to speed up the migration. Here’s an idea.
 
Create a service that makes a digital thank you note more meaningful, sentimental, and valuable than a paper thank you note could ever be. Instead of handwriting a paragraph long note,record a 30 second video personally thanking the person for their individual gift. Maybe attach a photo of yourself using or enjoying the gift. Most people wouldn’t be savvy enough to sit down at their computer to record, edit, compile and attach a video/photo/note, but I think a streamlined online service could be very valuable at automating all of this.
 
Imagine you have a grid where you enter each person’s name, email, and a brief note. When you’re ready, you press go, and the site steps you through recording your 30 second thank you video using your web cam. After you’re happy you submit your notes, and the service files off a beautiful pingg style email to the recipients complete with your note and a link to your personal video. It’d be interesting to see whether the general public would appreciate this more or less than a handwritten thank you, but I know personally I’d be a lot more entertained by a nice short video than I would by receiving another piece of mail.