Startup Founders & Risk

Real Life Sciences (RLS) failed for many reasons. The tech team consisted of me and one of the co-founders. (And for the first few months it was just me.) The tool we built was functional, but not spectacular. We used a lot of tech we weren’t familiar with, which slowed progress. The team was distributed across four cities, and none of us had experience working remotely. Consequently, communication was poor. The only funding came from a family member of one of the co-founders.

But I think the biggest reason for failure was risk imbalance among the founders (and me).

I was initially brought in as a full-time consultant to build the first version of the product. At this point, the four co-founders were all working part-time in various capacities. After a few months, the technical co-founder lost her day job when that startup went under and she shifted over full-time to RLS. Two other founders were working on finding funding and the fourth founder did… something. I never was quite sure what he did.

At this point we had four founders in the following situations

  • The technical co-founder was working with me full-time building the product.
  • The two business/sales co-founders were working with our alpha customer and trying to secure funding, but only part-time.
  • The fourth co-founder was doing… something.

We were now in a situation where the people responsible for securing funding had little to no risk compared to the technical people. Both of them had good jobs and no incentive to quit them. It’s unclear what level of success would have even been required to bring them in full-time. I’m not blameless either. I enabled the situation by continuing to work for equity after the money ran out. It doesn’t matter how much of the pie you own when there is no pie.

I know it is almost impossible to be part of a startup where all co-founders take on an equal risk. There are too many circumstances outside of work for that to be possible, but don’t make the same mistakes I made.  If you see a situation where the risk is extremely lopsided, bring it up. And if nothing changes, look for your exit.

Knowing When To Quit

Note: I started this post in October 2012 after quitting my previous job at the end of February 2012. I never posted it, but feel it is appropriate now that the company exists in name only. I’ve made slight changes, but most of the post exists as I originally wrote it.

I haven’t been paid since August. The only co-worker I see on a daily basis is my cat, who always thinks it’s her turn with the keyboard. I would love to have a week of physical interaction with the rest of my team. And even with all of that, my new job is still awesome.


I’m not a quitter by nature, but in February I actually did it. I quit. I had been trying to make it work. I really was. Eventually though, I had to accept that sometimes a job just isn’t right for you. The tech may not be interesting. Maybe the pay is mediocre. Possibly your main project has no direction. And sometimes all of these converge into one… what? I mean, it’s not terrible. You can live with it. After all, they are giving you money to write code, right? And your co-workers are all really nice.

But what if you don’t need the money? Or you spend a good chunk of your time wondering why you came to work today? Or every time you look something up on StackOverflow you get distracted by the Careers 2.0 postings along the right side. That’s where I found myself this winter, so I quit.


I wrote an email on a Friday, slept on it over the weekend, and then sent it first thing on Monday morning. By mid-morning, I knew that I was going to be unemployed in two days. I had no plan, just the usual “exploring opportunities” and “researching startup ideas”. But I didn’t need the money and I felt amazing. The happiest I had been about my career in awhile.

Moving Forward

And then everything just fell into place. Former co-workers and classmates heard I was available and within days I had multiple options. I decided to work remotely for a former classmate’s startup. And when the money ran out I just kept working.

I get to work with an up to date stack on a greenfield project (the first true greenfield of my career). I get serious input into the architecture. I get the freedom to work whatever hours I want, from wherever I want. And, right now, I don’t get paid. Sometimes though, it pays to be a quitter.


It’s now May 2014. That startup never did get any more funding. I continued to work on it intermittently, but cut my hours back significantly. I got a lot of equity thrown at me, but even 100% of zero is still zero. Amusingly, I was so underpaid before, that even though I didn’t get paid for the last five months of work, I still made almost as much as I had the previous year.

I was already having doubts that funding was coming around the time I wrote this post, but I didn’t have anything else on the table at the time, so I stuck with it. I need to collect my thoughts, but for now I’ll just say that you should avoid a startup where there is an extreme risk imbalance among the founders.

Two Year Recap

The short recap of where I’ve been for the past 2 years.

On February 29, 2012, I quit my job at Summersault working on I was struggling with RSI and the work wasn’t fulfilling. The backend was a mess and the project had no direction. I had butted heads with other developers over some issues repeatedly and no progress was being made. My plan was to take some time off to rest my arms and look at some startup ideas.

That plan literally lasted one day. On March 1 an old college friend contacted me asking if I wanted to come work at her new startup. Over the next 6 months we made progress, but funding dried up and the product died in a private beta. Professionally, the best things to come out of it were that I got to say I was a professional Ruby developer and that I had experience working remote.

From there, I transitioned into my current role as a remote developer for InfernoRed Technology. I’m back in the .NET world, which still feels weird. I hadn’t owned a single machine running Windows since 2008. Now I’m writing Windows 8.1 apps. It also broke my streak of not having professional experience with a new job’s primary language. I went from C# -> Perl -> Ruby -> Python -> C#. (Yeah, there was a brief Python foray in there.)

The real purpose of this post was to get back into the swing of writing and publishing. Over the past couple of years I have started writing several posts, but never finished. I’m a creature of habit, and if I don’t include writing in my regular routine, it just doesn’t happen. Hopefully this is a new start.

CodeMash 2012

I had the good fortune of attending my first CodeMash a couple of weeks ago. CodeMash is a conference in Sandusky, OH in the middle of winter at an indoor waterpark/convention center. All 1200 tickets were sold out in 20 minutes and the registration rush brought EventBrite’s servers to their knees. There weren’t any Perl talks (maybe I’ll submit one next year), but there was a wide range of topics to choose from.

Building For the Cloud at Netflix

Carl Quinn from Netflix gave an excellent talk on how Netflix uses Amazon Web Services. They have a really slick setup where a deployment involves simply firing up a new, pre-baked instance and redirecting traffic to it through the load balancer. The new version runs alongside the old version and a rollback simply involves telling the load balancer to send all traffic back to the old version. By pre-baking images they avoid having to do any scripting on the instance as part of deployment. Pretty slick. And their so redundant with their Cassandra instances, they put them on ephemeral storage, which means that the data disappears if the instance is shutdown.

Becoming a Ruby Gemcutter

I only caught the second half of Nick Quaranto’s talk on building ruby gems, but what I did see was a good outline of best practices for creating and managing your own gems. I was also interested to learn of GemTesters, which is basically CPAN Testers for Ruby. I often hear Perl mongers mention that no other community has something like CPAN Testers and that makes Perl better. Well, Ruby has it.

Cooking Environments With Chef

I was really looking forward to this talk by Colin Gemmell and wasn’t disappointed. Colin went over the basics of knife, roles, recipes, and cookbooks, while making it all seem so easy. I’ve even started playing around with Chef at work already and am hoping to automate a good chunk of our infrastructure management with it. Nothing like a developer pretending to be a sysadmin. I think we call that devops now.

Cross-Platform Mobile Apps With jQuery Mobile

I had the misfortune of fumbling around with jQTouch this summer, so I was looking forward to hearing about how the 1.0 release of jQuery Mobile was working out. Apparently a lot has changed since the summer and it is now on a path to becoming the dominant browser-based mobile framework. It’s even got Visual Studio 2010 and Dreamweaver CS5 integration, which indicates some serious momentum to me. I’m hoping to get the opportunity to play around with this some more on a side project.

Information Overload

Scott Hanselman is one of the best speakers you will ever see at a tech conference and this talk did not disappoint. He went over how to deal with information overload. Scott gets hundreds of emails a day and can never hope to give everybody the slice of his time that they wish they could have. Dealing with this has led to him developing a number of techniques for coping. For example, he splits his inbox by whether the message was sent to him or he was just CC’d. If you CC him on an email, he may never read it. If it was important you would have sent it to him. The talk was a blend of many time management and organization techniques and I highly encourage you to check it out once it’s up on InfoQ within the next few months.

Beautiful Front End Code With Backbone.js and CoffeeScript

Backbone.js and CoffeeScript are two tools that I’ve been interested in, but have not had the motivation to actually check out. I’ve been through the quagmire of trying to understand jQuery eventing gone wild. And I’ve been the one writing the code. At some point ad-hoc event handlers just gets to be too much to manage and that is where a tool like Backbone.js comes in handy. Backbone.js is just a client-side MVC framework. That’s it. And coupled with the expressiveness of CoffeeScript you can get a lot done with just a little bit of code. I see myself using this judiciously in the future. For many sites it would be overkill, but even those sites often have certain pages which are more JS-heavy than others.

It was a great conference. Many attendees consider CodeMash to be the best conference they attend every year. I was just about the only Perl guy there, but it was great being immersed with developers with a wide variety of skills. And it’s very satisfying to play in a waterpark in January while it snows outside.

The Wow Factor

One thing that I find Perl to be lacking is a “wow” factor. Something so easy and awesome that within 5 minutes you’re sold on it. I was reminded of these after starting a side project with Ruby on Rails and Heroku.

This is my 3rd foray into Rails. I briefly worked on the initial version of OrgSync in 2007 with Rails 1.2. I came back to do a small website (since switched to WordPress) in 2009 using Rails 2.3. Now I’m back on the train in 2011 with 3.0.7. Every time I’ve ventured in I’ve come out deeply impressed and this time it is even more so because of Heroku. I went from never having read anything about it to having an app up and running in hours. And a lot of that time was spent just browsing their documentation. I could have done it in 15 minutes. The pain of Rails hosting I experienced in the past is simply gone. And it is free to get started. Everything about the process is designed to minimize the amount of friction a new user experiences, all the way from creating a Rails app, creating some scaffolds, and installing it on Heroku.

Maybe Stackato or DotCloud can provide some “wow” for Perl. Until then I’m pretty stoked to be riding the Rails again.