After reading Trotter Cashion's recent post, Startups: Don’t Hire Frontend or Backend Webdevs, I realized that I've been sitting on a good idea for an article for a long time. Trotter is an old friend of mine from back in NYC.rb's early days, and I have a lot of respect for him as a developer, so generally I'd recommend following his advice. But in this particular case, I think that his post talks about a symptom of the startup hiring problem, and not the disease. I'll do my best to outline what I think the real root of the problem is here, and I'd love to hear what people think in the comments section below.

DISCLAIMER:  I am a consultant who specializes in helping startups launch products, and I also do rescue work for those projects that have fallen off the tracks. That makes my opinion here super biased, but also gives me a unique perspective on what some failure points are for various startups out there, and some nontraditional ways around them. Part of this article may seem like a promotion for the company I do most of my contracting for, but really, I'm just super excited about the way we do business, and no one asked me to write this. :)

Two Types of Cowboys

Everyone lusts after the cowboy coder, the one who can do it all and be completely self-reliant no matter what problem arises. The trouble is that there is a fork in the road to becoming a cowboy, and it's hard to tell at a glance which path your potential new hire has walked down before they moseyed onto your ranch.

One way to reach the sort of well-roundedness Trotter is advocating in his article is to come up with an idea that you have to execute on your own because you don't have funds, or because you've got an inner drive to be self-reliant. If you really, really, love your idea, the sheer passion and hard work your project requires will provide enough motivation to tackle all the obstacles in your path.

The problem is that once someone reaches this level of accomplishment, they've already become the Lone Ranger, and would be better off founding startups rather than working as an employee in one. Some folks are aware of this fact, others are not, but the bottom line is that the truly talented developers who have walked down this path are hard to come by. Unfortunately, that doesn't stop some folks from fantasizing about scooping them up by the dozen.

What you absolutely do NOT want to have on your team is someone who generates their enthusiasm from acting the part.  Most people who end up in a role in which they need to be a self-reliant jack-of-all-trades are simply not ready for it. So instead, they trick themselves into thinking they're heroes because they spend nights and weekends at the office catching up, or spending a night sleeping at their desk because they botched a routine deploy simply because they didn't know what they were doing.   While their actions may seem heroic, and the end results may seem to be good at first, eventually these developers get smacked in the face with reality. The inevitable result is either burnout, or a rapid shift to some other shiny fantasy (job hopping).

Sooner or later, what happens is that someone else needs to pick up where the last cowboy left off. If you hire another cowboy, you repeat the process and none of your developers truly become professional at anything, let alone find themselves in an area of specialization. This is a tremendously wasteful process that I think is a leading cause of startup failures. It's at least big enough of a problem to have kept me in work for the last several years.

So if catching the "Lone Ranger" is like winning the lottery, and a losing ticket nets you a kid playing dress-up, the odds are clearly stacked against you. Fortunately, I have an alternative suggestion to balance out this bit of bad news.

You can get Professional Help!

Unless you still like to wear children's cowboy outfits around the office, I'm not talking about hiring a psychiatrist. Instead, I'm talking about how (at least in Ruby), there are plenty of professional development teams out there that specifically market to helping startups get off the ground.

• Brad Ediger, the founder of the company and author of Advanced Rails, who is an outright expert in database management and architecture.  He has worked on doing production deployments for high traffic sites as well as complex system administration for enterprise applications.   His company has the resources to bring team members on and off projects as need be, making sure that every project gets proper attention from qualified people.
• Gregory Brown (me), author of Ruby Best Practices. I have a deep application-level design sense that comes from years of developing complex open source projects (including the PDF generation library Prawn).   My specializations include building integration bridges to existing systems, and building internal libraries and services to support web applications.
• Jordan Byron: A skilled front-end developer and Rails programmer who has worked onsite with Gregory for over a year.
• Chenoa Siegenthaler: QA Tester and scripter who has worked onsite with Gregory for almost two years.
• In projects that require strong visual identity, one of our talented designers that is familiar with the way our team works also joins us.
  

We do cross train on side projects, and do some pairing on client work when there is some overlap between our areas of expertise.  But given the choice between a small team in which everyone knows a bit of everything, and a small team in which each person really kicks ass at one part of the puzzle, we favor the latter.  We've just found that professional execution requires such a thorough understanding of the technologies we're working with, that we'd never have time to reach the level of experience we are at now if we tried to take it all on.

As a result, none of us need to be heroes in our work.  We each strive for absolute mastery in the area we're responsible for, but because our roles are far more narrow than the "do it all" roles common in startups, we can actually maintain a reasonable work/life balance. We deliver projects on time and on budget, even though most of our hours are billed during ordinary business hours and most of us have a number of side projects we're involved in.

So why does this model work so well for us, but ends up having someone I like and respect like Trotter saying it's a bad idea?  I suspect it has to do with money, but in a bit of an indirect way...

Employees Scale Poorly (At least at first)

If you put out an advertisement for a backend or frontend developer before you truly need one, you're going to end up getting a lot of "expert" applicants demanding crazy high salaries from you. Then, what you're going to end up with is either someone incredibly underutilized because there isn't enough specialized work for them to do, or someone who is incredibly overextended because they are working on things that are outside of their area of self-assigned specialization.  If you're at a startup with less than 20 people, and you are hiring this way, I think every single point Trotter made is valid.  That said, there is a better way.

Suppose you have a single technical founder or a handful of intermediate developers that your founders trust.  In that case, it makes a lot more sense to set up a contracting relationship with a professional team to lay the initial foundation for your products,  and let your inhouse teams focus on the less demanding work of incremental improvements and routine maintenance. For that kind of work, smart folks who don't yet have enough experience to develop specialized skills do a great job.

The benefit of letting your inhouse team take on lighter duties while an outside agency does the heavy lifting is that "specialists" are only called in to do a task when it really applies to them, so every dollar you spend goes to the right person for the job. This is the main reason why a consulting company might bill you $150/hr or more, but still manage to come in below the budget of a low-payed inhouse team over the lifetime of a project. 

As your company grows, your inhouse developers don't need to all have such broad skill sets that extend far beyond the basics. At first, they can start by doing easy or intermediate work on whatever job needs to be done, but they won't have the pressure of coming up with good designs or putting out big fires. As they begin to learn more, they'll eventually get a feel for what they like, and take on more of that sort of work. Over time, you will have built several specialists simply through direct experience.  These folks can eliminate the need for outside contracting, and it won't take too long to get to that point because they'll have a clear path to success with the needed support framework to get them there.

Closing Thoughts

This to me seems like a much more sustainable path than picking cowboys at random hoping to assemble a team of folks who all happen to be heroes like the Lone Ranger.  What do you think?  Let me know in the comments below.  I am especially interested in opinions from folks who are in a hiring position at startups who *don't* utilize outside help, and what their reasons for that are.

P.S. If folks find this idea interesting, I can do a follow up post about how to separate the hucksters from the genuinely helpful consulting agencies out there, and also write up a bit about what you can do to get honest and realistic proposals for your projects.  I know that a lot of startups avoid outside work simply because of the perceived risks, but I think there are some good ways around that.