The expert-layman problem is similar to the principal-agent problem, but also different in big ways.
Laymen, by definition, don’t have the expertise they need to solve many specialized problems. They depend on experts to help them. How do you recognize an expert, when you lack that specific expertise?
For example, I’ll never be a good accountant or CTO — how do I recognize people who are great in the field? On what basis could I ground a decision? Every founder can think of similar disciplines that they have not mastered, and every founder faces the challenge of hiring outside their expertise again and again as they scale.
An agent acts on behalf of a principal, executing tasks in the service of the principal’s interest. Because agents are closer to the action, and more immersed in the details of their domain than the principal, they have an advantage they can use to deliver suboptimal results while concealing conflicts of interest. In public companies, this often takes the form of CEOs and other corporate leaders being overpaid, at the expense of the shareholders. In tech companies, it often takes the form of software engineers sand-bagging product managers.
So the principle-agent problem is about managing someone else to do the work for you.
In contrast, the expert-layman problem is about the moment of choice: hiring someone outside your expertise, or finding someone who can tell you how to do the work better.
It comes up all the time in consulting. One of the main reasons companies hire consultants is because they need an expert opinion about a domain they don’t understand. And consulting engagements go wrong all the time, partially because the client did not choose the right expert. But the reasons why they are hiring a consultant are the same reasons why they can’t recognize a good one!
How do you recognize expertise in a domain you have not mastered?
The easy, bad way: Many companies cheat by going with social proof. Let’s just hire McKinsey.
The lucky way: Other people hack the process by tapping their networks and asking people they trust for advice. Not everyone has a network like this to tap. In venture, VCs see certain problems repeatedly, and know people who can solve them, in areas a new founder might stumble through. That’s why getting the right investors has huge repercussions on other decisions down the road. (Yes, all cash is equally green, but only some cash gets you the best networks and advice.)
The hard way: Hard-core interviews…
Interviewing Outside Your Expertise
In most fields that you, a founder, will hire for, the candidate should have clear mental models of how things work, what they need to do to get things done, and how they measure success or failure.
Good ones can explain their workflows, why they make certain decisions, and how they adjust their behavior to improve outcomes. They can illustrate anything they say with a concrete instance.
Better ones can go into granular detail about every aspect of their work, and also explain that work to outsiders. They are great communicators, who can zoom in and zoom out. By the end of the call, they should have taught you something valuable and new.
The best ones have often invented terms to describe the things they encounter when going down professional rabbit holes, can talk about their work with humor, and shows signs of extracurricular interest in their profession (their recreational reading shows their work is also a passion project).
It’s actually easy to surface clues about quality during an interview. You just have to establish the expectation that you will be leading a gentle but persistent interrogation into the fine details of a candidate’s work, and probably asking a lot of “dumb questions”.
That is, when you ask a question, they should expect that you will ask several followup questions on the same topic, probably interrupting them if they embark on a long monologue that’s a little too prepared.
If the candidate makes a general statement, that is your cue to ask if they can give a concrete example of it. When I speak with founders about a product they’ve already launched, I don’t want to hear about “users”. I want to hear about the last user they spoke with, the problem that person was solving, where they worked and the role they held. That’s concrete. Then I want to hear from the founder how they helped that user.
If you are interviewing a salesman who says “we were targeting engineering directors”, then I want to hear why. It’s not enough to say that they are the economic buyer. What’s the maximum amount of money they can spend without seeking external permission? Can they self-onboard or do they need IT to sign off? Do they pay with a credit card or through a procurement department? Have you tried to sell to other roles? How did that work out?
If a candidate can’t break down their workflow into distinct stages, and talk about the decision tree that leads them to next steps, they don’t know their business well enough to do it for you.
If the candidate becomes hand-wavy at any stage, even after you reassure them that you want to dig deep, then the interview is over.
A lack of concrete examples is a dealbreaker.
The inability to reason about a hypothesis, to say why they decided on one path of action and not another, is a dealbreaker.
It’s better to just say “no.” The expert has not passed muster.