First, go read Joel Spolsky's short book about finding talent, Smart and Gets Things Done, so we're talking the same language.

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?

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.