Done? Okay, perhaps not, but my takeaway from his book is that it's your responsibility to do anything and everything to find people with general intelligence and who work hard.

That doesn't, on the surface, sound very complicated. Our brains are basically hardwired to be able to make these kinds of snap judgments and if Malcolm Gladwell is to be believed, we should listen to this intuition. But then, why do the hiring practices of most of the companies I've worked for often fail?

Photo by Alan Chia

I think one reason is the tendency for people to breakdown teams into roles. They think of their teams as being made up of big squarish building blocks with pretty colors indicating where they belong in some grand scheme. They jostle them around occasionally, repaint the blocks, write long winded job descriptions about them.

And it's only natural, building a team is a thicket of interdependent decisions that have to be made promptly and at great risk/cost. Theoretical physicists call this simplification process: "idealization".

It's a perfectly reasonable way of solving complex problems. And in the main, for a large company with a sizable base of employees with diverse talents, role-idealization is a reasonable enough approximation. They can absorb a less than ideal person because there's a better chance that some arrangement of all the parts will be able to accommodate them (including the arrangement where you hide them in a corner so they stay out of the real team's way).

But for a small team, one bad hiring decision can be deadly. There's a reason why people use the euphemism "role-player" to denigrate a person who is useful for some specific task now, but will someday become useless.

A slightly better approximation for thinking about fit would be to think of roles in the same way we think about skills. Each candidate is going to have some mixture of roles they can play, each with a degree of competency. Instead of thinking about a person as "a developer", think of them like "a developer who knows how to manage people and run a project".

Start by making a map of roles that are needed to be successful: A base of product management, a dash of people management, a hunk of sales, and 2 cups of developer.

Then figure out how the multiple roles of the existing team fits together against that recipe. Assuming you still have some gaps (and often you don't really, you just think you do because you have money burning a hole in your accountant, or because you're desperate to go faster) you are now ready to hire.

Sourcing multi-dimensional candidates is tough in a world where people search for jobs by role, job boards are all organized by role and recruiters filter resumes using role-related keywords. You can try to play job description mash-up, "Project Manager/Developer/Marketer", and while this may attract just the right person, you're actually much more likely to just accumulate a blizzard of lower-quality resumes for each of the roles.

So choose a primary role, write the job description to emphasize that you're looking for a flexible candidate rather than list a litany of "responsibilities", and let your recruiter know that you're looking for people with a range of experience.

Once you've winnowed the candidates down, how do you go about interviewing them?

I've always been an advocate for measuring candidates by watching them do the thing you want them to be doing. For development, this involves asking them to bring in a laptop with an IDE installed. For product management, this might mean giving them a hypothetical product to build and asking them to create a backlog for it.

As you construct an interview loop, assign a person to each role you wish to test the candidate against. Multiple separate interviews for any role you're particularly keen to fill. Include a lunch or cool down interview with a leadership type, but think of it as your opportunity to sell your company to them as opposed to the more typical interview for "team fit".

What if you don't have an [INSERT ROLE HERE] to interview them for [ROLE]? It might not matter. Have someone who works closely with that role conduct the interview anyways. A good developer will know what a great backlog looks like and a good product manager should know what great coding looks like.

After the interview, get all the interviewers in a room and have them secretly cast a yes/no vote for their interview. Do NOT include the person who did the lunch/cool-down, as this has a high likelihood of being a false-positive/negative. Briefly review what you were looking for in a candidate in the first place, then have everyone show their votes.

There are no hard and fast rules on how to consolidate the feedback into a decision. Sometimes one thumbs down is enough. Other times the person is such a great find in one role that this trumps their unsuitability for every other role you care about.

What you're looking for is for the group to come to a consensus on whether or not to hire. The team should have a working knowledge about the challenges they're facing and you should expect a healthy debate about "what we need" vs. "is this person the right one". At the end, if you can't reach consensus, then pass on the candidate. Either you don't really know what you need yet or the candidate isn't really the one you need right now.

I have a reputation, in my social and professional circles, for being something of a curmudgeon.

I find this to be roundly unfair.

Okay, yes, over a pint, I'm more likely to argue with you than agree with you, that's true. And yes, I tend to be rather critical, and vocal, about things I think could be going better. I just like to be convinced of a thing before I believe it. But once I believe a thing, I become its earnest champion, arguing for it and vocally criticising all that...

Okay, perhaps they have a point.

I know the exact moment when I turned. I was standing at a podium in high-school. My first debate.

Debate

For the uninitiated, formal high-school debate, the kind the National Forensic League gives out certificates of achievement for, is a peculiar institution.

It's a highly structured speaking format with lots of rules and lots of insular jargon. It has about the same relationship with a lively argument as chess does with a fist fight.

There is a resolution is chosen at the beginning of each year that forms the major premise for all of the debates that follow. My year it was (from Wikipedia): "Resolved: That the United States government should reduce worldwide pollution through its trade and/or aid policies."

An Affirmative team posits arguments in favor of the resolution while a Negative team looks to undermine or refute their claims. Judges decide a winner based on whether enough of the Affirmative team's arguments are left standing after a few rounds of discussion.

The peculiar part is that to win, you don't have to be right.

Instead, the goal was to be the one with the best Evidence. Each team in a debate brings with them great stacks of index cards with bits of text glued to them. These make up all the arguments, counter-arguments, counter-counter-arguments, and counter-counter-counter-arguments that you'll need. The best teams obsess endlessly about Evidence and you could generally size up an opponent based on the size of the stash they hauled into the room with them.

Back to the Podium

I was on the Negative. I'd just heard the Affirmative opening arguments, something about how the US should promote nuclear power, and being pre-curmudgeon at that point, I was quite inclined to agree with them. Their points seemed perfectly valid. Nuclear power seemed to be an elegant solution to the world energy problem. While it had/has problems to be addressed, there's no reason why these technical problems couldn't be solved, in time, with better technology.

I suppose I could have just walked off and dropped the class, but I recognized this as a game, and I liked playing games. I was good at games. And also being a good student, I had collected many pieces of Evidence to counter this specific argument, so had a chance here and now to win the argument, even if I believed I was wrong.

So I launched into a rebuttal of each of their arguments, hand waving and pausing for effect while the Affirmative team scurried about trying to find the index cards with the right counter-counter-counter-counter-arguments.

We won that debate. My partner and I won all the debates that year.

(This is nothing particularly to brag about. This was debate class, not debate club. The bush leagues of debate. My teacher later lobbied me to join, but I ignored him because it would have interfered with football, which TV had lead me to believe led to girls, and, well...puberty is its own best rebuttal.)

It was at that moment, for something as silly as wanting to win a game, I began to learn how to suppress my emotional and subjective beliefs from the exchange of purely objective ideas. Or perhaps more properly, to temporarily direct and shape my beliefs towards a contrary viewpoint to allow me to argue it more strongly and convincingly.

Pessimism About Products

As it turns out, this is a wonderful skill to have.

Very often, we are put in situations where our beliefs are put into conflict with cold hard reality. The revenue projections that were missed, a heartfelt promise you made to your team but couldn't keep, or a customer looking confused and concerned at your product roadmap.

In these situations, there is a strong temptation to externalize and rationalize what has happened. The market wasn't ready, the team didn't work hard enough, the customer just doesn't get it. Its far better if you can be self-critical, take your lumps, and move forward with a newly straightened perspective. Better still, if you can see ahead of time when your beliefs are leading you over the cliff's edge.

To an outside observer, this can appear to be pessimism. Particularly if that observer shares the errant belief that should be changed.

Most people loathe changing what they believe and fear the uncertainty that follows discovering that they are wrong. They therefore loathe and fear the pessimist, who seems to be tearing away at the fragile veil that lets them act with confidence.

Those people squander confidence. Yes, it can inspire a team to do remarkable things. Terrible risks are sometimes only undertaken because of misguided confidence, and great rewards reaped as a result. But if you deal in it, and it fails the test of time, you're marked a fool. Being thought of as a fool is far worse than being marked as a pessimist.

Use confidence at the moment of truth, at the end, rather than the beginning. When there's one last unimaginable leap to cross and you need the team to come with you.

Now, this isn't to argue that I should be forgiven all my trespasses as a curmudgeon. I'm a creature of emotion as much as reason, just like the next guy. Sometimes I argue out of bad habit, rather than any particular insight into a situation. Sometimes I'm the starry-eyed true believer that can't see the imminent danger just in front of me.

But, if you're not persistently and actively challenging your own assumptions, then you might try a little pessimism yourself.

One of them should be an extrinsic/extroverted type who can build consensus and orient towards customers or executive management. One of them should be a died in the wool hacker who will pull all-nighters for the sheer joy of writing code. One should be a creative problem solver who can think around corners and design elegant but practical user interfaces.

That doesn't necessarily mean one of each, in fact, it's vastly preferable if each person can hold down one or both of the other two roles in a pinch. People do go on vacations, or get sick, or decide to quit to pursue their lifelong dream of being a musician.

3 is better than 2 because there's always someone to break ties. 3 is better than 4 or 5 because a larger group never really gets into the "zone". That magical place where you have a whole day of pure productivity, barely speaking to each other but acting in perfect alignment.

Another benefit of 3 over larger teams is the possibility of creating product diversity. Instead of one team of 6, how about two teams of 3 working on decoupled products that serve related goals?

Ah, but you say, why not have a team of 6 develop two products serially?

Well, because of the law of diminishing returns for both time and risk. Sure, you'll plan to deliver two products in six months, but in month four when you haven't quite worked out all the features in the first product, it will seem brutally logical to keep throwing the good money after the not-yet-bad.

Plus, good products need time just as much as effort. Customers will always come slower than you expect them to and the team will need time to marinate in the problem and marshal expertise with the technology and processes.

But you say, some problems simply can't be tackled by 3 people!

I'm not so sure. Every problem I've encountered can be broken down into smaller ones. Sometimes these sub-problems are coupled, such that one cannot deliver value without the other also succeeding, but in these instances the successful team will probably figure out a workaround to buy the other team some time, or even make their sub-problem irrelevant.

And that last point is very important. Resiliency to failure. The survival rate from start of development to successful product is something like 40%. Having more product teams building a diverse set of products greatly increases your chances of at least one being successful. Ask any successful VC how many baskets their eggs are into.