Just Don't Hire 0x Engineers
zachholman.com
zachholman.com
Thinking that you can avoid stupid people by only hiring smart people is naive, and misses this basic truth.
Success in one area typically correlates with success in many other areas as well. Otherwise we wouldn't have polymaths. There are people who are among the best in the world in fields that are completely independent.
Consider the recent story about how Elon Musk (arguably the most brilliant polymath of our era) chewed out an employee for missing a work function attend the birth of his child. That's appallingly stupid. That's pure blindness to instinct, cultural values, and compassion. There you go. Elon Musk, fscking idiot.
More generally, a lot of people with brilliant technical skills have lousy social skills - social failings that can drag a team's effectiveness down as much as a technical idiot can.
A brilliant engineer can have an amazing, world-changing technical career without ever realizing that he'd be 10x more effective with better social and leadership skills. Whether one sees that truth about themselves has much more to do with their personality and temperament than it does with their intelligence or expertise (IMO).
It's about presenting dedication, not being correct.
This is especially true if the new area is something they're peripherally familiar through everyday experience. I'm a teacher, so teaching comes to mind, here. Everyone has opinions about teaching and learning because everyone spent 15-20 years of their life doing it.
Intelligent people often act as if
Understanding of Area A + Familiarity with Area B = Understanding of Area B
See also: every thread ever on HN about law, politics, race, or gender.
In my experience, one's ability to develop expertise in many fields has much more to do with one's temperament. Most people I've met who who are able to do this live in a kind of visceral, mortal fear that they might believe something that isn't true. They're more likely to see certainty (in others as well as themselves) as a symptom of utter, hopeless confusion than as a symptom of understanding.
Blah blah anecdotes, yadda yadda caveats.
"Stupid" is pretty much defined as the opposite of "smart". You might be thinking of "unwise" or "ignorant" or "inexperienced". Or maybe you're thinking of "untalented" or "incompetent". None of those are "stupid" and their opposites aren't "smart".
For example, I'm good at programming, I have a good ear for music and I absolutely suck at drawing. None of that necessarily makes me smart or stupid. As a matter of fact, I'm pretty sure people wouldn't call me "stupid at drawing".
"Smart" and "stupid" are measures of a characteristic, just like "tall" and "short".
This does not disprove GP's point. Rather, you seem to agree.
Specifically: I'm smart but I do stupid things every day.
Fixing one's own stupid mistakes is half of what smart programmers do... perhaps "egoless" rather than "smart" is the proper opposite of "stupid" as far as programmers go.
Definitely. I've worked with people I refer to as "blithering geniuses". Like the guy who could write memory managers for OSes and so forth, but who would not only miss his own exit on the freeway, but suggest that we do crazy shit like switch C++ compilers two weeks before shipping (there was some feature he wanted out of another vendor's toolchain . . . hoo boy).
It's worthwhile knowing what your blind spots are, and where you are stupid.
You know what stupid is? It's focusing on things that are not a big deal.
That doesn't mean it doesn't take some special sauce to be a 10x developer, but my observation is most of the things that 10x developers do are teachable. For instance, they almost always are concerned with removing small inefficiencies from their work (learning keyboard shortcuts, using better tools, asking a lot of questions, etc.), and when they do find they're in a situation where the environment tends to pull people down to the mean, they usually move on quickly.
This is just my opinion, I'm not a manager, but if I were a manager I think I would be more concerned with how to "coach up" talent more than finding a unicorn.
> Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
— M. Conway
When I started at this position, money was very, very tight. While we had managed to get and retain some good people due to a variety of factors including luck, there was no realistic way for us to be able to afford to go after and hire the top people in the industry. So our strategy was to train the people we had and help them develop whatever potential they had. I think it was quite a risk for the management team to hire me because they had to believe enough in the staff that the cost of my salary would be compensated by the improved performance of the team. Not many management teams trust their staff to this degree (it is one of the best things about working on this team).
There are a few observations which I will make. First, it's a really, really difficult job :-). Even though I have probably more relevant experience doing this kind of thing than most people in the industry, it stretched me pretty far. Had I not been very motivated from the start to do it, there are probably many times I would have just given up. I will speak of some of the difficulties a bit later on.
By and large, I would say that we were successful. One measurable result is that we had very little attrition during that period. I think the fear many companies have is that if you spend money training people that they will just leave for a better paying job. It is a reasonable fear and you do have to be careful to track the development of people and to try to offer salary improvements as their skills grow. I think it is fair to say that we were not always successful in this aspect (due to very real constraints on our budget at the time), but that people valued the personal growth aspect of the job enough to decide to stay anyway.
In many cases, I think as a coach your role is not so much to tell people how to do their job better, but simply show them where they are not performing well. The thing about programmers is that they are both intelligent and also problem solvers. Even if the person is not functioning at the top of their game, I think this generally holds true, at least compared to the general population. I found what worked best was to try to formulate the problem in terms that the person could understand and then encourage them to find their own solution. Of course you have to give tips and guidance from time to time, but most programmers can improve themselves quite a lot simply if you show them what is lacking.
Of course this is not always easy. I'm just going to have to be blunt. Not everybody wants to improve. It is a testament to the team that I barely ever had to deal with this, but I think it is a real possibility in general. What I did have to deal with is the problem that sometimes people don't want to improve right now. Sometimes their life is full and they just don't have the capacity. This is really, really difficult because you have to wait until they are ready, never really knowing if they will ever be ready. This is pretty stressful for the coach.
The other main problem that is difficult is when the person you are coaching simply doesn't believe that what they are currently doing is sub-optimal. In fact, they may think exactly the opposite -- that what they are doing is amazing and that everybody else is crap for not doing it. To some extent, this happens to everybody. The kicker is that it happens to me (the coach) too. So you often find yourself in some pretty intractable situations where you are pretty sure that you are right, but then so is the other person. You are paid to coach them, but if you get it wrong... you could potentially do a lot of damage.
So the main thing here is that you need to be pretty flexible in allowing people to examine their ideas. Even if you know you are right and the other person is wrong, once you have broached the subject you have to let them find their own way. It can be extremely painful as you watch the person make the same mistakes over and over again until -- finally they get it. At some point you have to trust that the person will get it, while doing your best to do damage control for the mistakes they make while they are learning.
If you have read this far, you may have noticed me use the word "trust" a lot. I think this is the most important part of doing a role like this. If you think the people on your team are crap and can't be trusted to improve, then I think the job will be impossible. If you can believe that no matter what situation you are in today, the person/team will blossom then the job is (barely) possible ;-)
How you get that belief in the first place and how you maintain the belief and trust over a long period of time will largely dictate the level to which you can succeed as a coach, I think. If you ever get a chance to do this role, I highly recommend it, but you need to be prepared to do a lot of sole searching.
Don't fear the mediocre worker, fear the toxic worker.
I've not met a single individual whose contributions were so amazing to make up for their toxic personality. Most all of the toxic people I've worked with have had poor productivity, precisely as a function of their toxicity.
Fractional (1/10) workers, at best.
10x workers, to me, are by definition non-toxic.
Certainly, there are developers who fit the mold of what you're talking about. I'm not suggesting that all toxic developers are 10xers. But the ones to really fear hiring are the ones who produce lots of code while they corrode your organization.
If that's true, then they are not "10x developers". Being super-productive, but only by yourself in a vacuum, is next to useless to any company with more than 1 employee.
There's another important fallacy.
From the viewpoint of a 10x worker, the /10 worker is toxic.
From the viewpoint of a /10 worker, the 10x worker is toxic.
* They have an opinion on every subject, and express one in every discussion ("leadership")
* For any proposed task, they can give a list of plausible-sounding reasons why it should not be done ("technical expertise")
* Nobody challenges them because doing anything that sounds even a little bit like a challenge results in you getting shouted at ("respected by their peers")
Words in parentheses are what management sees.
Every time I have seen a case where these people have persisted, it has been because a clique of them back each other up and the rest of the people in the company are essentially docile. Every competent engineer who finds themselves in this scenario then discovers that they are (a) outnumbered, and (b) able to find a better job somewhere else, so that's what happens.
The net result was there was never a stable team to get anything significant done. The project never did release anything. Needless to say they blamed everybody else apart from themselves. The last I heard, they did two more projects and met the same fate.
You think you need them because they do X, Y, and Z beautifully, but in reality they're destroying morale and tanking everybody else's ability to do A-W.
It's very, very easy in this situation to try to put a band-aid on things and hunker down, try to encourage the other folks to just give the toxic person a little more space. But it never works, and the longer you drag it out the more the A-team folks who aren't toxic will jump ship.
More counter-intuitively, you can take a 10x team full of folks everybody agrees are brilliant, stick them in other teams, and have the other teams tank and folks in the other teams think those folks are losers.
It's a humbling (and enlightening) thing to watch.
ADD: A lot of the myth of the 10 or 100x developer is just a really, really capable guy with a supporting team that is able to meet all of their needs and clear all of their obstacles. The team (including our star) is the cool and irreplaceable part, but the "genius" or "boy wonder" gets all the good press.
I would argue this is almost always true especially in todays world of ever increasing software complexity. Building services, handling ops, fixing bugs, high level architecture, low level architecture, front end, back end, etc... are just impossible for a single person to ever be 10x at across the board. It takes a team to deliver software.
I look at it a lot like Michael Jordan and the Bulls in the 90s. MJ was the 10x player, but without the other hall of famers and all stars on the team they would not have won like they did. The same also goes for the rest of the team.
I'm very close to believing that you'd be better off with hiring smart people right off the street who have never worked in IT -- but get along great and truly care and help each other out -- than you would trying to screen out folks who know algorithms and/or data structures and then filter a second time for not being a douchebag.
I have seen a lot of average ability teams who had social skills kick ass. I've never seen a team with tremendously smart people without them do so. In fact, I continue to be amazed at the brilliant people I meet sometime whom I wouldn't want bagging groceries for me, much less creating an web application.
ADD: If anybody's interested in running an experiment where we create teams basically out of thin air, hit me up. I've been kicking around some ideas in this space for a couple of years or so.
Also there's an interesting relationship between the people, the team, and the company. As it turns out, all are important equally, just in different ways. You really need a pre-existing company to do this.
Finally, I don't care what anybody tells you, work in this area is experimental. Everybody and their brother has a pet theory and most of it is based on limited/non-existent sample sizes or the conflating a plethora of data with an abundance of understanding. If people were robots, we'd just hire robots.
I was not meaning you should start a "normal" project services company - more that most such companies just grab semi-random contractors and throw them into the latest contract, meaning a company that made experimentation the basis of its allocation may have a both a commercial attraction and greater scale than ordinary lab-scale experiments.
Not that I know what you are planning so it's likely to be off target. (Well actually your second sentence suggests taking existing teams in existing company)
"You're looking for three things, generally, in a person," says Warren Buffett. "Intelligence, energy, and integrity. And if they don't have the last one, don't even bother with the first two."
It's a favourite quote of his, mentioned in this speech[1] as well, around the 1:55 mark.
0. http://theweek.com/articles/451860/why-clever-lazy-people-ma...
"How do I know I am doing the right thing?" Every second of every day, you have to keep that in mind.
http://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cla...
1. Such people tend to be very good at what they do, and largely bad at most other, even related, fields. This is not one of those tired stereotypes of a genius who is bad at social skills. There is a good explanation for this: someone who managed to become one of the best in their field, probably did so through concentration of their knowledge in that field, to the exclusion of others.
2. People who are the best of the best can sometimes overspecialize. You know the old saying, to a hammer, every problem is a nail.
In a small company with a few employees you can not afford to have such a person unless their field of expertise IS the domain within which lies the problem you are trying to solve, and even then, you should be careful. In a large company, you can have more specialists, but be careful as well.
It is also important to realize, as the author of the article pointed out, sometimes good enough will do. You do not need the best iOS dev or the best JS person if all they are doing is creating a front end for you new revolutionary AI engine. You probably want to go for the best AI person you can find, however.
This applies to looking for "top experts", and also to "full stack developers".
The more holes and short-cuts you're (painfully) aware of in tools and libraries everyone use every day, to get stuff done.
To be aware of how artefacts are made, is to be afraid. Be that artefact sausages or firewalls. The trick is to then learn enough to know which sausage to eat: or at least find a level of acceptance that lets you enjoy the stuff that tastes good, even when you know how it's made.
And after lunch, maybe you'll serve a json rest api with php.
An important exception to this entertaining aphorism is observed in the Dreyfus Model of Skill Acquisition. Becoming an Expert (in the five level Dreyfus model) in something makes it much easier to become Competent or Proficient in other things. This has certainly been my experience, as things I learn in one area apply to learning others.
The result is that people who never commit to expertise in anything struggle to achieve proficiency, or even competence in anything. They're neither generalists nor specialists... they're just trapped.
That said, I think the article itself is pretty uncontroversial. It's only inevitable that you will mainly find people who hit neither extreme.
E[X] = E[X]
Proof:
E[X] = E[X]
<vigorous applause>
There are people who would rather look good then play well, and then there are true ballers who never even thought about anything but winning the game by any means necessary.
If you are actually 10x and super-duper smart, you're probably undervalued as an employee at any company. For example, companies have actively colluded to lower rates, so you are fighting to be on top of a sinking ship. Although salaries are probably still rising, you should really be a consultant if you actually want to get paid what you're worth. [0]
If your 10x comes from natural talent and work ethic, you should seriously consider moving to security (app, embedded, web, whatever) to help prevent governments from robbing the interwebs of privacy and security. [1] I'm blatantly arguing for 10x people to strive for a 'higher calling' and to get out of line-of-business software development if they are actually this person. In all likelihood, you will probably be better compensated as a consultant in this side of the software field anyway. I do realize there are other noble pursuits outside of security, so good on you if you're chasing that already.
[0] http://www.kalzumeus.com/2015/05/01/talking-about-money/
At the same time, these hiring practices push away the real talent who has better things to do with their time than to play the game. This talent is now sitting somewhere and building a startup of their own. Perhaps even a competitor of yours.
It is easiest way to weed someone out, quickly ask couple canned questions and if you got standard reply then you got your "not hire" mark.
* Codility (online timed) test. I like Codility and their tests; worse case can always learn a new trick and believe my skills (not my recruiting standard answers) would improve if i spent more time solving their problems, so -1 kudos here for me. Never faired better than a 40/50% result and companies that use it don't follow up with applicants that score less than 60% or more.
* Hackerank (online timed) test. Not a good experience at all and separated this entry from the above, instead of just categorizing "online tests", just to express how crappy i felt it was. Weird and poorly described problems (written by the customer, unlike Codility, as far as i perceived, may be wrong). Small textbox in which to type the solution, without any kind of editor like feature (not even syntax highlighting) which you DO have to utilize all the time (no separate editor copy paste), since they do key logging on it, which they then allow the customer to view as video. Actually spent a large part of the minutes or so hacking that texbox (size) on Chrome Dev tools, which was actually the only interesting thing in the whole process :) Since the goal of a test is to demonstrate ones abilities and not have "fun" per se, -1 kudos for me here as well. Although, should also note that i was asked on a Friday (afternoon was it), to complete two of these assessments over the weekend, for a Monday noon interview, which ended up being cancelled 30m before since the company was not happy with the test results (nice one guys!). Sour butt and all, if a company feels entitled to "push around" an applicant like this, what should the applicant think about when it's on a payroll, to say the least.
* The surprise timed sample project test. This was actually the process that irked me. Was asked to set a day and time in which i'd have 2h availability, for implementing a surprise task i'd be sent over e-mail and which i'd have to reply 2h after receiving the task with the result, by providing a github/bitbucket/etc url. Ok. After some persistence, managed to squeeze information in that i would have to implement a web page as to "behave a certain way". The test ended up being about implementing a small django project in which you'd be able to enter an URL in a form, press submit and information about the URL would be displayed (page title, word count, meta tags and other stuff). In the e-mail that contained the task, and only then, was i informed that in the case i did not implement the full solution in the couple of hours, i would have to deliver the full solution at a later date. Not gonna -1 kudo myself on this one, that's for sure. Felt like i was doing free work for a client that either didn't knew what it wanted or did not wanted to tell me :) though i can go as far as understand why they were behaving this way.
* The sample project. Applied for a role in a company which the main language was new in my skillset (Ruby) and was tasked to do a small web app. They were aware of that. Bring it on, challenge accepted! Didn't implement all the features, but learned enough Ruby in one week to, in my opinion, demonstrate enough skills (as in "i know what i'm doing") on the frontend and backend (picked up some Sinatra, Sequel and took the opportunity to utilise Docker Composer in something useful). Ongoing recruitment process.
* The talks. Was invited to the offices for informal chats where i was asked about previous experiences, tech related and test questions. Was told directly what the company was about and had chance to ask what the company is expecting from the role and did my best to pass on my previous experiences (and passion about the tech areas that related to the role). Ongoing recruitment process.
All in all, even though i understand companies need to be able to, for example, put pressure on applicants so as to understand in a short period of time, how they would behave and perform and what their skillset is, i feel that there's some arrogance and irrealistic test methodologies around, but the truth is that if someone asked me the best way to asset a candidate, i wouldn't have an asnwer either. Personally, at the end of the day, i only want to improve my skills, solve real problems, get paid, not becoming better at interviewing.
edit: fixed some typos, added extra sour butt comment :)
It is a good idea that if you find someone who is smarter than you, then you probably should hire them.
But the whole "we're looking for A players only" crap is the mantra of mediocre companies and in my experience has resulted in really messed up hiring practices (Eg: Amazon passed on someone I know (because I worked with him) was smarter and better at programming than I am... while hiring me. Not that I'm bad.)
The basic root of the problem is, if you think you're an A player then you think you're at the top of the heap. This means you're not actually aware of people enough to know the people who are stronger than you... which means you can't hire people stronger than you.
Also, I've seen really good people be mismanaged to the point where they aren't really contributing what they should. The difference between an A player and a C player is sometimes really silly stuff- like not giving them an office or otherwise constantly interrupting them, or refusing to give them specs, etc.
This pursuit of the best of the best also sends you down rabbit holes of looking for college graduates (only) who come from ivy league schools. There are a lot of people coming out of the Stanford CS department, I believe, that I would not hire. (Can't say for sure, because I'm not in California) But the skills of producing great grades at Stanford are not the same skills that produce great software at a startup. Not that Stanford students are bad, bu that it's not really a metric for success.
However, the "over achiever" "type-A" "A player" types tend to think it is, the conflate conformance in the pursuit of success with quality, and that's not accurate.
Yes, you need hard work to graduate from stanford, that's true, and that's a key element. But you also need innovation and critical thinking, and unfortunately, colleges these days actually undermine that. Generally, anyway, I'm not saying all college graduates are mindless sheep. Just that people who are more independant thinkers are less likely to go to college. Or less likely to have gotten a CS degree. (I was studying physics for instance.)
I was actually thinking a lot about this the other day, and it's one of the big differences between say a 5 person engineering org and a 20+ person engineering org. In a 5 person org it may be super valuable to have an independently minded superstar who avoids process but gets things shipped fast while a larger org will actually turn that person toxic by imposing too many restrictions and process on them for them to follow their normal patterns. This is why I think there are some folks that are really good that just jump around from one early stage startup to the next, so they can be mostly free from the bureaucratic politics of large organizations. I wanted to think with the right culture that bureaucracy and politics can be avoided, but my experience has been that eventually these things will shape how your org works, and like Zach says, that's not a bad thing if that org is filled with average people, as long as the process is designed to help those people do the best job they can at large team scale.
"Quality of individuals is only one part of what makes an organization great. Sports is rife with examples of the nimble, well-connected team triumphing over the team of individual superstars."
However the author doesn't really expand on this theme. How does a startup that's not obsessed with hiring "A-level rock stars" groom its people to mesh them into a great organization, a well-connected team? This is not elaborated.
The conclusion of the post is: "Sometimes people just want a greasy burger"... Which does not conjure up images of a team that is greater than the sum of its parts, unless McDonalds somehow qualifies :)
However I wouldn't say the same things when it comes to the first version of your core team. Every "10x" developer can work with 3 people but are they still "10x-effective" (do they even exist?...) when incorporated in an existing 5/6/7 people team? I don't believe so.
We are more interested in problem solvers.
The best answer we had was from employee # 2 - "if it gets shit done, and we ship, sure, why not?".
He knows how to play the game.
I can be super happy to work for company after year or so when I get to know how it is to work there. Before that I can be interested or looking forward to get to know how it is working for them.
Meant to write 'employers'.
No. Next question please.
Does this extend to other tools as well, or just the tech stack?
Or preference <> condescension, if you swing that way.
I'm currently dayjobbing in a world of Java on Windows. It's kinda horrible, especially after recent experience with Ruby, Docker, and fully automated infrastructure. But there's more to the job than tool choices. Fifteen years of legacy code has its own interesting challenges to overcome, and the work environment is terrific in many other ways that I probably wouldn't get at a modern startup.
"Not being happy using X" is preference, for sure, but is also not equal to condescension.
So, you wouldn't hire me, and that's probably a good thing.
I apologize if this seems overly negative, but it really does seem like programmers reach for any opportunity to be viciously divisive.
90+ percentiles have a lot of opportunity and mobility. Why would they want to work on your VC funded cat comparison platform?
As an aside: Michelin Red guides are like Yelp, but Francophile-centric, uses dedicated reviewers instead of crowdsourcing and without the extortion. The issue with Michelin is that places outside France aren't rated very often (6 months to 2 years). And like a newspaper, the physical Red guides get outdated as soon as they're printed. Most people are better off with Yelp, especially if they can determine whether an establishment pays the Yelp "tax" or not. Speaking of which, a great personal project would be an invite-only, private Yelp scraper that doesn't play by the "tax" ranking rules (don't get busted by keeping it anonymous, obviously).
Because the title isn't his point.
His point is, and I quote: "What I think is bad is that there’s so much pride and focus on The Best of the Best of the Best, With Honors."
Which doesn't conflict with 10x. If 95% of the world's best software is written by the top 5% of programmers, the programmer who isn't in the top 1% and barely made the cut at the top 5% is still exceptional.
It's true companies seek pain avoidance rather than pleasure seeking behavior. But pain avoidance also gets you Windows instead of Linux or Mac.
If the question Zach is asking is: "is there such a thing as a 10x engineer?" the answer is yes.
The story from philosophy class was educational though.
Founding a company is hard - so hard I fucked it up. You need to be 10x. Then you can hire who you like.
I'm sorry but, can't we all daydream for more than a minute? How can you get bored so fast?
You could also be so desperate for growth that you hire someone with high hopes knowing full well it's a bigger risk that you'd want to take if you had more time to choose properly.
>The hip thing nowadays is that your software company should hire only A-players instead of B- or C-players, or focus on engineers that are ten times better than anyone else. [...], but I think the sentiment itself is the wrong question to ask.
If people are starting companies, it's not the wrong question to ask. The first 5 programmers hired with fast dwindling startup funds all need to be ultra talented and smart. The competition will kill you with your staff of B & C programmers. When you get to the size of Microsoft with 128,000 employees, you can afford to have some deadwood C, D, F, and 0x employees wasting cubicle space. When you're a startup, you'll go bankrupt because the C players are floundering around not generating enough value in the product to help make the business succeed. It's not a matter of hip or not hip -- it's a matter of survival.
[...]the average company is pretty average. Not everybody can hire exclusively top-tier people. And you know what? That’s fine.
If the readership on HN is plugged into the startup scene, hiring mediocrity is not fine.
EDIT to reply to the replies:
Most of the replies think of "A players" as an absolute ranking on a world scale. Linux Torvalds, etc. That's not what I'm talking about.
Hiring employees or finding a marriage partner is hill-climbing algorithm.[1]
The startup would have some notion of an "A-player" suitable for the company's goals and business standing. It does not mean you try to lure AI expert Peter Norving away from Google Inc to code a bash shell script because you insist on the "best of the best of the best." Whatever pool of candidates your startup can realistically attract, over a constrained time frame, funded by a limited budget -- that's where you find your Local Optimum. To you, you hopefully find your "A-player" although others may view that same candidate as B/C player compared to to someone like Linus Torvalds.
>, the reality was that most of the companies using our hiring software were most interested in finding people that don’t suck.
That's totally opposite from my observations. Startups are most interested in finding great people. They only "settle" for people that don't suck as a consequence of reality. Their hill climbing didn't find their "awesome" programmer so they cross their fingers and hope it works out. The blog post is saying most companies actually prioritize "don't suck hires" over "great hires". The blog has it backwards and that is an outcome instead of the motivation.
As a meta comment, the advice from Warren Buffett, Steve Jobs, Bill Gates, Paul Graham, the YC Sam Altman startup school vids with the dozens of guest speakers (angel investors, VCs), etc all stress the point of hiring the best people you can.
The only sources of advice for "just aim for hiring people that don't suck" are obscure writers of blogs. Why is that? And why does that sentiment have to be delivered as explicit "advice"? Since you can't hire all A-players, you'll inevitably end up with mediocre employees that don't suck even when you don't pursue "don't suck" as a primary goal.
(taken from http://www.joelonsoftware.com/articles/fog0000000072.html)
Microsoft also used stack ranking, one of the worst management practices from an employee perspective that I know about. It operates on the same principle: arbitrarily execute everyone at the bottom of the perceived bell curve.
That leads me to a translation of a quote by Stalin: "Those who cast the votes decide nothing; those who count the votes decide everything." The counting method has a greater effect upon the outcome than the actual votes.
How you measure the worth of someone may have little relation to the value they can actually provide. If you rank people by how quickly they can move 100m, and subsequently hire Carl Lewis and FloJo to manage Justin Gatlin, Tyson Gay, Mo Greene, Carmelita Jeter, and Tori Bowie, you're going to be disappointed when they try to do the same 5m 20 times, or 100m up a vertical rope, or 100m across the surface of a lake, or 100m while carrying a 50 kg backpack, or 100m across ice and snow, or 100m across a tightrope, or 100m on a flat, straight, level track, at local noon, in June, in the Sonora desert, with only 1 L of water.
So that Gates quote sounds to me a bit like begging the question, defining an "A person" as "someone Microsoft ranks well", a "B person" as "someone Microsoft ranks neutrally" and a "C person" as "someone Microsoft ranks poorly". Without establishing the ranking metrics, all he's really saying there is that Microsoft hires people with a good cultural fit for Microsoft.
That doesn't make them the best people. It makes them the best people by Microsoft's method of estimation.
There really are no 10x or 0.1x developers. The worth of the worker cannot be meaningfully separated from the conditions of the job. Someone who is 10x while working alone on his own side project may be 0.1x on a team using a management-mandated process. You can't really know ahead of time how well someone will do when thrown into your unique variety of bullshit. (And pretending that your company has no bullshit does not make it magically disappear.)
i'm curious what this means exactly. having worked for startups in my area of things (graphics, games) i can say that 99% of the startups i see here only require mediocrity in my specialty area at best. most of them would do fine with a bunch of juniors and just one moderately experienced engineer to keep them focused.
solving a simple problem with a sledgehammer language on top of a tower of web stack is not the place you find the exceptional engineer, at least from my native code, down to the metal perspective, but its what most tech startups are about, and lots of them are doing very well with positively mediocre engineers.
i understand there is a different skill set involved in the really niche areas of pretty much anything... e.g. where you need to squeeze the most bandwidth efficiency out of some obscure type of database query by juggling SQL and PHP or .NET libraries or whatever... but that sort of 'excellence' is pretty mediocre from my perspective too.
its like mechanics who prefer working on the F1 car to the tractor. its not even specific to software. however the vast majority of mechanics will have to suck it up and do day-to-day work on pretty normal stuff, just like programmers at tech startups.
so from my perspective it seems like there is no choice but to hire mediocrity actually...
For most tasks that fall out the real core of the business, mediocre developers will do just fine.
while they believe that these are really A-level engineers. It is called placebo effect elsewhere.
The pool of ideal start-up candidates is finite. What if you don't have the budget to execute on a team of A hires?
Something must be fungible. Either you don't actualize your dream at all, or you try to actualize it using sub-A players.
I think most people at least want to try having a startup rather than none at all, rate limited by "talent".
There's a huge gap between actually mediocre and say, @antirez. I only took the article as a suggestion that your expectations and ideas around who to hire be better tuned to your reality. There's an obvious dissonance between the number of companies saying they only hire the best, and the ceiling of available "bests".
IIRC, Amazon (and/or possibly Microsoft, someone can recall better details for me) has a policy of "don't hire the wrong person". They'd rather miss out on awesome than get stuck with sucks. And that's the point of the headline: don't worry so much about hiring 10x as making sure you don't hire 0x, startup or monopoly.
For example airbnb, although very useful, does not require 10x engineering skill. It's a CRUD app, and there is nothing wrong with it.
If your business startup requires 10x skill, that is an existence risk. The only hard thing is scaling a large numbers, and that is a problem you can fix once your making it big, just like facebook.
First, what is the evidence for this claim?
Second, what is the evidence that anyone's so-called A players are actually A players? The best people have better things to do than foof around with startups that may or may not work, like solid, well-paying senior jobs at established companies.
Especially when your back is up against a wall and you've got little time and less money, its more important to have a squad of B players who all pull in the same direction at the same time than to have your 1 mythical 10xer playing hero.
Hiring mediocrity is apparently terrible, but everyone seems content with founding mediocrity.
I was one of the many that thought "meh, rsync" about dropbox. I still do. About the technology.
To be honest, I don't think I gave the business side much thought at the time (I hadn't given much thought to the idea of a sustainable business, other than "make more than you spend"). That said, I think it was obvious to me even before the success how this could be a product people would pay to use. It's crap (for my use cases) -- but it is useful.
Funding mediocrity isn't bad. Funding is about returns -- not beauty.
And talking about founding: I think founding mediocrity is genius. You just have to find un-serviced mediocrity. Like dropbox. Awful idea - but also great idea. Crappy tech (see: security holes).
But it works. People leverage dropbox to increase their productivity. That is great stuff. I'm not sure if it makes me a worse or better developer to think that I'm happy I didn't make dropbox. But I'm certain it makes me a worse business person. I'm fine with that -- but I can still recognize success in that arena.
I'm not sure what to make of that. Maybe I'm suffering for impostor syndrome, but when people mention "A-players", I'm thinking people mean something like "top five percentile". Which, if I'm going to pull names out of a hat, means you have a short-list like:
Steve Wozniak
Bryan M. Cantrill
Slava Akhmechet
Colin Percival
Linus Torvalds
And you've maybe already ruled out the "B-team" (here comically chosen because of their lack of direct engineering visibility -- currently obvious commit sign-offs -- not because of any assumed "lack of ability to make the A-team"):
Alan Kay
Guido van Rossum
Larry Wall (I really have no idea, I don't use perl. I suppose writing perl as a reaction to posix-shell fatigue at NSA actually qualifies for the A-team... but I mean ... perl. B-team. ;-)
I've only met one of the persons on either list. And they are all, way above what I can assume is available for most start-ups. For one thing, even if they all were awful 10 years ago, they've had 10 (30) years to really, really improve.
Now, if you mean that people with some kind of coherent idea of coding, adaptability etc -- or want to "shop down" to something like: https://www.codeeval.com/profile/e12e/ (that's me) -- feel free to send me an email.
But impostor syndrome aside -- I'm not "A-level" in any sense that is meaningful.
That doesn't mean I haven't encountered my share of javascript jockey's or single-minded php masters that have both fewer skills (not so bad) an more of a constrained mind (much worse) than me. But please don't label me "B-level" and "can code a wet paper bag in CSS" "C-level".
There was a time when all I did was code wet paper bags in CSS. Of course, I did web standards before it before it was cool[1] (and I'd learned to spell check emails) -- but I'm not sure how you can tell talent from mediocrity+experience. If you do, you should probably run an HR-startup.
[1] http://www.jerrypournelle.com/archives2/archives2mail/mail84... (Oh, to have one's young hopes so brutally crushed. I suppose I should take some comfort that he probably thought I was a native English speaker).
You'll have a handful of people who are actively destroying value by just being there. These people will make your project later and buggier if you even give them commit access. They're the toxic personalities who, although nominally might be helping to improve whatever they're working on, are causing better people to leave or be less productive because of their personality or attitude. These people must go. I haven't worked with too many, but you can spot them pretty quickly, usually the first time they open their mouth.
Then, you'll have the folks who just clock in and do something every day, but they're not really adding or subtracting value--they may as well be furniture. This will be, by far, the vast majority of people you work with throughout your career. They're sorta competent, probably really nice people, but at the end of the day not exactly fueling the engine of whatever the company is trying to do. Depends on the company to a certain extent, but you'll generally see them everywhere. It's many of the people you currently work with. It might even be you, too. It's not really good or bad to have these folks around, they'll work on a project and you'll break even on it or maybe even meet some internal rate of return. There's really no reason to actively not look for this group.
Finally, there are the people who are net value-adds. Some people call them rockstars or unicorns or whatever. Whether they're 2X or 3X or 5X doesn't really matter--they're NX where "N" is a positive number, and that means they create more value than you pay them. When companies say they're looking for the top-5% or top-1% developer, they're really looking for anyone in this group (given the company's salary range), regardless of their particular "N" value. You'll encounter a number of these people in most companies. Some companies have more than others.
Someone can go from one group to the other either by getting better/worse at their jobs, getting a better or worse role fit, or taking less or more salary. Top talent at one company might be "furniture" at another one simply because they make more there--more than the value they can add.
The people you really want to actively avoid hiring are the net negatives.
You just have a one-dimensional imagination. Don't want to shoot heroin up your veins forever, or have an infinite orgy? Just imagine playing paintball or walking on the beach, the cool sand running through your toes... or whatever. The mind is your oyster.
I'm sure if you were in Heaven, you wouldn't be worrying about making every moment the most exquisite you have ever experienced. It's not a competition; just chill out. You're in Heaven. Or day dreaming, same difference.
How is this the only comment in 100+ to mention the incredible and bizarre fact that a class full of people could imagine hell but not Heaven?
I read it as "Don't Hire ex Engineers"
I was probably thinking of managers...