What Happens If One Person Knows Everything?
It often happens gradually.
A developer joins the business, solves difficult problems and becomes the person everyone turns to when something goes wrong. Over time, they understand more of the software, infrastructure and technical decisions than anyone else.
Eventually, you realise there are things the business cannot easily do without them.
Perhaps only they can deploy the software. Maybe they are the only person who understands a critical integration, knows why the system was designed a particular way, or has access to important accounts.
The question for leadership is not whether that developer is doing a good job.
It is:
What happens to the business if this person becomes unavailable?
This is commonly called key-person risk or key-person dependency.
Some dependency on specialist knowledge is normal. The problem is when one person’s absence could materially affect the organisation’s ability to operate, maintain its software or make important technology decisions.
Signs Your Business May Be Too Dependent on One Developer
Key-person dependency is not always obvious.
The business may be operating perfectly well today. The risk becomes visible when someone takes leave, becomes ill, resigns or simply isn’t available when something important happens.
Common warning signs include:
- Only one person fully understands a critical system.
- Only one developer can safely make certain changes.
- Software releases or deployments depend on one person.
- Important technical decisions exist mainly in someone’s memory.
- Documentation is missing, outdated or difficult to use.
- Other developers avoid particular parts of the system.
- One person controls important passwords, infrastructure or supplier accounts.
- Nobody else fully understands important integrations.
- Holidays or illness regularly delay technical work.
- Management is reluctant to challenge decisions because the developer is considered indispensable.
- Leadership does not know where source code, credentials or important documentation are stored.
- The developer is the only relationship with important technology suppliers.
- Replacing the developer would probably take months.
- You do not know whether another developer could realistically maintain the software.
One or two of these does not necessarily mean you have a serious problem.
Several together deserve closer attention.
The Developer May Not Be the Problem
Becoming dependent on one developer does not mean that person has done anything wrong.
Quite often, the opposite is true.
Key-person dependency frequently develops because someone is capable, reliable and good at solving difficult problems. When something breaks, everyone asks them. When a difficult decision needs to be made, they make it. When deadlines are tight, documenting what they did gets pushed aside.
The organisation gradually builds itself around that person’s knowledge.
That can create risk for the business, but it can also put considerable pressure on the developer. They become the person who cannot really switch off because they might be needed.
The aim should not be to distrust or replace them.
It should be to protect both the organisation and the individual by sharing knowledge, improving access arrangements, documenting what matters and making sure critical responsibilities do not sit with one person.
Why Does Key-Person Dependency Develop?
It is particularly common in growing businesses.
Early software development often prioritises getting something working. A founder may rely heavily on the first technical employee, a trusted contractor or the developer who originally built the system.
That arrangement can work well for years.
But the business grows while its technology arrangements remain largely unchanged.
Other causes can include small development teams, poor documentation, limited knowledge sharing, legacy software, specialist technologies, outsourced development and informal management of passwords and accounts.
Sometimes nobody has been given responsibility for reducing the dependency.
The result is not necessarily bad software or poor development. It is a business that has outgrown the way its technology knowledge and responsibilities are managed.
What Happens If Your Developer Leaves?
The consequences depend on what the developer controls and how well their knowledge has been shared.
If they resign, become ill or take extended leave, you might discover that:
- Development slows or stops.
- Important bugs take much longer to resolve.
- Nobody else can confidently deploy the software.
- Access to systems or accounts becomes difficult.
- Existing code is difficult for another developer to understand.
- Projects are delayed.
- Expensive specialist help is needed at short notice.
- Security and administrative access becomes uncertain.
- Replacement developers take much longer to become productive.
- Supplier relationships are disrupted.
- Important technical knowledge has to be reconstructed.
This does not mean every business with a key developer is facing a crisis.
The important question is whether the level of dependency is acceptable to the business.
How to Tell How Dependent You Really Are
You do not need a lengthy technical audit to start understanding the problem.
Leadership can begin with some straightforward questions.
Source code and ownership
Who can access your source code?
Where is it stored?
Does the business clearly own the software and associated intellectual property?
Could another developer access the repository and understand how the software is organised?
Systems and access
Who controls your cloud platforms, hosting, domains, databases and third-party services?
Are important accounts registered to the business or to individuals?
Are credentials stored securely somewhere the business can access?
Development and deployment
Could another developer set up the software on their computer?
Could they make a change and safely release it?
Could someone else diagnose a production problem?
Are build, deployment and recovery processes understood by more than one person?
Technical knowledge
Is the architecture documented well enough for another experienced developer to understand it?
Are important integrations documented?
Does anyone else understand the database and data model?
Can someone explain why important technical decisions were made?
Business continuity
How long would it realistically take another developer to become productive?
Most importantly:
What would happen if your key developer were unavailable tomorrow?
These questions should not be treated as an audit of the developer.
They are a way of understanding the organisation’s exposure.
What to Do If You’re Too Dependent on One Developer
Once you understand where the dependency exists, you can start reducing it.
You do not need to document every line of code or duplicate every technical role.
Start with what matters most to the business.
1. Identify your critical dependencies
Document which systems, processes, responsibilities and decisions currently depend on the individual.
Prioritise those that could interrupt business operations, customer service, software delivery or security.
2. Confirm ownership and access
Make sure the business has appropriate access to source code, cloud infrastructure, domains, databases and critical third-party accounts.
Confirm intellectual property ownership where relevant.
3. Document what matters
Prioritise architecture, important integrations, deployment processes, recovery procedures and operational knowledge.
Documentation should help another capable person understand and operate the system. It does not need to describe every technical detail.
4. Spread knowledge
Introduce knowledge sharing, code reviews and cross-training where practical.
Another developer should gradually become capable of working with important parts of the system rather than simply knowing where the documentation lives.
5. Test the arrangements
Documentation alone does not remove key-person risk.
Where practical, have another developer perform important activities such as setting up the software, making a change, deploying a release or investigating an issue.
That quickly reveals whether knowledge has genuinely been transferred.
6. Create a realistic contingency plan
Decide what would happen if the key person became unavailable.
Who would take responsibility?
Who could provide technical support?
Which systems would need immediate attention?
A simple, workable plan is far more useful than a large document nobody uses.
Don’t Wait Until the Developer Resigns
The worst time to discover key-person dependency is after receiving a resignation.
At that point, knowledge transfer has a deadline.
Reducing dependency while the developer is still actively involved gives everyone more time. Documentation can be created properly, knowledge can be transferred gradually and another developer can learn the system while the person who understands it is still available to answer questions.
It also makes the process far less confrontational.
This is sensible business continuity and succession planning, not preparation for getting rid of someone.
Should You Hire Another Developer?
Possibly, but simply adding another developer does not automatically solve the problem.
Imagine hiring a second developer while the original developer still:
- Makes all the important technical decisions
- Controls deployments
- Holds most of the system knowledge
- Manages critical accounts
- Handles the most complicated parts of the software
You now have two developers, but you may still be dependent on one.
A second person becomes valuable when there is deliberate knowledge transfer, shared access and genuine responsibility.
The goal is not just increasing headcount.
It is reducing single points of failure.
How Much Dependency Is Acceptable?
You do not necessarily need to eliminate every dependency.
Specialist knowledge will always exist.
A senior developer may naturally understand some areas better than other people. A particular specialist may remain the best person to solve certain problems.
The question is whether their absence would create an unacceptable business risk.
Leadership should understand where those dependencies exist, what would happen if the person became unavailable and whether the organisation has reasonable alternatives.
That allows you to make a conscious business decision rather than discovering the dependency during an emergency.
How I Help Reduce Key-Person Technology Risk
An independent assessment can help you understand where your business is exposed without turning the exercise into an investigation of the developer.
I can review areas such as:
- Source code ownership and access
- Development repositories
- Cloud and infrastructure access
- Domains and third-party accounts
- Software architecture
- Technical documentation
- Build and deployment processes
- Backups and recovery
- Development practices
- Knowledge distribution
- Critical integrations
- Technology suppliers
- Intellectual property ownership
- Security and administrative access
- Succession and contingency arrangements
The objective is not to replace your developer or disrupt a development team that is working well.
It is to understand where the organisation relies too heavily on individuals and decide what should be addressed first.
What You Should Know After a Review
A useful assessment should give leadership a much clearer picture of:
- Where key-person dependencies exist
- Which dependencies create meaningful business risk
- What knowledge needs to be transferred
- What documentation is missing
- Whether critical systems and accounts are appropriately controlled
- Whether another developer could realistically maintain the software
- What needs attention now
- What can be improved gradually over time
For businesses that want a structured assessment, my Key Person Technology Risk Review examines these areas specifically.
If the concerns extend beyond one person and include the wider development process, codebase or delivery capability, a Software Development Review may be more appropriate.
Reduce the Dependency Without Disrupting the Team
Being dependent on one developer does not necessarily mean something is wrong today.
It means the business should understand what would happen if circumstances changed tomorrow.
The aim is not to remove a valuable developer’s importance. It is to make sure critical knowledge, access and responsibility are shared appropriately so the organisation can continue operating when people take holidays, change roles or eventually move on.
A calm, planned approach is usually much easier and less expensive than trying to reconstruct critical knowledge after it has disappeared.
Concerned Your Business Relies Too Heavily on One Person?
If you’re unsure how exposed the business really is, an independent review can help identify the important dependencies and separate genuine business risks from things that are simply normal specialist knowledge.
You can then decide what needs attention now, what can wait and what level of dependency is reasonable for your organisation.