That's very well written, however there's a better way to put it: when hiring, neither side should be trying too hard to sell themselves. A candidate telling a company "I am a rockstar ninja" is a candidate selling themselves too hard. A
company talking about "hiring the top C/C++/Java hackers, from a top-ten CS program" to create CRUD screens in PHP is selling themselves too hard as well. If you want top talent, give them top challenges. You can find plenty of people who are passionate about web development who would be interested in writing PHP for you. May be they can't implement a red-black tree on the white board (yes, I have literally heard of a PHP/Perl web developer being asked to do that), but they may have a great deal more knowledge when it comes to UI/UX, requirements gathering or people/project management.
I do think there is room for "top talent" in a start-up, but the key thing is that they will almost certainly be doing work that is "below them" at one point or another. As pg pointed out, YC presently has a tenured MIT professor as their Systems Administrator.
There's also a corollary to that: if you're coming straight out of college and are looking for serious technical career growth, you may want to hold-off joining an early stage start-up unless they're doing something truly uniquely challenging (e.g. Netscape in the early 90s, Google in 1998 or -- right now -- Directed Edge or the YC start-up making an alternative storage engine for MySQL).
It's also true that seemingly "simple" sites such as various social networks, e-commerce and media sites (Facebook/Ning/LinkedIn, Digg, Twitter) do grow to present many fascinating scalability and algorithmic challenges, these do not occur until the stage where these companies are no longer early-stage start-ups (particularly now, when powerful web frameworks abstract away any systems programming).
(EDIT: some start-ups do have many scaling and algorithmic challenges, but usually not in the early stages)
many fascinating scalability and algorithmic challenges... do not occur until the stage where these companies are no longer start-ups
I agree with your point that you shouldn't think about scaling too soon, but you're overstating the case. Twitter is still a startup. And they emphatically did have to worry about algorithms and scaling while they were still a startup.
Good point, corrected my post. My point isn't "don't worry about scaling" (in fact, large scale distributed computing is pretty much my own area of expertise/interest). My point is that there's a lot of glory stories of grand technological challenges, but they do not occur at your typical early stage start-up. If you want to solve these kind of problems, you're best off joining a company that's experience them (and not joining an early stage start-up and wishing they would: been there, done that).
It’s a very rare company where they can make the claim that their CEO is the recipe for success.
This seems to be the opposite of what most VCs tell. "We invest in people, not in ideas" is a common claim.
If you can’t trust the guy sitting in the cube next to you, you are in trouble. Hiring rock stars and ninjas is inviting trouble because they are likely to be glory seekers who are thinking about their own personal rewards, and less likely to be thinking about the team
I disagree with the stereotype he draws of "rockstars" (which is a retarded term anyways).
Overall this whole article is just based on a broken premise. The author suggests that a team of programmers is more than the sum of its individuals. This is false. A team of programmers is less than its sum. The larger the team, the more dramatic the impact of this inverse correlation. Cf. The mythical man month.
That's why a very small group of "rockstars", or even an individual, can run circles around mediocre teams of any size.
Maybe the term "rockstar" is where the trouble lies. Because, I don't know about you guys, but when I think rockstar, I don't necessarily think about virtuoso performers capable of creating masterful artwork. I usually think about burning out by their 30's, trashing hotel rooms, refusing to work because the mic settings are incorrect.
I think what everyone's trying to get at is, "consummate professional devoted to their field." The sort of person who, in an academic setting, might obtain a PhD and publish, or at the very least an engineer who reads technical journals and contributes, either to newsletters or publications, or as a member of a professional society; someone who considers personal improvement necessary to do their job as best they can. I think even if you're looking to hire someone to work on your CRUD PHP webapp, that's the sort of attitude you need, regardless of their actual experience.
Further I'd argue that even for your CRUD PHP webapp you ideally want the guy who, first thing, explains to you why doing it in PHP is a bad idea and how he'll do it with a more powerful tool in a day - rather than the guy who will just nod and then go off to blindly beat "something" into shape in a week.
Both candidates will deliver the first iteration of your "simplest thing that could possibly..." within a reasonable timeframe. But their respective effectiveness will diverge dramatically starting from the second iteration...
> you ideally want the guy who, first thing, explains to you why doing it in PHP is a bad idea and how he'll do it with a more powerful tool in a day
No, you don't. The last thing you need on a team is a person who's first thing is to start whining about things that cannot be changed. That kind of thing can quickly spoil the atmosphere. Rather, you want the person that accepts that things aren't perfect and use the strengths of the situation and works around the weaknesses. He'll need to do that anyway, even if you use the best "language du jour"...
Not accepting the weaknesses just leads to constantly chasing the perfect state while never completing the project.
No, you don't. The last thing you need on a team is a person who's first thing is to start whining about things that cannot be changed.
Depends on what phase your project is in. You can't start with a mediocre team and later try to hire rockstars. It can sometimes work the other way round, though.
A complete change of platform is obviously not something a real rockstar would suggest when invited to a large, existing codebase. Much rather will he recognize a lost cause when he sees it and just politely decline.
Note how I referred to the first iteration in my parent comment. I was aiming at the bootstrap phase of a startup where the initial choice between hiring a veteran for real stake or "going cheap" happens. Many people don't realize the consequences of "going cheap" at that point.
If I have a code base of over a few thousands lines (yes, even when that small), changing the language is just a dumb thing to do. It requires a complete rewrite, while changing a language that your team has experience in for one it doesn't. And of course, the usual rewrite problems also apply: killing a fully battle-tested system in favor of one that has not even seen a strong discussion...
And all that because one new hire couldn't get to grips with the fact that the organization didn't use his favorite language.
Problem is a young hacker with no formal experience (but who is nonetheless bright and talented), won't have the leverage to sell the higher-ups on using a more powerful technology.
That's why the higher-ups need to be open to disagreement and be able make decisions based on information. At the same time, the young hacker should have enough communication skills to be able to convince the higher-ups that it is in their interest to use a new technology. The higher-ups should be able to convince him why that may not work, either for tech or business reasons.
Seems there are a lot of "shoulds" in there but that's why management isn't easy.
No doubt. To continue the analogy, I usually want some guy who's played a hundred gigs, with all kinds of different musical styles, and is going to be focused on doing his part well so he can go home early.
Whether the team is more or less than the sum of the parts depends on how well the team works together. A team of good programmers who value each other and work to improve each other will cause each other to be better than if they were all alone. A team of rockstar programmers who get into lots of design conflicts will be less effective. Imagine a team of Linus, RMS, JWZ, and Miguel de Icaza; probably a pretty ineffective team. But how about Kerninghan, Ritchie, and Thompson? From their writings/interviews they seem like good people who became great because they worked together as a team. Or maybe Xerox PARC is a better example: how many members of the team can you name, yet the set the UI standard for years.
Imagine a team of Linus, RMS, JWZ, and Miguel de Icaza; probably a pretty ineffective team
I doubt that. One common attribute of great hackers is that they remain effective even in the face of personal disagreements. The LKML is a good place to witness that in the wild.
If they fail to compromise they would probably simply divide the problem space according to the individual strengths and preferences...
Agreed:
Key thing is that RMS and JWZ did build something together at one point, their views just diverged later (GNU/Lucid/XEmacs emacs split).
And of course, just typing this post I am using work of all of these: Firefox (JWZ heritage), on Linux (Linus), using GTK (Miguel), compiled with gcc (RMS).
The US Olympic team for basketball started using all-stars in the mid eighties (I think). When that happened, you had a bunch of high priced guys who were used to being the stars on their teams trying to play together. That doesn't work very well. Even if they are collectively the best athletes on the planet.
The Soviet hockey team from the mid 60s to 1980 were unbeatable. They all played together, some for as many as 15 years. Chemistry matters. Knowing that your team has your back, and make reasoned predictions about what you are going to do, and act before you need them to ensure success, matters. Hugely beneficial to have people who want to be part of a team not a bunch of people who are used to being individual standouts on teams.
The example is that just putting a bunch of the best basketball players on a team doesn't mean they will succeed - the 2004 USA Olympic team had some of the best basketball players in the world on it, and they still only got 3rd place.
The common thinking is that each superstar on the team wanted/was used to being in the spotlight and was unable to share/coordinate their efforts effectively.
You'll find that I believe VCs say many things that don't necessarily make sense. They do invest in people, but really, they invest in teams. That team has to work well together.
I very much believe that a solid team of developers (not a huge team) is WAY more than the sum of it's parts. There is not enough that can be said about a great team dynamic of very good programmers over bad or even typical team dynamic of "rockstars." Further, rockstars, in my experience, tend to exacerbate organizational dynamic issues.
> That's why a very small group of "rockstars", or even an individual, can run circles around mediocre teams of any size.
They can (and do) in the case of a true technology company. Lot of early stage Internet start-ups aren't yet technology companies (the modus operandi is "do the simplest thing that could possibly" vs. "build a technological advantage that others can't").
In programming, there is a VAST difference in productivity between great and mediocre programmers. That's because programmers create tools that do work. Bad programmers create shovels; great ones create fleets of bulldozers. Bad programmers create buggy, slow code; great programmers create fast, working, robust code and meet deadlines to do it.
I know this, because I'm a mediocre programmer. I struggle for a couple weeks to build something, and I talk to my Rock Star Programmer buddy, who immediately suggests a better solution. At his job, he creates stuff in a week that I couldn't create in my whole life (or at least it feels that way).
So yes, I think he'd definitely be a bargain at twice my salary, and probably he makes more than that, and should. If I were going to start a company, I would definitely want some rock stars like him.
The trick is, you almost have to be one to know one.
You are only posting the job ad on craiglist for free
You ask for guru level C++,C# and Java in the ad but the app is in VB6/PHP
Programmers don't get a corner private office, they share a room with the call center and sales staff.
They don't get an aeron chair and height adjustable desk. They get something government surplus with at least one broken leg in the corner of shipping and receiving warehouse.
Your office doesn't have views of central park. It has views of a railyard and the police regularly raiding the junkyard next door
And finally, if you are paying $40,000 you are hiring RockBand playing programmers, not Rockstar programmers - there is a sublte difference.
These sound like things to avoid if you want to get a cushy job at a big company, not find stimulating work at a start-up. Or is that the point? Color me confused.
none of these are especially encouraging signs but they're not reasons to dismiss an opportunity immediately either. not many early stage startups can afford private offices, aeron chairs, great views or high salaries
Most of the guys who I regarded as the very best developers were in Seattle and Silicon Valley.
Sorry you see it that way. I have found little correlation between developer quality and location. Great developers can be anywhere, with many reasons why they haven't relocated to a tech center. They may be right under your nose. Sounds like you found a few.
There is a disproportionately high number of very very good developers in those centers. That in no way states that there aren't awesome developers elsewhere. They are everywhere. Finding them is hard, and you certainly increase your chances when in a tech center like Seattle, Boulder, Boston or the Valley. Non US countries that have great talent? The Nordic countries have amazing developers, and former USSR countries. Wow. ODesk has some great resources in that regard.
To me, the author and commenters are missing the point of hiring "rock stars". The point is sort of the reverse. If your company was able to attract a "rock star", it probably makes something very interesting.
This just -in the eyes of VCs and other companies- makes your company more interesting.
The same applies to the times, where employees with PhDs made the company worth 70 mill$ more each (back in 2000).
A good deal of the value you can bring to hiring has to do with your personal network as well. You could be a mad scientist working on cold fusion, but if you don't know anyone, and a VC hasn't validated it, does that make whatever you are working on any less interesting? Absolutely not.
The point of the post was that there is this tendency to believe in the myth of the rock star, and that only the rock stars can make something amazing. A couple of the engineers from my old founding team are in YC now, and they are meeting with many VCs early. Why? Because they made those contacts on the first go round. Did they need rock stars to make that happen? No. Are they "rock stars?" No. Not in personality type anyway. I do look forward to working with them again though. They made for a great team.
I do think there is room for "top talent" in a start-up, but the key thing is that they will almost certainly be doing work that is "below them" at one point or another. As pg pointed out, YC presently has a tenured MIT professor as their Systems Administrator.
There's also a corollary to that: if you're coming straight out of college and are looking for serious technical career growth, you may want to hold-off joining an early stage start-up unless they're doing something truly uniquely challenging (e.g. Netscape in the early 90s, Google in 1998 or -- right now -- Directed Edge or the YC start-up making an alternative storage engine for MySQL).
It's also true that seemingly "simple" sites such as various social networks, e-commerce and media sites (Facebook/Ning/LinkedIn, Digg, Twitter) do grow to present many fascinating scalability and algorithmic challenges, these do not occur until the stage where these companies are no longer early-stage start-ups (particularly now, when powerful web frameworks abstract away any systems programming).
(EDIT: some start-ups do have many scaling and algorithmic challenges, but usually not in the early stages)