4 ms·

I interview Business Development people just like I interview developers. I want to see them "code". I have them open up their CRM tool of choice. Then I hav

by pkaler 14y ago

I interview Business Development people just like I interview developers. I want to see them "code". I have them open up their CRM tool of choice. Then I have them explain their funnel. They should be able to step me through how they've setup their stages: Qualifications, Needs Analysis, Decision Makers, Value Proposition, Quote, Negotiation, etc. Then I have them deep dive on a particular deal and have them explain each of these stages for this particular deal.

rscale 14y ago
I'd be extremely reluctant to hire somebody who was willing to give me a guided tour of another company's CRM. Even ignoring the ethics of the request, if somebody is willing to act against their current employer's wishes, they're almost certainly going to act against my wishes as well. There are plenty of ways to check an applicant's abilities without requesting access to confidential information. This is as true for biz dev as it is for coders.
- DenisM 14y ago
  Where did you yet the idea that GP asks for confidential CRM deployment? I think you are jumping to unwarranted conclusions.
  - rscale 14y ago
    I got the idea from his post. The vast majority of BD candidates can't open a CRM and provide detailed information about it's structure and the deals it contains without revealing confidential information. As such, I think it's a poor idea to make that a standard part of the interview process. You mounted an unwarranted defense. There are edge conditions where somebody could do so without a problem, but they're the exception that proves the rule.
notahacker 14y ago
Hiring a salesperson on their ability to describe pipelines in abstract terms and relate it to a CRM is a bit like hiring a programmer based on their ability to describe a particular software pattern and relate it to an application.(1) Sure, most worthwhile candidates will give broadly similar answers showing they understand the theory behind what they're doing and had formal training in it, but can they actually write the code? If you want to see them "code" get them to sell to you. Do they ask good questions? Can they relate answers you've given to an actual proposition? Are they so thorough and accurate they've ended up with a watertight business case for that proposition? Have they identified other hypothetical stakeholders they're going to need to ask similar questions to present similar cases to, and how far you'll help them with that? How do they respond to your 11th hour attempt to reduce the price? That's "coding". The other stuff is architecture: important but pretty useless without the fundamentals unless you're looking for a pointy haired guy. Plus the really good sales guys often intuitively breeze through a lot of those official "stages" in one call or meeting, whilst appearing "stuck" at another stage for ages, and are completely comfortable with that because they know what aspects of the sales cycle they can and can't control, and why they'll be waiting. This probably sounds less impressive than the textbook example of steady progress a good bullshitter should be able to come up with. (1)arguably worse: probably the best explanations of pipeline organization you'll hear are from underperformers in large companies who have to explain their activity to their line manager in more regular review meetings. The guy that sucks at writing code probably gets less regular invitations to meetings to decide on application architecture.
orangethirty 14y ago
Really? That doesn't sound very effective. May you shed more light into it? I'm really curious to learn more. In my experience, people who can sell are better off tested with actual selling and not the administrative side. They can always learn how to do the things you describe, but not everyone can sell.

by pkaler 14y ago

rscale 14y ago

I'd be extremely reluctant to hire somebody who was willing to give me a guided tour of another company's CRM. Even ignoring the ethics of the request, if somebody is willing to act against their current employer's wishes, they're almost certainly going to act against my wishes as well. There are plenty of ways to check an applicant's abilities without requesting access to confidential information. This is as true for biz dev as it is for coders.

DenisM 14y ago
Where did you yet the idea that GP asks for confidential CRM deployment? I think you are jumping to unwarranted conclusions.
- rscale 14y ago
  I got the idea from his post. The vast majority of BD candidates can't open a CRM and provide detailed information about it's structure and the deals it contains without revealing confidential information. As such, I think it's a poor idea to make that a standard part of the interview process. You mounted an unwarranted defense. There are edge conditions where somebody could do so without a problem, but they're the exception that proves the rule.

notahacker 14y ago

Hiring a salesperson on their ability to describe pipelines in abstract terms and relate it to a CRM is a bit like hiring a programmer based on their ability to describe a particular software pattern and relate it to an application.(1) Sure, most worthwhile candidates will give broadly similar answers showing they understand the theory behind what they're doing and had formal training in it, but can they actually write the code? If you want to see them "code" get them to sell to you. Do they ask good questions? Can they relate answers you've given to an actual proposition? Are they so thorough and accurate they've ended up with a watertight business case for that proposition? Have they identified other hypothetical stakeholders they're going to need to ask similar questions to present similar cases to, and how far you'll help them with that? How do they respond to your 11th hour attempt to reduce the price? That's "coding". The other stuff is architecture: important but pretty useless without the fundamentals unless you're looking for a pointy haired guy. Plus the really good sales guys often intuitively breeze through a lot of those official "stages" in one call or meeting, whilst appearing "stuck" at another stage for ages, and are completely comfortable with that because they know what aspects of the sales cycle they can and can't control, and why they'll be waiting. This probably sounds less impressive than the textbook example of steady progress a good bullshitter should be able to come up with. (1)arguably worse: probably the best explanations of pipeline organization you'll hear are from underperformers in large companies who have to explain their activity to their line manager in more regular review meetings. The guy that sucks at writing code probably gets less regular invitations to meetings to decide on application architecture.

orangethirty 14y ago

Really? That doesn't sound very effective. May you shed more light into it? I'm really curious to learn more. In my experience, people who can sell are better off tested with actual selling and not the administrative side. They can always learn how to do the things you describe, but not everyone can sell.