How to Find a Technical Co-Founder

Finding a technical co-founder is like online dating: too many guys and not enough women, except you skip the engagement and jump straight to the wedding. Often times, what’s really being asked is “How do I learn about starting a company?”. Check out the title of this hugely popular Quora question: “I am a creative guy with a startup idea. Where is the best place to find a rockstar developer to bring it to life?” There are 35 answers and it has been viewed 19870 times. The wording of this question reveals a troubling conceit–the idea that once you have an idea, all you need is to hire a few monkeys to code it up–then profit! The world is richer and more complex than that, my friends.

1 is the Loneliest Number

Apple had Steve Wozniak, Google had both Larry Page and Sergei Brin, Facebook had Mark Zuckerberg. It’s hard to build successful technology companies without a strong technical co-founder. You really need the wide range of talents from a Marketer, Product Manager, and Designer–it just so happens that the 1+1 combo of a business founder and technical founder can condense this set of skills into two people. With freelancers and advisers, you can keep the team size to two longer, but you’ll be hard-pressed to find a single person that does it all.

Be Realistic

Be honest with yourself first so you can be honest with others. Rate yourself on a scale of 1-10 for this role. Figure out what strengths you bring to the table and what’s lacking. Are you ready to be part of a 1+1? Most likely, this means you’ll be solely responsible for the business side of things including marketing, sales, legal, etc. Should you find a co-founder or should you join a startup to learn some skills first? If you’re not a superstar business guy, you will not get a superstar technical guy to work with you, so have realistic expectations.

Make Friends

Highly sought-after women generally don’t need online dating. A great engineer will have six-figure offers from Google and Facebook on the table. For them to pass on those jobs is like ditching a millionaire for a struggling writer. You better be Ernest Frakking Hemingway carrying a dead lion you just killed with your fountain pen. I suggest you make friends with as many technical people as you can. Go to meetups, conferences, Startup Weekend, etc. Make connections on Twitter and through your extended network. Meet your neighbors who may be trying to build the next Instagram (engineers tend to tinker too much and ideate too little). At some point you’ll realize why the term “rockstar developer” is so passe. If you need some technical advice, introduce yourself on Twitter–I go by @mankindforward.

Every Startup Needs a Gong

This is our third gong. Our first one was a few inches in diameter and sat on a desk. Our second one is about six inches in diameter–a mini version of this beast, which vibrates your soul if you stand too close. Gongs are a meme at Badgeville–a unique story about our company just like “Team Punishment” and Iceland. We hit the gong whenever sales closes a deal and the size of the deal determines the number of gongs (and now also what size gong you hit). Other companies also does this for sales. I hear New Relic gongs and sends a mass email to the entire company when a client goes premium (awkward and funny story around that). I love the gongs because they’re a tangible reminder of progress. As an engineer living in a world of 0-downtime releases and in the past weekly or even daily releases, there’s no party to commemorate the mailing of CDs with your software. Somewhere out there, some VMs turn over in a dark, temperature-controlled room and your SaaS product has been updated.

Gongs are one of the many ways companies develop culture and character. Our name is “Team Punishment”. The origin of the name is oh-so-random but it’s stuck nonetheless. Every quarter we design t-shirts to commemorate the evolution of “Team Punishment”–recent ones featured images from the Godfather and Scarface. I remember one quarter we had one w/ a japanese phrase translated as “team with no worthy enemies”. As we’ve grown to over 50 employees and moved 4 offices and now occupy a fifth across the street, it’s the little things like gongs and team names and backstories that pass on the culture, the essence of the company. The space-time continuum in a startup is compressed–years feel like months and weeks feel like days. It’s very easy to get caught up in Getting Stuff Done (GSD), but it’s these tiny details that help tell the story of your company.

Why I Joined a Startup

There I was, working for Andrew Ng, known for his research in machine learning and computer vision. I was lead on Stanford AI Robot (STAIR), getting the project off the ground and teaching the robot to wheel around Gates and open doors with its robotic arm. Needless to say, I was very fortunate to have an interesting project. And yet something was missing. As Larry Smith said, “What you want is passion–it is beyond interest“. There I was, having a quarter-life crisis.

I don’t have an accent and though from time to time I talk like a fob or a banana for fun, my parents did a pretty good job raising me in the Chinese tradition balanced by America’s progressive values. In high school, my weekends were mostly spent studying for the SATs and when my parents weren’t looking, playing the original Quake on a 13-inch CRT. When I wasn’t in China visiting family during the summers at Yale, I worked at research labs on things like Molecular Electronics and the Autonomous Vehicles. I didn’t do internships in industry because that wasn’t in the plan. The plan was to get that Ph.D. because in Chinese culture, the degree is king. In a culture whose recent history rewarded political office to the best scholars and with it a life of fame and fortune, this mindset is hard to shake.

There I was, fulfilling the plan but not the passion. So I took baby steps. I worked on a few startup projects with friends and acquaintances and learned a bit of Ruby on Rails, which was in its toddlerhood (1.0, baby!). I wanted to build things that had impact right then–I knew I had at least a few decades to wait until robots would advance beyond glorified vacuums. I tried to read about the startup life but barely scratched the surface. To be honest, I didn’t really prepare myself properly. I had the comfort of graduate school to cushion me while I did some part-time work for a company called Howcast. One day I was working from home part-time and the next day I was “WFH” full-time. I still played basketball with my grad school buddies after work. There I was, a newly minted startup guy.

There are many reasons not to join a startup so back then I listed many of them to myself. People with young children or other family responsibilities. Nope, I left that box unchecked. People who can’t handle high-stress or high-intensity situations. Nope, my personality craves andrenaline–like playing FPS for 16 hours straight w/o a bathroom break or popping a few Lactaid pills before doing the Milk Challenge. Ultimately, this was a lame game to play and since “everyone was doing it”, I definitely got sucked in by the hype as well.

Here I am, a startup guy. I can tell you that you’ll learn so much more and have so much more responsibility at a startup, but that may not always be true. I can tell you that the potential rewards are greater than the risks, but I won’t go on the record with that. I can tell you that you’ll have more impact than teaching or working at a big company but that’s not a truism either. When you’re in a quarter-life or mid-life or three-quarters-life crisis, it’s a “solution” you’re looking for. It’s the sign in the road that says “Happiness 42 miles”. Well, there were budget cuts and those signs were never installed. No path to follow, no one end result to optimize for. And guess what, startup life may or may not be for you. It’s like saying, “Surprise! You’re on the Truman Show!” My reasons have changed over time but one thing hasn’t really changed. Here I am, a guy who isn’t ever bored for long.

Engineyard or Heroku?

Web-based software is becoming more and more service-oriented. You probably know about software as a service (SaaS – e.g. Salesforce) and infrastructure as a service (IaaS – e.g. Amazon) but probaby not platform as a service (PaaS). Companies like Engineyard and Heroku make it easier to launch and scale a web application. For the most part, you can setup an account, run a few commands for basic configuration and you’ve launched in the Cloud. This is an order of magnitude easier than it was just 5 years ago. If you just felt your heart skip a beat, please take a few minutes to catch your breath. When you’re ready, let me help you decide what platform to launch your next application on.

Heroku is great for quick applications. The best Rails candidates I interview deploy their code challenges on there and send me a link. The smallest configuration on Heroku gives you a 5MB shared database and 1 “dyno”, their unit of measure for CPU. It’s free and you can even get add-on’s like New Relic performance monitoring thrown in. To scale up, you can pay more for dynos and a more powerful database. Setup is fairly painless, though I had to google for help when their “happy-path” documentation didn’t work exactly the way it was intended. The most annoying thing is that for the smallest configuration, the first request you make to the site takes 30-60 seconds to complete because their servers are dynamically provisioning you resources. Heroku hides much of the Operations side of things from you and that’s an intentional choice. It’s clear that they’d like to make the deployment process idiot-proof. I think that’s great for interview code challenges and school projects but if you’re serious about your application, you need to use Engineyard.

Why?

You need to be in control. Over the years I’ve seen EBS volumes become read-only all of a sudden, MongoDB refuse to resolve internal hostnames for a subset of instances, and even instances mysteriously become unreachable or “disappear”. Putting your servers in the Cloud has a huge drawback: you don’t have physical access to the hardware. When things go wrong–and they inevitably do–you need to have access. Since you’re saving money by not buying your own hardware up front and using IaaS, the next best thing is having as much control of your instance as possible. With Engineyard, you can ssh into every single machine and customize your own recipes. Essentially, they setup the default configuration but at the end of the day you can do whatever you want. For everything from Cron to Redis, I customize the configuration and understand exactly how processes are running. I analyze the CPU and memory usage and even the IO performance because I need to tune things like how many workers should be on each application instance. Control is critical when debugging issues. You’ll need to install custom monitoring and benchmarking to find out why your Memcached servers are maxing out at 80% memory utilization for example.

You need expertise. PaaS is your world-class Operations team. Even if you hired one or two Operations people, it is unlikely they will be experts in all the technologies you’re using. Given that I’ve never used paid Heroku Support, I can’t speak to their experts, but Engineyard definitely knows their stuff. They try to cover as many areas as possible in-house and through partnerships, cover others. I know that they have a great in-house MongoDB presence because their team helped me with my Sharding migration. I’ve gotten DBAs from Percona to look over my slow mysql queries, advice from Durran Jordan of Mongoid over IRC, and just as I was looking into Neo4j for some graph-based projects, I heard that they were actively talking with Neo Technology about a partnership. When your application has a problem and Google doesn’t help, you can either call a really smart friend like a contestant on “Who Wants to Be a Millionaire” or you can leverage the collective expertise of Engineyard and their network. They know your application and infrastructure really well and you may be seeing the same problem as another one of their clients. This expertise model works and just makes sense.

You need support. When you’re in the Cloud, you need someone to have your back. You can install a Heroku add-on like “Redis To Go”, but what happens when things break? As a engineer I’m pretty paranoid and rightfully so. I’m weary of things labeled “X to go” or “Y in a box”. Furthermore, I believe that if you’re going to use a technology in production, you should install it yourself. It’s critical that you develop a long-term relationship with a team that knows your specific application and infrastructure. When you read an email from Engineyard at 9am telling you how at 5am they detected a problem and brought your site back up without waking you from your precious 6 hours of sleep, you’ll know what I’m talking about. When it’s 3am and you’ve been wrestling with an issue that’s keeping your site down and your friends at Engineyard are still up and walking you through hell, you’ll know what I’m talking about. Heroku support may be just as good, I don’t know. But I’ve been in the trenches with these guys and I can tell you that whoever you choose, you better be able to count on them when the CEO is calling you to ask when the site will be back up.

If you’re serious about your application, you’ll take these points into consideration and weigh them heavily against cost and hype. Engineyard’s worth the money.
Disclosure: Badgeville is an Engineyard customer and so was Howcast when I was there

Learning from Linsanity

ImageAfter J-Lin dropped 38 points on Kobe Bryant in the early days of Linsanity, Kobe wisely said, “Guys like that don’t just show up out of nowhere”. Outside the Startup Bubble or Linsanity, it’s hard to see past the hysteria, past the insanity. We human beings are conditioned to react quickly to sudden or big changes. We like to focus on the most exciting and the most sensational. But Kobe and I know the truth.

The truth is you try your best and hope to get lucky. For a long time J-Lin was solid but not showy. That didn’t get the attention of the people who decided who got picked for the team and who got playing time. In the startup world, you can have a solid product but if you don’t tell a good story or do enough marketing, it’s unlikely you’ll gain traction. Even if you do the proverbial “all of the above”, you may still go out with a bang or worse yet, quietly into the night.

For the most part, being solid is a prerequisite. You learn to dribble and shoot and sit patiently on the bench. And when enough people pull a groin muscle or have their brother unexpectedly die, you get your chance to shine. Don’t forget to trademark your meme.

Startups and Education

I’ve always been passionate about education and last weekend I finally did something about it. I spent 54 hours at Startup Weekend EDU immersing myself in the world of EdTech. At first I didn’t know what to make of it: 56 random people from diverse backgrounds giving 1-minute startup pitches ranging from a browser plugin for MLA citations to a “Million Student March”. Since none of the 3 ideas I voted for made the cut, I was disheartened. Was my gut really that far off??? Fate had other ideas apparently because the team I eventually joined won the whole thing.

The prize is a meeting with Andreessen Horowitz, but I already got my money’s worth. I had a candid chat with my teammate Ben, a high school teacher from rural Mississippi, who effortlessly shot down all my over-engineered and ungrounded ideas on how to “fix education”. I was inspired by an elderly woman and her son from Minnesota who combined her original songs with animated caterpillars to teach music and concepts together. Most valuable of all, I learned that we each hold but fragments of complete solutions.

At the end of our presentation, we whipped out an iPad and quipped “There’s an app for that!”. It was our flourish, demonstrating that what we built works seamlessly on the iPad as well as the web. I am simultaneously proud and embarrassed about it. I’m proud that we were able to build something that would have taken many times longer in the past but embarrassed that we spent the majority of our time building and not thinking. One day, Startup Weekend will produce startups that will build products, mature in the market and get acquired all before the 54 hours are over. Until then, I’ll be working on building the tools and improving the education needed to get us there.

 

Open Source and The Evolution of Full-Text Search

Image

A few months back, I was asked to estimate how long it would take to implement scalable full-text search. I instinctively cringed and started to give my standard expectation-setting reply where references would be made to the complexity of Google and keywords like “stemming” would be floated like mines in the ocean. But I caught myself–instead, I replied “I have a few options in mind but let me do some research and get back to you”.

With Open Source software today, the pace of innovation is so fast that in many situations it makes sense to spend time researching the latest and the greatest even it’s only been months since you last checked. This was my third run-in with seach. The first was with Ferret and its infamous fling with the Rails community a few years back. Because of performance reasons, Engineyard added it to a naughty list (as seen above) and there it has remained. My second involved Sphinx. It took me months to write integration tests, tweak performance, and configure the options. With elasticsearch, it was like using an iPhone for the first time minus the $299 + 2-year contract.

What can Open Source do for me (an engineer)? Full-text search is one of many tools that has matured after years of iteration within the community. Instead of continuously reinventing the wheel, we help each other build ever more powerful components. In fact, joining the effort could mean as little as using software and reporting bugs. Open Source is also a great way to learn new techniques and shed bad habits. Because everyone is watching, transparency encourages accountability.

What can Open Source do for me (an entrepreneur)? In the past, Open Source software meant unreliable software to entrepreneurs. Today, it’s our ticket to a quick launch and fast iteration. Along with its commercial cousin, Software as a Service (Saas), Open Source can take care of many non-core parts of your application like talking to the database and rendering pages (Rails), sending emails (SendGrid), and now search (elasticsearch). No matter how impressive it would be for your engineers to build you a custom email solution, their time would likely be better spent figuring out how to get those pins to stick to the board.

Demystifying the Cloud

Image

One of the hottest buzz words in the Valley today is “Cloud”. You see it on accident-inducing billboards like Microsoft’s “Virtualization alone does not a cloud make”. You hear murmurs while grocery shopping like “Omg, Apple’s coming out w/ the iCloud–it’s gonna be sick!”. But before you call Microsoft for some meditation lessons or march down to the Apple store for an iCloud 5, take a reality check with me.

The Cloud will not make your web application better. If your application sucks now, it will not get any better in the Cloud because normally the code for your application will be exactly the same whether you run it on your own servers or on Amazon’s. There are many ways the Cloud can help your cause but most of these relate to infrastructure and not your core application.

The Cloud isn’t for everybody. There are cases where you shouldn’t leverage Cloud Computing. For example, if you’re feeling adventurous with the law and start a gambling website where latency and security are top concerns, it might be prudent to your buy your own hardware up front. With your own hardware, you always have more control.

The Cloud isn’t always cheaper. Depending on your needs, it might be more expensive to host your application in the Cloud than on your own hardware. For example, Amazon’s rates for various instance sizes scales with CPU and memory. In many cases, your application will need some of the more powerful and expensive instances. At some point, it will make more sense to ‘buy’ than to ‘rent’ these instances.

Some of the hype is true.

What can Cloud do for me (an engineer)? The Cloud allows web developers to abstract further away from the hardware we see as less predictable and more frustrating than code. Just as programmers have moved beyond writing less code (think 70s and punch-cards) and beyond worrying about memory allocation (think coding in C), the Cloud allows us to worry less about infrastructure. The Cloud allows us to easily setup as many environments as we need for our code. For example, in a typical web startup, you probably need a “staging” environment where developers can experiment, a “qa” environment where QA can verify release candidates, and a “production” environment for the real deal. Depending on your needs, there can be other variations of code + data required (e.g. a “sandbox” environment for partners), but the Cloud, in conjunction with services like Engineyard, gives us the ability to easily manage this complexity. The Cloud helps engineers focus on the important stuff.

What can Cloud do for me (an entrepreneur)? The Cloud is a driving force for lowering the barrier of entry for new web-based technology. More importantly, the lower costs allow entrepreneurs to test ideas overnight with practically beer money. In my first startup 5 years ago, we paid over six figures up front to buy our own servers. Today, you could launch for 1000s if not 100s of dollars a month. Beyond the initial phase where we can quickly test our ideas, the Cloud also allows us to scale our application and business if the architecture is designed well. With proper planning and frameworks like Ruby on Rails, entrepreneurs can give birth to ideas and help them mature into a business or die a quick death. Yes, “fail early and fail often” is brought to you inexpensively by the Cloud.

The Cloud means progress for engineers and entrepreneurs. It can mean the difference between evaluating 1 or 10 ideas a year by reducing development time and costs. With a potential order-of-magnitude boost in the evolution of ideas, we are moving forward indeed.