💃 When One Person Knows Everything 🕺

Good morning, Salesforce Nerds! Every Salesforce team has one …

Maybe they built the org from scratch. 🏗️ 

Maybe they've been there so long they are the org. 😅 

They know which Flow breaks if you touch it, which integration credential lives in a sticky note on their monitor, and why that one Apex class has a comment that just says "don't delete this."

They're brilliant. They're indispensable. And that's exactly the problem.

This is Key Person Risk. 👈️ 

And if you're a technology executive responsible for a Salesforce instance, there's a good chance it's already living inside your platform, quietly compounding interest. 💰️ 

TABLE OF CONTENTS

💃 When One Person Knows Everything 🕺

• It's Not About The Person

• How It Sneaks In

• What It Looks Like In Your Org

• The Real Cost Is Hidden

• Resilience, Not Redundancy

THE SYSTEM FAILED FIRST

IT’S NOT ABOUT THE PERSON

Key Person Risk has nothing to do with loyalty, talent, or intent. ❌ 

It's what happens when institutional knowledge accumulates in one place.

One brain, one inbox, one set of credentials. 🫠 

Because the systems around that person never kept pace.

A single individual holds disproportionate knowledge, access, or decision-making authority over the org.

When they depart, go on leave, or simply take a two-week vacation, things slow down or stop. 🛑 

Deployments stall. Incidents drag.

New team members can't get answers because the answers aren't written anywhere. They're in someone's head.

It's not a people problem. 🙅

It's a documentation and systems problem wearing a people costume.

FAST ORGS GROW BRITTLE QUIETLY

HOW IT SNEAKS IN

Key Person Risk doesn't arrive with a calendar invite.

It compounds. Someone builds a critical integration over a weekend and documents nothing because the deadline was yesterday. 😧 

Someone else takes ownership of the deployment pipeline because they were the only one who knew Gearset.

A third person becomes the de facto authority on data architecture because they were there when the decisions were made. 🤷 

And no one wrote down why.

Orgs that scaled fast are especially exposed. Speed is the enemy of knowledge transfer. ⏩️ 

When teams are sprinting, documentation feels like overhead. Tribal knowledge fills the gap.

Before long, the answer to most architecture questions is "ask Alex" … and when Alex is unreachable, the whole operation waits. 😭 

The accumulation is invisible until it isn't.

SPOT IT BEFORE IT BITES

WHAT IT LOOKS LIKE IN YOUR ORG

Key Person Risk leaves fingerprints. Here's what to look for: 👇️ 

🔓️ Access and credentials: One person owns all named integration credentials. No one else has the login. The connected app OAuth token lives in their personal developer account.

⚙️ Automation opacity: A business-critical Flow has been running for two years. No one on the current team can explain what it does or why it was built the way it was. Plus there's no documentation to find.

💔 Deployment single points: The CI/CD pipeline runs through one person's Gearset account. If they're out, releases pause.

⛔️ Architectural tribal knowledge: Design decisions were made three years ago by someone who left eighteen months ago. The rationale was never recorded. The team inherits the output with no context.

🧑‍🦰 Informal routing: "Just ask Morgan" becomes the unofficial answer to every technical question. Not because Morgan is on call, but because Morgan is the only one who knows.

These are detectable, fixable symptoms. But you have to look for them.

HR PROBLEM? THINK AGAIN.

THE REAL COST IS HIDDEN

When a key person leaves, the obvious cost is the disruption. 💥 

The scramble, the frantic knowledge-dump, the three-month ramp for the replacement.

Executives see that. What they often miss is the cost that was already there. 💸 

Key Person Risk quietly inflates incident resolution time. When something breaks and only one person knows the system, every outage is a hostage situation.

It slows onboarding. New team members can't be productive if the knowledge they need lives in someone else's memory. 🧠 

It creates leverage imbalances, where a single employee wields disproportionate influence simply because they can't easily be replaced.

And it raises delivery risk on every project, because critical paths run through one person's availability.

This is a balance sheet risk, not an HR annoyance. 💯 

The cost of mitigation is a fraction of the cost of a bad offboarding.

FIX THE SYSTEM, NOT THE ORG CHART

RESILIENCE, NOT REDUNDANCY

The goal isn't to clone your key person. It's to make the knowledge portable. 📦️ 

Here's how to start without a reorg:

🧑‍🤝‍🧑 Architecture Decision Records (ADRs): Every significant design decision gets a short written record. What was decided, why, and what was rejected. Future teams inherit context, not just code.

📖 Runbooks: Document the processes only one person currently knows. Deployment steps, integration setup, emergency procedures. If it lives only in someone's head, it's a liability.

🔐 Shared credential management: Named credentials, connected apps, and API keys should live in a shared, governed location. Not a personal account or a sticky note.

🤝 Paired delivery: Never build critical components solo. Two people on every significant build means two people who understand it when it ships.

🔄 Knowledge transfer as a Definition of Done: Before a story closes, document what was built and why. Not a novel … just a paragraph. Make it non-negotiable.

Start with an audit.

Map where single-person dependencies exist today. Access, automation, architecture, and deployment.

Prioritize the highest-risk nodes. Build a remediation plan with owners and timelines.

The platform won't protect itself. 👈️ 

But a well-documented, well-governed org is one where a two-week vacation is just a vacation. Not a risk event.

SOUL FOOD

Today’s Principle

and now....Salesforce Memes