What Happens If Your Lead Developer Resigns Tomorrow?

Your lead developer is unavailable tomorrow.

Can someone else deploy production?

Can they restore a backup?

Can they access the cloud account?

Can they explain why that strange service nobody wants to touch still exists?

If several answers are "no," you do not only have a valuable developer.

You have key-person dependency.

And that can become a technical and business continuity problem very quickly.

The Lead Developer Is Not the Problem

Key-person dependency usually develops for a good reason.

One engineer becomes the person who understands the system best.

A difficult deployment comes up.

They handle it.

Infrastructure needs changing.

They do it.

A production incident happens.

Everyone calls them.

A new vendor account is needed.

They create it.

Eventually the team develops an undocumented API:

Problem
↓
Ask Lead Developer
↓
Problem Solved

That works surprisingly well.

Until the lead developer is unavailable.

The goal is not to make senior developers less important.

It is to prevent routine business-critical operations from depending entirely on one person's availability.

Run the "Tomorrow Test"

I like a simple exercise.

Assume your lead developer cannot answer messages tomorrow.

Now check whether the team can still perform these operations:

[ ] Deploy production
[ ] Roll back a failed release
[ ] Access cloud infrastructure
[ ] Restore a backup
[ ] Access production databases
[ ] Rotate credentials or secrets
[ ] Manage DNS and domains
[ ] Administer source control
[ ] Access monitoring systems
[ ] Manage critical vendor accounts
[ ] Explain major architecture dependencies
[ ] Respond to a production incident

Every unchecked item represents a dependency worth investigating.

Not every item needs five owners.

But important operations should have a realistic backup path.

Deployment Is a Good First Test

A lot of teams technically have a deployment process.

In practice, the process is:

"Ask the person who normally deploys."

Try having another qualified developer perform a normal release.

Can they determine:

which branch or tag goes to production,

how environment configuration works,

whether database migrations need to run,

where CI/CD failures appear,

how to verify the deployment,

how to roll back?

If they cannot, document the process.

Then test it again.

A basic runbook could look like this:

Production Deployment

1. Confirm approved release branch/tag.
2. Verify CI checks have passed.
3. Review pending database migrations.
4. Trigger deployment.
5. Monitor deployment logs.
6. Run production smoke tests.
7. Verify monitoring/health checks.
8. If validation fails, execute rollback procedure.

The important part is not having the document.

The important part is that someone other than its author can successfully use it.

Infrastructure Knowledge Should Not Live in One Head

Infrastructure becomes another common dependency.

One engineer may know:

which cloud resources are still active,

how networking is configured,

where production databases live,

which storage buckets are important,

how backups work,

what monitoring alerts actually matter,

which resources exist only for legacy reasons.

When this information exists only as memory, another engineer has to reverse-engineer the environment during the worst possible moment.

You do not need perfect infrastructure documentation.

Start with a simple map:

Production
├── Application
│ ├── Web/API
│ └── Background workers
├── Database
├── Storage
├── Cache
├── Monitoring
├── Backups
└── External integrations

Then document ownership and the important relationships between them.

If you use infrastructure as code, even better—but IaC does not explain every operational decision.

The code may show that a resource exists.

It may not explain why removing it would break something important.

Credentials Can Turn Dependency Into Lockout

Knowledge transfer is inconvenient.

Account lockout can completely block the company.

Review important technical services:

Cloud provider
Source control
Domain registrar
DNS
CI/CD
Monitoring
Password manager
Email delivery
Payment provider
App stores
External APIs

Then ask:

Is this account company-owned?

Are there multiple authorized administrators?

Does MFA depend on one person's phone?

Is recovery information controlled by the company?

Where are credentials stored?

Who receives renewal and billing notices?

A critical cloud, domain, or vendor account should not effectively belong to an employee because it was originally created using their personal email address.

The business should control business-critical access.

Architecture Context Is Harder to Transfer

Passwords can be reset.

Historical context cannot.

Your lead developer may know why:

a legacy service still exists,

a table cannot easily be changed,

an integration must run in a particular order,

a background worker behaves strangely,

a seemingly redundant API endpoint is still important.

The repository usually does not explain all of that.

Good architecture documentation should capture both:

WHAT exists
+
WHY it exists

For important decisions, lightweight architecture decision records can help:

Decision:
Keep billing processing separate from the primary application.

Reason:
Billing retries and external provider delays should not block
normal application requests.

Trade-off:
Additional service and operational complexity.

Review when:
Billing architecture is redesigned.

You do not need an ADR for every commit.

Capture the decisions another developer would otherwise have to rediscover.

Vendor Accounts Are Part of Your Architecture

Technical dependency extends beyond your repository.

Your system may depend on:

payment gateways,

transactional email,

SMS,

maps,

authentication providers,

analytics,

monitoring,

object storage,

app-store accounts,

AI APIs.

Someone should know:

Vendor
Purpose
Primary Owner
Backup Owner
Admin Access
Billing Owner
Recovery Method

This is especially important for older integrations.

It is easy to discover during an incident that the only person who knows how to access a service is unavailable.

Documentation Does Not Equal Redundancy

This distinction matters.

Suppose you have:

deployment-runbook.md
backup-recovery.md
infrastructure.md
architecture.md
vendor-accounts.md

Great.

Now ask another engineer to use them.

Can they deploy?

Can they restore data?

Can they find the correct cloud resource?

Can they explain a critical dependency?

Can they access the vendor account?

If not, you still have key-person dependency.

The document exists.

The capability does not.

Use the Two-Person Test

For genuinely critical technical functions, I prefer a simple rule:

At least two qualified people should be able to keep the operation running.

That does not mean both need identical expertise.

You can still have a clear primary owner.

For example:

Production Deployment
Primary: Lead Developer
Backup: Senior Developer

Infrastructure
Primary: Platform Engineer
Backup: Lead Developer

Database Recovery
Primary: DBA / Backend Lead
Backup: Senior Backend Developer

The backup person should have:

access,

documentation,

enough context,

practical experience performing the task.

Writing a person's name into a spreadsheet does not make them a backup.

Cross-Train Before Someone Gives Notice

The worst knowledge-transfer plan is:

Developer resigns
↓
Two-week documentation marathon
↓
Hope nothing was forgotten

A healthier pattern is continuous.

Person A performs task
↓
Person B shadows
↓
Person B performs task
↓
Person A observes
↓
Runbook gets updated

Use normal work as the training environment.

Let another engineer perform a release.

Rotate ownership of routine infrastructure changes.

Run backup restoration exercises.

Review architecture together.

That creates real operational redundancy instead of a folder full of handover documents.

Watch for "Only X Knows That"

There is one sentence I treat as a warning:

"Only Sam knows how that works."

Occasionally, that is unavoidable.

Repeatedly, it is a signal.

Ask:

Why does only one person know it?

Is the knowledge documented?

Can another person be trained?

Can the process be automated?

Can the underlying system be simplified?

The goal is not to remove specialization.

It is to stop specialized knowledge from becoming an unnecessary operational bottleneck.

A Practical Key-Person Dependency Audit

Take your critical technical systems and build a small matrix:

System/Task:
Primary Owner:
Backup Owner:
Documentation:
Backup Access Confirmed:
Backup Has Performed Task:

Review at least:

[ ] Production deployment
[ ] Rollback
[ ] Cloud infrastructure
[ ] Database administration
[ ] Backup restoration
[ ] Source control
[ ] CI/CD
[ ] Domains and DNS
[ ] Secrets/credentials
[ ] Monitoring
[ ] Critical vendor accounts
[ ] Architecture knowledge
[ ] Incident response

Pay particular attention to anything where:

Primary Owner = 1 person
Backup Owner = nobody
Documentation = missing
Access = untested

That is your priority list.

The Goal Is Resilience, Not Replaceability

A great lead developer may be extremely difficult to replace.

That is normal.

Their experience, technical judgment, system context, and problem-solving ability are valuable precisely because they are not interchangeable.

But the company should still be able to deploy software, access infrastructure, recover data, maintain critical vendors, and respond to incidents without them.

Those are two different things.

Senior engineers should be valuable because of the new problems they can solve.

They should not be valuable because they are the only human being who knows the production password.

So run the test before you need it:

If our lead developer became unavailable tomorrow, what is the first technical operation that would stop?

Find that dependency.

Fix it.

Then ask the question again.