The job title is a filter, not a label
How you name a role determines who shows up — and what they expect.If you've struggled to name a critical role at your company — or kept attracting the wrong profile from an open search — this article explains why. You'll learn how job titles load assumptions before the first conversation, why the naming exercise is a definition exercise in disguise, and how the same dynamic plays out across partnership types and product features.
We had a job post called "Entrepreneur in Residence" that had been live for over a year.
The responsibilities were clear: own the founding team relationship, lead the product, be accountable for what gets shipped and what gets signed. But the title was attracting the wrong conversations — people who wanted to incubate a startup inside Holdex, not people ready to co-lead one.
When we renamed it "Partner," the inquiries changed. Not in volume. In the assumptions people brought to the first conversation.
The title had been acting as a filter the whole time. We had just set it wrong.
A label is a signal, not a description
When you write a job post, the title isn't a summary of what the person does. It's shorthand that activates a set of expectations in anyone who reads it — how the role works, what success looks like, how they'll be managed, what the relationship with the business will feel like.
"Entrepreneur in Residence" activates an incubation model: the EIR has their own ideas, gets runway and resources, and eventually separates. "Partner" activates a co-operator model: the Partner is accountable for a shared outcome and earns based on results.
Same day-to-day work. Different contract with reality.
This matters because people who self-select in based on the title arrive with assumptions already formed. If those assumptions are wrong, you spend the first weeks correcting them instead of building. The best candidate for the role as you've actually defined it may never apply — because the title told them it wasn't for them.
The naming exercise is a clarity exercise
Founders tend to treat the title as the last step — something you do after you've figured out the role. It's actually the first step, and it does diagnostic work.
If you can't land on a clear name, the role itself usually isn't clearly defined. The difficulty isn't semantic. It's a signal that there's still ambiguity about what the person will own, how they'll be evaluated, or what authority they'll have.
We went through several iterations before settling on "Partner." Each attempt surfaced a different gap:
- "VP of Growth" implied marketing and sales — not what we meant.
- "Head of Product" implied internal scope, not work alongside founding teams.
- "Entrepreneur in Residence" implied a temporary arrangement with exit baked in.
Each wrong name was pointing at a real confusion about the role. The naming process forced us to be precise about what we were actually asking for.
The same dynamic appears everywhere
This isn't unique to job posts. It applies to any label you attach to a working relationship or product feature.
Call a working arrangement a "pilot" and partners treat it as temporary — low investment, reversible, not something to build infrastructure around. Call it an "integration" and they build toward it. The name shapes behavior before the relationship starts.
In DeFi and fintech, where the vocabulary of roles, products, and structures is still being invented, founders run into this constantly. Borrowing terms from adjacent worlds — VC structures, traditional finance, enterprise SaaS — loads the wrong expectations into the room. "Liquidity partner" means something different in TradFi governance and in a DeFi protocol. "Strategic advisor" carries implied availability and accountability that rarely matches the actual arrangement. When those assumptions go unexamined, they surface as misaligned incentives later.
Naming as a first step
Founders who have been through this tend to add a naming step early — not as a branding exercise, but as a definition exercise. What assumptions does this name load in? Are those the assumptions we want? If not, what word does the job we actually need?
The right name also changes what you screen for. Once the role is named correctly, you can look for the orientation and judgment that fit the actual work — not credentials that match a description. That shift matters: the people who self-select based on the right signal tend to have the right operating model already. The ones who filter themselves out based on the wrong name are usually the ones you'd have to unteach.
What to look for in a technical partner before the first conversation is a separate question — but it starts with having named what you are actually looking for.