Don’t hire an expert to do it for you! That’s a Recruitment Anti-Pattern (RAP).
(Bad) IDEA: “To hire a skill you don’t have, pay an expert to do it for you, borrowing their knowledge and expertise”
Background
There are three common types of hiring. Two of these are easy, one of them seems impossible:
- High-skilled/senior role that you used to do yourself / have worked with such people extensively yourself
- Low-skilled role where you have a laundry-list of required traits/skills/experience
- High-skilled/senior role that you’ve never done yourself and don’t understand
That last one causes a problem:
How do you evaluate candidates in a skill that you don’t have yourself?
There are two particularly common situations where this applies:
1. Hiring your first Manager
How do you hire an Engineering Manager if you’ve only ever hired/managed ICs (Individual Contributors) before? What do you look for? What makes a good/bad candidate – how should you measure these people at interview?
2. Hiring a new vertical (e.g. Mobile/iOS when your existing team is all Full-Stack)
What questions do you ask, and what counts as “good” or “bad” answers? How do you ask technical questions when you won’t understand the answers yourself? How do you even choose which questions to ask, without revealing your own ignorance?
Belief/Expectation
If we hire a Consultant (usually: a former CTO, an Investor/Advisor, or a specialist Contractor) to guide us on the evaluations – to feed us questions to ask, and tell us whether the answers were good or bad – then the problem goes away, and it’s becomes like the simpler case where we were hiring roles we understand!
Reality
Most tech-industry ‘experts’ only perform well when judging their own expert-area(s) – otherwise they are no better than you (they’re using generalisms to do the evaluation – which is exactly what you’d be doing without their input).
However … you know something your expert cannot: the context, the journey, the vision, and the shared values you want in your team. The advice from an expert when looking at candidates is almost always wrong because it does not / cannot include these insights. They will make their own assumptions based on the kind of team they want/like, for their current/recent company – instead of assumptions for your company, with your existing team-members and challenges.
Corrective Action
Push the burden of proof onto the incoming employee: if you are hiring someone for their skills, and especially ‘skills we don’t already have’, then a core part of the job is going to be ‘teaching the rest of us how to work well with you/your skillset’, and communicating to their colleagues any area-specific needs, warnings, good practices, etc.
This solves the problem both more elegantly and more honestly: evaluate the candidate on the same issue they’ll be judged on in their role (how well did you enable [new skill x] to be integrated into our existing team/practices/roadmap?).
In practice, the best way to do this is to start by defining the known boundaries of the role: what info you expect to provide, what info you want to receive back, which items you want this person to be autonomous at, which ones you expect them to bring to you / the team for feedback and discussion, etc. (if you don’t know how to interface to this role as a manager/colleague, then … that is one of the boundaries you can define! Have the interview candidates tell YOU how they feel that interface should work. If it’s convincing and sounds like it would work for you, then hire them)
To evaluate their performance at interview you look for how convincing they are – does this person seem like someone who’s saying the right things, at a level you understand? Are they understanding your own questions/concerns and dealing with them effectively? … if not, then their chances of dealing with this job – as the first of their skillset in your company – are low.
More Anti-Patterns & Recruiting Advice
Add your email below to get notified when I publish new Anti-Patterns and related advice.