Most Salesforce leaders don’t have a hiring problem. They have a system design problem.

The struggle isn’t finding talent. It’s that your entire stack quietly evolved around one or two people who know how it all fits together. When one of them leaves — and they will leave — you don’t post a job. You start hunting for a unicorn. And that hunt is long, expensive, and almost always disappointing.

This article breaks down how key-person risk actually forms, what the warning signs look like before it blows up, and how to build the kind of Salesforce team structure that doesn’t collapse when someone walks out. I’ve covered related ground on The Hiring Edge podcast and the JoshForce YouTube channel — this is the written version, sharpened for Salesforce leaders who want to get ahead of it.

The Risk Is Already Hiding in Your Org

Every company has that one person.

They’ve been around for years. They grew up inside your Salesforce org. They know every customization, every workaround, every data model quirk that never made it into any documentation. When something breaks at 4 PM on a Friday, you know exactly who to call.

That person is an asset. But they’re also a liability you haven’t fully accounted for.

Here’s how it usually plays out:

• They resign for a better offer.
• They hit a ceiling and quietly disengage.
• The business evolves faster than their skill set does.
• Or they just get sick, burn out, or move away.

Suddenly, you’re exposed. You call a recruiter. You describe the role. You get good candidates — technically solid people with real experience. But none of them feel right.

That’s because you’re not actually describing a role anymore. You’re describing a person. You want someone who already knows your org, your workarounds, your customizations, your history. You’re not hiring. You’re searching for a unicorn. This is also one of key-person dependency is one of the five risks quietly eroding Salesforce teams.

How Does a Unicorn Get Created in the First Place?

Here’s what most leaders miss: unicorns aren’t found. They’re built — unintentionally, slowly, over time.

No one shows up on day one with a magical skill set that makes them impossible to replace. That status gets assembled. The system wraps around them. They become the answer to every urgent question. They take on more and more institutional knowledge because it’s easier to ask them than to document it. And over time, that person becomes structurally embedded in a way no org chart reflects.

It’s not about loyalty or how long someone’s been there. It’s about dependency — and how that dependency was allowed to grow.

The honest truth: your organization created the unicorn. Not the person, not the market, not bad luck. The system design did it.

What Are the Warning Signs?

You don’t need to wait for a resignation letter to know you’re exposed. The warning signs are usually visible long before the crisis.

Documentation that lives in one person’s head. If you asked your Salesforce team to walk a new hire through the system and that “walkthrough” would basically require that one specific person, you’ve got a problem.

Customizations no outsider could decipher. Bespoke code, unexplained flows, workarounds layered on workarounds. If you brought in an outside contractor today and they spent their first two weeks just trying to understand what’s been built — that’s a red flag.

A job description that reads like a personal résumé. When you sit down to write the posting and it keeps describing what your current person does (instead of what the role requires), the role isn’t real. It’s a person. That’s a design failure.

A bus factor of one. This is the operational measure that doesn’t lie: if one person gets hit by the proverbial bus tomorrow, does your Salesforce org keep running? If the honest answer is “no” or “not really” — you’re exposed right now.

The emotional comfort trap. This one is sneaky. It feels good to have that go-to person. You feel covered. You feel like you have a reliable expert on speed dial. That comfort is real. And it is exactly what prevents you from fixing the problem before it becomes a crisis. The relief of having a unicorn is what creates the conditions for a painful future.

Is This a Hiring Problem or a Design Problem?

It’s a design problem. Every time.

When a leader calls me because they can’t fill a critical Salesforce role, I ask them to describe it. Usually within five minutes, the description has drifted from a real job into a laundry list that only makes sense if you already know their system intimately.

That’s not a talent market problem. That’s a role that was never properly defined, structured, or documented in the first place.

The market isn’t short on capable Salesforce admins, developers, and architects. It is short on people willing to inherit an undocumented, dependency-riddled mess and be expected to perform on day one.

You can’t hire your way out of a structural problem. You have to build your way out.

The Unicorn Prevention System: Five Practical Steps

You don’t solve key-person risk by hiring harder. You solve it by building for replaceability — before the crisis forces your hand.

1. Standardize your stack.
Every creative workaround that exists today is a hiring headache tomorrow. This doesn’t mean you need to strip out everything custom. It means that every customization should be documented, justified, and built in a way that someone else can understand and maintain. The test: could a competent outside contractor pick it up without a two-week handoff from your current person?

2. Document everything — now, not later.
If someone had to step in tomorrow, could they? That’s your benchmark. Documentation isn’t a future project. It’s an ongoing operational practice. And it doesn’t have to be a burden on one person — if someone on your team is a natural educator or communicator, let them record walkthroughs, build internal wikis, and share knowledge in the format that comes naturally to them.

3. Share ownership — deliberately.
Cross-train. Rotate responsibilities. Have team members present their areas of ownership to each other in internal demos. No single person should own 100% of anything critical. The goal isn’t to dilute expertise. It’s to ensure that expertise is never locked inside one person’s head.

4. Define roles by outcomes, not by people.
When you build a job description, build it around the outcomes you need — not around the specific skill set of the person currently doing it. Outcome-based roles that scale are transferable and defensible. People-shaped roles are fragile.

5. Get an outside perspective.
An experienced recruiter or advisor can spot key-person risk almost immediately. You’re often too close to the system and too comfortable with the current arrangement to see it clearly. An outside set of eyes — someone who has seen how dozens of other Salesforce orgs are built and staffed — will tell you the truth faster than any internal audit.

What Happens When You Actually Build This?

When you have standardized processes, solid documentation, shared ownership, and outcome-based roles, something shifts.

Hiring gets easier. You’re describing a real job, not a person-shaped hole. Good candidates can actually evaluate whether they’re a fit. Onboarding takes weeks instead of months. And when someone does leave, the institutional knowledge doesn’t leave with them.

More importantly, you stop operating from a place of fear. Right now, many Salesforce leaders know, in the back of their mind, that they are one resignation away from a serious problem. That’s a stressful way to run an org. The prevention system changes that. It also sets you up for hiring for roles that are built to last.

The Hard Truth Most Leaders Don’t Want to Hear

It feels good to have someone who knows everything. That comfort is real. But that comfort is also what creates your future pain.

If you’re constantly trying to hire someone “just like Sarah” — and nothing ever feels quite right — the issue isn’t the talent market. It’s how the role was built in the first place.

The best Salesforce leaders build systems that outlast people. The rest spend a lot of time and money searching for unicorns that don’t exist, or paying a premium for someone willing to absorb the chaos.

Build the system. Document the work. Share the knowledge. You won’t need to search for a unicorn if you never build a role that requires one.

Ready to Audit Your Salesforce Team Structure?

If you’re not sure whether you’ve got a unicorn problem brewing — or if you already know you do — let’s talk. At Salesforce Staffing, LLC, we help Salesforce leaders build teams that are durable, scalable, and not dependent on any one person.

Schedule a conversation about your Salesforce team structure →

Josh Matthews is the founder of Salesforce Staffing, LLC and TheSalesforceRecruiter.com and host of The Hiring Edge podcast. He has been recruiting since 1999, operating Salesforce-only since 2018, and has conducted more than 15,000 interviews.