In the last decade or so I think we can all agree that the internets have come a long way.  Cloud infrastructure, application technology and hardware have evolved beyond my expectations.  The market is abuzz with third party, value-add products that make application service providing (ASP) easier and easier every day.  The clearest sign of civilization is specialization right?  ASP’s are becoming more and more specialized.  The industry even has a new name for it: Software as a Service (SaaS).

All these years, systems administrators and application developers have been concerned about application uptime, points of failure, fault tolerance, disaster recovery, geographic redundancy… oh you get the idea.  I haven’t noticed much evidence of the evolution of thought on these subjects as the technology has improved.  I think that’s because of fear.  See, if an application is down.  Someone is to blame.  No, not a router, not a hard drive, not a line of code.  A person.  People make decisions.  Fear causes bad decisions or worse, indecision.  Removing the possibility of failure reduces the potential to be blamed.  Um, yeah, but at what cost?

The tubes are now all about agile specialists.  The more agile you are the better.  The environment is actually feeding itself.  Successful SaaS providers use each other to be faster; to get their service to market quicker; to concentrate on what they do best.  Successful companies aren’t afraid of downtime. They are not concerned with geographic redundancy.  If they were, they’d be spending too much time mitigating their fear.

Ok, I’ll admit, I started writing this post because I heard about downtime one too many times recently.  My latest app, CheddarGetter is a SaaS application.  We specialize in pricing and subscription management.  It’s important stuff but It’s nothing to be afraid of.  Any application developer worth her salt can read the paypal api docs and include rudimentary billing support for a web application.  But if it’s not your specialty, why would you waste your time?  Sure, if you use CheddarGetter to bill for your app and the service is down, you can’t signup a new customer.  Well, guess what?  If CheddarGetter is down, no one can sign up for CheddarGetter either.  See, CheddarGetter uses itself to bill for itself.  That’s built in motivation to eliminate downtime, to increase fault tolerance, to limit points of failure.  That motivation only increases as the customer base grows.  Which application do you think will have the best uptime?  CheddarGetter or the ill conceived, limited, proprietary, likely undocumented, single-use billing functionality written by a developers who may or may not be on vacation or currently working for a different, successful SaaS company.

Stop living in fear.  Start making money.

You’ve probably heard about the incredible team we put together at SproutBox. They are experienced, talented and dedicated to entrepreneurial success. But how did we find them? It was a painful process and took months, but we learned a few things:

1. Start with people.
The first thing we did is talk about our dream team. Anyone could be included. We listed out each general role and then put a name next to it. The names we wrote down had nothing to do with rather or not we could hire them. They were people we had worked with before, or even well known people at companies we admired. We started a dialog like: “If we could get a Dimmett (who we ended up hiring) and Kyle (a friend that we knew we couldn’t hire), that would be sweet”. It made the types of people we were looking for real and concrete. After all, it wasn’t a list of qualifications we were looking for, it was a real live person.

2. Look to your friends friends friends.
We did job boards and resume search sites, but in the end, nearly all the team came from personal relationships. They were friends, or friends of friends friends. We didn’t set out for it to be like that at all—that is just where we found success. We spent a lot of time doing different things, but the time we spent listing people we knew (or that might know someone) turned out be the most effective use of our time. We used LinkedIn and facebook to refresh our memory about who we knew, and then bugged everyone incessantly until we found what we were looking for.

3. Be open and flexible.
Because we were hiring the whole team (8 or 9 positions) at once, we had a lot of flexibility—which means a lot of moving parts. We could double one person’s salary as long as we could take it out of everyone else’s. We were very open with everyone about the situation, making them much more open to tell us what their requirements and desires were. We didn’t try to fit a square peg in a round hole by dictating salaries or responsibility for each position. Instead we ran scenarios for various possible teams. We listed out deliverables and who would be responsible for them, then added the salaries of that team. Once we found a combination that fit our budget we were ready to make offers.

4. Evaluate candidates based on their online presence.
The first thing we did when evaluating a candidate was a google search on their name. We scanned resumes for URLs and entered them in. We looked at LinkedIn and facebook profiles and connections. We looked for twitter accounts, and what they posted. We looked to see if they had made anything that we could see online. Did they contribute any code on GitHub? Did they have a website with writing/design samples? Did they have any side projects or hobbies? It was these things more so than education, previous experience or lists of skills, that helped us make our decisions. We didn’t cross people off for putting themselves out there. Have a picture of yourself at a bar on facebook? Guess what? So do we. If we are going to hire you, we actually want know what you are like. Maybe you’re a good fit, maybe you’re not, but the more info we have about each other, and the sooner we have it, the better it is for everyone.

Notes on job boards.
We posted on the 37Signals job board and got a few solid candidates. We had 4 or 5 near hits from 37Signals, but no actual hits. Some were outside our price range. Others sorta flaked out later in the process. The Joel on Software job board was similar, but brought us fewer candidates and really only 1 near hit. Dice did bring us one of our hires, and since he is awesome, I guess it was worth the pain. We got very little useful from our listing on there, but the ability to search resumes, while time consuming, had some value. We looked at hundreds of resumes, sent 50+ emails out and got around 10 serious responses and 1 hire.

The pain in the hiring process is one of the reasons we created SproutBox. We don’t want this critical hurdle to be a companies first challenge. With the SproutBox model, you immediately have a talented and experienced team ready to begin making your idea a reality. You can then start building a small focused team during the transition phase. Lots of people would love to work at a startup. But attracting the best talent (outside of founders) is much easier if you are stable, have a brand and a little traction.