A talent map is not a list. Here's the question it answers

Clients who ask me for a talent map usually want a list. Everyone in the market who could do this job, with company names.

I can make that list. It isn't worth much. Anyone who knows the tools can pull it in two days. The hard part is something else, and most clients haven't thought about it yet.

A talent map answers this: when you can't fill the role, which requirement are you going to drop?

Why does every search get stuck?

Because requirements multiply. They don't add.

Write three requirements for a role, each cutting out half the market, and you have an eighth left. Add a language, add years in the industry, and the pool is a handful of people, most of them happy where they are.

A job description that reads perfectly sensibly can describe almost nobody. That isn't bad writing. It's arithmetic. So every search gets stuck. The only question is whether you decided in advance what to give up, or let exhaustion decide for you.

When exhaustion decides, it picks a different requirement every time. Hire three people in six months that way and none of them are comparable, and nobody can say what the role actually needed.

I once searched for an IT project manager who could work in both English and Japanese, on a limited budget. Six months, a pool of a few people, none of them willing to move. The requirement I finally dropped was native-level Japanese. Good enough for meetings and email became the bar. The hire closed within a month. Looking back, it wasn't the market that blocked us for six months. It was one line.

How do you decide what to drop first?

Break the role into separate requirements. For each one, write down two things: how long it takes to build after someone joins, and whether it expires.

The order follows from that. Drop the requirement that is quickest to build. Protect the one that can't be built at all.

Two kinds of requirement sit at opposite ends, and I've seen this play out many times.

One is behavioral. Jobs built on repetition and rejection, like door-to-door sales or outbound calling, need a tolerance that people either have or don't. It can't be taught after joining. It looks like the softest requirement on the list and it's the hardest. Drop it and you don't get a slow ramp. You get a resignation inside three months.

The other is deep domain knowledge. The mechanics of an industry, not its vocabulary. Twelve to eighteen months at least, and only if someone inside can teach it.

In between sit language, degrees and years of experience. They're the most visible and the easiest to check, so they look non-negotiable. Usually they're the first to go. Intuition runs the wrong way here. My project manager search is a case in point.

How do you organize the company list so the trade-off shows?

A flat list hides which requirement is doing the excluding. I sort companies into three rings by distance from the target domain.

Ring one: same problem, same work, same customers. Usually your competitors. The smallest pool, the highest cost, and the most friction when you poach.

Ring two: a different business with the same domain knowledge, or the same behavioral profile. Upstream and downstream, adjacent industries, and anyone who sells a different product to the same customers with the same daily routine. This ring usually has the best return, and it's usually drawn too narrow.

Ring three: people who have the requirement you're willing to drop and lack the one you're protecting. Only usable if someone inside can teach. Otherwise it's a hire with no onboarding.

For behavioral roles, draw ring two by what people do every day, not by industry. Someone selling drinks to shops door to door and someone selling payment terminals to the same shops face the same rejections all day. Draw the ring by industry and you lose all of them.

Why do regional offices never fill?

Because ring one has a different thickness in every city, and most companies don't measure it before opening an office.

Tokyo's ring one is thick. In a regional city, ring one for the same role can be empty. Then you have two options: take people from an outer ring and accept a longer ramp, or move the organization to where ring one is. That's a talent decision, and it belongs before the site decision, not six months after opening when nobody has been hired.

I opened several regional offices for one company. The emptiest ring was always the office head. Nobody local had run the same kind of business and built a team from scratch. So we reversed the order. We didn't search for the head first. We hired the front-line team locally, let it grow to a real size with real business, and only then looked for someone to lead it. Candidates saw an office with people and customers instead of a blank sheet, and far more of them said yes.

Audi entering Formula 1 and putting its technical center in the UK rather than Germany is the public version of the same logic. F1's ring one is in Britain, so the organization went to the people. I took that apart in Audi's first year in F1.

What do you do when the overlap is thin?

Split the requirements, draw the rings, lay companies over requirements, and the target group appears: people who have every protected requirement and lack only the one you'll drop. That overlap is where the search starts.

It's often thin. Thin is a finding, not a failure. Treat it as a decision point, not a reason to keep looking harder.

There are only a few responses, and it pays to pick one up front. Accept a gap: hire the closest person and build the missing skill, at the cost of a ramp. Hire on the droppable requirement and grow the protected one internally, at the cost of the longest time to full productivity. Or split the role into two people, at the cost of one more headcount.

The third option is badly underrated. It turns a scarcity problem into a headcount problem, and headcount problems are usually easier. Especially when the role is hard to fill not because any single requirement is rare, but because the combination is.

The same person is a different person in a different team

There's one more layer that none of the above touches.

Requirements, rings, overlap: the unit of analysis is always an individual. Individuals can't answer the question of which people win together. For businesses that deliver through small teams, a market-entry squad, a consulting project team, a founding team, that's the only question that matters.

A team that has already been through hard times together often outperforms five stronger individuals assembled from scratch, even if nobody in it is the best in the market. Break up a team that works and its value is destroyed in that moment. One senior person joining a young team can lift the whole team from the middle of the pack to the top. The same person joining a team that already has a spine adds almost nothing.

So the last layer of a talent map answers how to place these people, not who they are. It's the same idea as what I look for in an interview: events and context, not labels.

What I haven't worked out

This whole method assumes people are hard to move. In a market with short contracts, public transfers and a fixed transfer window, finding people isn't hard at all. Poaching is just how the market works. There, the value of a talent map shifts entirely from who to find to who wins together. Japan is a long way from that. I'm not sure it stays that way.

Last time you couldn't fill a role, which requirement gave? Did you decide that in advance, or did it decide itself?