One of the most asked questions by non-technical people in the startup space is “How can I find someone technical to work with?” or better yet “How can I find a technical co-founder?”
People ask it so often that it sort of becomes an annoying joke. Technical partners aren’t “found.” They just happen. Technical people don’t want to work with someone looking for a technical partner. They want the person who can demonstrate that they can get things done. Begging and asking developers to be your technical co-founder is pathetic and devs can spot this from miles away.
In my experience, here are the two best ways to find your technical life partner:
1) Work at a Startup
Forget about your own idea for a year or two and go work for a company that has already raised a series A or B (ie they can pay you a salary to live). You’ll have a job, you’ll learn how to run a company, you’ll befriend the technical team and much more. Spend time with the technical team. Actually bond with them. Take the time out to get to know all of them and see if anyone blends with your style of work (i.e. works late nights, morning people, etc.).
It’s not a guarantee but many companies have emerged when a design/product/biz person and a technical person leave a company where they met to work on their own thing. If you don’t find someone from your company, you should try to meet other engineers at other friendly companies (friendly here means that you might share an investor or are based in the same building). Be flexible when looking around for your technical life partner.
Also: You need to make sure you are also doing your job and doing it well. You can’t focus all your time on this, but it’s okay to have it on your goal list of things you’d like to gain from working there. If you don’t do a good job and only focus all your attention on this stuff, you will lose.
2) Hackathons + Meetups
If you don’t meet your technical-life partner at the office, you should be attending hackathons and technical meetups. There are good ways to go about this as well as bad. You don’t want to be the person going around looking for technical co-founders at these events. You want to be the person wanting to learn more about a technical language (for meetups) or looking for teammates at a hackathon (you can offer your product/design/biz skills).
You need to go where the wild things are, namely places developers hang out. Hackathons are the best. It’s 24 hours and you get to really learn if this person works well with you. On top of that, once you do find your technical life partner (whether it came from in the office or outside), you should go to hackathons together as a motivator to work and to have time together. If you build a cool project together, you may even win a prize that weekend. There are hackathons almost every weekend in SF and NY, so there is no excuse that you can’t attend one.
Finding your technical-life partner is no easy task. Most people never find theirs. Other times people find a technical partner and then realize it is not a good fit (which sucks). I think the two ways above are good places to start.
Any other suggestions?
This past weekend we had a Dwolla hackathon in Iowa that we dubbed the Old MacDonald Hackathon. It was a blast and I was really happy to help organize it with the team.
Before the Old MacDonald Hackathon, we organized a bigger hackathon at the end of the summer called eCommerce Hack Day. This was 300+ people, 25+ companies, build-whatever-you-want-that-relates-to-eCommerce, and one hell of a weekend.
The idea of the Old MacDonald Hackathon was that to be considered for the prizes (a cow, a pig, and a rooster— yes you read that right) you needed to use the Dwolla API in your project. We held the hackathon at our main office, had over 100 people RSVP for the event and ended up with 12 awesome projects (about 50 developers in total). High quality awesome projects. I was super impressed with the caliber of teams and execution. We had a team fly in from SF (update: shoutout to team Ultapay!), a few come from Kansas City, and a bunch of homegrown developers.
Anyways, due to the success of the event and the quality time our developer team spent with random engineers learning more about their needs, I think we will see this becoming a quarterly event. I would definitely recommend that other API-driven startups start hosting smaller, API-specific hackathons. From the feedback we have received so far it definitely pays off.
If you release an API and expect everyone to jump all over it from Day 1, you need to dream on. Building and nurturing the developers using your API takes time.
Here are a few things you can do to get people to use your API.
1) Launch the API with a few companies already using it
Before the API is complete you should start talking to the companies that would benefit from your API the most. Get them interested and convince them to integrate or use your API for the launch. This will do a few things, a) legitimize the API, as people are using it b) create a ripple effect of companies integrating c) press and increased awareness of both your API and the companies that have integrated.
2) Get a good sense of features people want from the API
You may not get your API correct on the first launch. It may be missing a few pieces for some bigger companies to start using. Go out and talk to prospective partners and ask them what they need. Don’t build one-offs, only build if there are multiple big opportunities looking for a specific feature from your API. Build for the masses.
Hackathons are a great way to showcase your API and get feedback from developers in the field. If you are new to the hackathon circuit, I would recommend getting the lowest level sponsorship, demo’ing your API, preparing a workshop, offering a unique/cool prize for “best use of your API,” and hanging out at the hackathon talking to developers. This will give you priceless feedback on your API.
Dwolla and Etsy organized eCommerce Hack Day yesterday. It was awesome. I’ve written posts about hackathons before, but never about how to win one. After starting and running Photo Hack Day 1 and 2, and being involved in 5-10 more hackathons, I think I now have the experience to point out some do’s and dont’s for hackathon winning.
- If you are a good developer, team up with a designer. If you are a good designer, team up with a developer. You need both to be successful at the hackathon. This past week ShopPapaya (a one-click tool that helps you shop smarter) won second place. The team was an awesome developer and designer (that met each other that morning). I would say that the designer is much more needed for those final touches
- You have typically 2 to 3 minutes to demo. Either show a killer designed and functioning product and let it speak for itself or make sure you have a funny spin to make them laugh (chance to win a people’s choice).
- Work on something that does one thing really well. Show it off- focus on it for your demo.
- Tell a story. If you think you are solving a problem (big or small), tell everyone about the problem and how you solved it. People like stories. If you are solving an interesting problem and have a cool/working product you have a high chance of winning something.
- While you might not win the top place, by focusing your project on a specific API you may come away with the best use of the API. I’ve seen people enter hackathons saying they want to win Face.com or Twilio’s prize (whether an iPad, Kindle, etc) and focus their project entirely in that direction.
- To be successful at the presentation you need to be able to get through your demo. You can slave away all night working but if you can’t clearly express your project/hack you won’t have a chance of winning anything. Make sure you don’t waste time talking about pieces of the project that aren’t essential to the crowd’s understanding of what you have built.
- Don’t bet the house on a project/hack joke. They are always seemingly transient and don’t have a high chance of lasting after the weekend, which is traditionally one of the criteria that the judges use when voting. You should make jokes during your presentation, but just be wary of making your entire pitch a joke.
If you follow these do’s and dont’s your chances of winning will definitely increase.
Any other tips? Leave them below.
After having been involved with some hackathons I realized a theme that was occuring. Many great people were getting together, but there was a sizable faction of people coming to the events who didn’t know how to develop (myself included, but I was always an organizer- very rarely a participant).
Now, this wouldn’t be too bad if the people who didn’t know how to code wouldn’t continue to ask for help to learn from the people who did.
I’m all for helping the community and for people learning how to program, but it needs to be in the right place and time. (Side note: interesting idea here would to put together a midnight intro to programming class at a hackathon, but I digress)
So, when planning eCommerce Hack Day with the folks at Etsy we decided to have a filter process for developers. Michael, my (other) life-partner at Dwolla, thought up a really neat puzzle that he could insert in the source code of the homepage. This puzzle would essentially make developers prove that they can program before getting a ticket.
Once it went live it was on the front page of Hacker News and over 1,000 people tried to solve it in the first 5 hours. Michael is going to write a blog post about how he built it with Redis To Go and Sendgrid. We’ll be sending out invitations to developers soon!
I was at TC Disrupt this past weekend and was talking to a ton of developers asking them what they were working on. It seemed like every other person I spoke with was building off of Mobli’s API. I found that a bit odd as Mobli is not super popular. I soon found out that Mobli was offering a $10,000 prize to the best use of the Mobli API. $10k is a lot of money and it all made sense- Mobli was buying off developers to use their API.
I’m singling out Mobli, but there were tons of companies giving out incentives to hack on their platform. I haven’t seen a single company give out quite as much money before, but offering prizes to use an API is nothing new. It’s a great thing for both companies and developers.
I think it will be interesting to see: 1) Will people continue to use the Mobli API once this hackathon is over? Does the big cash prize carry over post-hackathon? 2) Will anyone build anything meaningful on Mobli that lives on for more than a week or two?
Who knows, my gut tells me no, but you never know.
I guess the real question is whether developers can be bought off to build at hackathons and if this is a worthwhile route for companies to take or just a waste of money?
Last week it was announced that Flickr would be integrating Aviary’s photo editor. To give some back-story on how this relationship really got kicked into high gear, you would have to go back to Photo Hack Day in August.
Before Photo Hack Day there was very limited conversation between Aviary and Flickr. Once news got out that Aviary was organizing the hackathon, every company emailed to get involved, including Flickr.
The conversation got pushed to the next level during the actual weekend of the first Photo Hack Day. The Aviary team had Flickr’s and other companies undivided attention for 24 hours (obviously not for all 24 hours, but a good portion).
Post-hackathon, the conversation continued and a deal became a reality a few months later when Picnik was going to be discontinued and Flickr was looking for alternative solutions.
While this was a great partnership win for Aviary (with all the props going to @paulbz), the main point is that if you are looking to score loads of partnerships in one industry, putting together a hackathon for that industry can do wonders in terms of getting in front of everyone.
While hackathons are meant to be for developers to build cool things, a great by-product for companies involved are the opportunities to chat and work with other companies. Flickr is only one of many companies Aviary closed because of Photo Hack Day (1 and 2), others include Picplz, Tracks, Bigstock, and more.
If your hackathon is a good one, all of the relevant companies should attend and you would have a unique opportunity to discuss ways to work together.
I had the pleasure of MC’ing and spending time at Photo Hack Day 2 this past weekend. It was super enjoyable and I had a chance to see a lot of old friends in the photo space. This was the second act of Photo Hack Day and we really put on a show. In the end there were 60+ projects built and 250+ developers in attendance.
Many people come to me asking how they can get their company’s API out there. Aviary has become the leader in photo editing API’s, but it wasn’t always that way. It took us a good year for developers to really start hacking on our API. Early on, we got involved with a lot of hackathons, but only the past few hackathons led to common knowledge of our API’s for web and mobile.
On average I’ve seen it take about or more than 6 months to let developers know about the existence of your offering. Usually when people come to a hackathon they already have their idea for their project thought out. They might see if there are any interesting APIs that they can just plug-in last minute to win prizes, but the idea is already there and thought through.
Because of this you need to hit the hackathon circuit for a good 6 months before developers really know what your offering is AND begin to think about using it BEFORE the event.
You are in luck though. There are at least two weekend hackathons a month, which will give you time to start getting the word out.