Hiring for Potential vs Experience

Every hiring decision is a bet on the future, but the two ways we frame that bet could not be more different. When I hire for experience, I am betting that the...

Originally published onanselmfowel.com

Every hiring decision is a bet on the future, but the two ways we frame that bet could not be more different. When I hire for experience, I am betting that the work in front of us closely resembles work the candidate has already done. When I hire for potential, I am betting that the candidate will become capable of work neither of us can fully describe yet. In regulated fintech, where the cost of a wrong hire compounds through compliance gaps and rework, getting this distinction right matters more than almost any other people decision I make.

Hiring for Potential vs Experience
Hiring for Potential vs Experience

I have spent fifteen years building engineering organizations inside payments and lending businesses, and I have learned that the experience-versus-potential question is rarely as binary as it sounds in interview debriefs. The real skill is knowing which roles demand proven track record, which reward raw trajectory, and how to read the difference in a forty-five minute conversation without fooling yourself. This is how I think about it.

What the tradeoff actually is

Experience is evidence. It is the accumulated, observable record of someone having solved problems similar to the ones you have. When I read a resume that says a candidate ran the migration of a card-processing ledger from a monolith to event-sourced services, I am reading a compressed history of decisions, failures, and recoveries. The value of that history is that it lowers variance. I have a much better sense of what this person will do under pressure because they have been under that exact pressure before.

Potential is a forecast. It is my estimate of how quickly and how far someone will grow given the right conditions. Potential is harder to measure because it is fundamentally a prediction about a person who does not yet exist in the form I need. The signals are indirect: how fast they learned the last unfamiliar thing, how they reason about problems they have never seen, whether they ask the second and third question instead of stopping at the first answer.

The trap is treating these as opposites. They are not. A candidate with deep experience can also have enormous potential, and a junior with raw potential can have narrow but real experience. The actual decision is about weighting, and the correct weighting depends entirely on the shape of the role and the maturity of the team they are joining.

When experience is the right bet

There are roles where I refuse to hire for potential, and I am unapologetic about it. If I am bringing someone in to own PCI scope, to design our approach to strong customer authentication, or to be the final reviewer on changes that touch settlement, I want scars. I want someone who has already been on the receiving end of a failed audit or a reconciliation break that took the team three sleepless nights to find. That kind of judgment cannot be reasoned out from first principles in the moment it is needed.

Experience also wins when the cost of a slow ramp is high and the team has no slack to absorb it. A founding platform engineer at a five-person company does not have the luxury of a six-month learning curve. The first hire into a new compliance function needs to know what good looks like on day one because there is nobody above them to correct course. In these situations, potential without a baseline of relevant experience is a liability I cannot afford.

The mistake I see most often is hiring brilliant generalists into roles that punish slow ramps, then being surprised when raw talent loses to compounding regulatory complexity. Some domains do not forgive the learning curve.

When potential is the right bet

The inverse is just as true. There are roles where experience is nearly worthless and potential is everything. Anything genuinely new to the company, anything where the playbook does not exist yet, rewards people who build their own maps. When we moved into embedded lending, nobody on the market had ten years of experience doing exactly what we were attempting, because the regulatory and product combination was novel. The people who succeeded were not the ones with the most adjacent experience. They were the ones who learned the fastest and were comfortable being wrong in public for a few months.

Potential also wins when you are building for scale rather than for the present. If I am hiring a senior engineer who I expect to become a staff engineer or a team lead within two years, their trajectory matters more than their current ceiling. A candidate who is already excellent but plateaued is worth less to me over a three-year horizon than someone slightly behind today but climbing steeply. The discount rate on potential is low when your time horizon is long.

There is also a simple economic argument. Experience is expensive and scarce; potential is comparatively cheap and abundant if you can identify it. A team that can reliably hire and develop high-potential people has a durable cost and quality advantage over one that can only buy finished talent on the open market. That capability is itself a competitive moat, and it is one of the few that compounds.

Reading potential without fooling yourself

The hardest part of hiring for potential is that the signals are easy to fake and even easier to misread. Confidence reads as competence. Articulate people seem smart. Candidates who resemble the interviewer get scored higher. Every one of these is a bias that masquerades as a read on potential, and every one of them has cost me a good hire or saddled me with a bad one at some point in my career.

What I have learned to look for instead is concrete evidence of learning velocity and depth of reasoning, not polish. The questions that work best are not hypotheticals but excavations of real situations:

  • Tell me about something you understood deeply six months ago that you now think you got wrong, and what changed your mind.
  • Walk me through the last time you had to learn a system you had no context for. What did you do in the first day, and the first week?
  • Describe a technical decision you made that you would defend even though most of your team disagreed at the time.
  • What is something in your current domain that most people get wrong, and why?

These questions reward reflection and penalize rehearsed narratives. A candidate with high potential will surprise you with the texture of their answers. They will volunteer the messy middle, the dead ends, the thing they only understood in hindsight. Someone coasting on charisma will give you a clean story with a tidy moral, and clean stories are almost always retrofitted.

Reading experience without overcrediting it

The symmetric error is overcrediting experience. Ten years of experience is sometimes one year of experience repeated ten times. A long tenure at an impressive company tells me the company hired well and the person did not get fired; it does not tell me they did hard things or grew. The seniority printed on a resume is a claim, not a verified fact, and my job in an interview is to verify it.

I probe experience the same way I probe potential: by going deep on specifics until I hit the bottom of what someone actually knows. If a candidate claims they led an incident response, I want the timeline, the decisions, the tradeoffs they rejected, and what they would do differently. Real experience has fractal detail. You can keep zooming in and it stays coherent. Borrowed or inflated experience gets vague quickly, and the vagueness usually arrives right at the point where the genuinely hard decisions would have lived.

The other failure mode is experience that does not transfer. Someone who scaled a consumer social product to millions of users has real, hard-won experience, but very little of it may apply to the failure modes of a payments ledger where correctness beats availability and every edge case has a regulatory shadow. Relevant experience is the only kind worth paying a premium for, and relevance is more specific than most resumes admit.

The asymmetric cost of getting it wrong

Not all hiring mistakes cost the same, and the asymmetry should shape how you weight the bet. Hiring an underqualified person into a role that demanded experience is usually visible and recoverable, if painful. They struggle, the signs are obvious within a quarter, and you can intervene. The damage is real but bounded, and it is the kind of mistake your organization is built to catch.

Hiring an over-experienced, low-potential person into a role that needed growth is more insidious. They perform adequately, they do not trip any alarms, and they quietly cap the ceiling of the team around them. A senior engineer who has stopped learning but knows enough to look competent can sit in a critical seat for two years and leave the team exactly where they found it, having blocked the growth of everyone junior to them. That cost is invisible on any dashboard, which is precisely why it is so dangerous.

In regulated environments there is a third category that dominates the others: the confident hire who does not know what they do not know. Someone with surface fluency in compliance who has never actually owned an audit can do more damage than an honest novice, because their confidence suppresses the questions a team should be asking. I would rather hire someone who says they need to learn our regulatory posture than someone who assumes their last company's posture transfers cleanly. It rarely does.

Building teams that can actually develop potential

Hiring for potential is only rational if your organization can convert potential into performance. This is the part most leaders skip. They fall in love with the idea of finding diamonds in the rough and forget that a diamond in the rough still needs cutting, and cutting requires infrastructure. If you have no mentorship, no code review culture, no documented standards, and no senior people with time to teach, then hiring for potential is just hiring underqualified people and hoping.

The teams that develop potential well share a few traits. They have a critical mass of strong, secure senior engineers who view teaching as part of the job rather than a tax on their time. They have systems that make mistakes safe and recoverable, so junior people can take real risks without catastrophic blast radius. And they have honest, frequent feedback, because potential only converts to skill when the person can see clearly where they are falling short.

This is why the experience-versus-potential question is partly a question about your own organization, not just the candidate. The right answer for a mature team with deep bench strength is different from the right answer for a thin team running on fumes. A team that can teach should index toward potential because it has a multiplier the market does not price in. A team that cannot teach should be honest with itself and buy experience, because its potential hires will languish.

Balancing the portfolio across a team

I do not make the experience-versus-potential decision one hire at a time in isolation. I make it at the level of the team's portfolio. A healthy team has a deliberate mix: enough experienced people to set the standard and catch the dangerous mistakes, and enough high-potential people to keep the team learning, cheap to scale, and resistant to ossification. An all-veteran team gets expensive, complacent, and brittle. An all-rookie team is fast and cheap until the first serious incident exposes how much judgment it lacks.

In practice I think of it as managing risk across the group. When I have just made a high-experience, safe hire into a critical seat, I have bought myself room to take a bet on potential in an adjacent role. When the team is already carrying several developing engineers who need attention, the next hire almost certainly needs to be someone who can contribute and mentor from day one. The composition is dynamic, and the right next hire depends on what the team already has, not on an abstract preference for one type over the other.

This portfolio view also protects me from my own biases. Left to instinct, most leaders over-index on whichever type resembles themselves. Deliberately balancing the mix forces me to ask what the team actually needs rather than what feels comfortable to hire, and that question almost always produces a better answer than my gut alone would.

Conclusion

Hiring for potential versus experience is not a philosophy to pick once and apply everywhere. It is a judgment to make freshly for every role, calibrated against the cost of a slow ramp, the maturity of the team, the time horizon of the bet, and the regulatory weight of the work. Experience buys you lower variance and faster impact where the work is known. Potential buys you trajectory, cost advantage, and adaptability where the work is not yet written down. Both are bets on the future, and the discipline is in matching the bet to the conditions rather than defaulting to whichever feels safer. The leaders who get this right are not the ones with a strong opinion about which is better. They are the ones who stopped asking that question and started asking what this particular role, on this particular team, at this particular moment, actually requires.

Chat with us