Think about the technology your school relies on every day. Microsoft 365. Networks and Wi-Fi. Student information systems. Cybersecurity. Backups. Devices. Cloud applications. User accounts. Vendors. Infrastructure.
Now ask a slightly different question: How many people really understand how all of it works?
For many schools, the answer may be a surprisingly small number. Sometimes, it's one person.
That person may know how systems are configured, which vendors to contact, where documentation is stored, how backups work, which applications have unusual dependencies and what to do when something goes wrong.
That knowledge can make an experienced IT Manager one of the school's most valuable resources. It can also create a risk that is easy to overlook.
Organisations often talk about key-person dependency in senior leadership roles. What happens if a CEO leaves unexpectedly? Who holds important client relationships? Which responsibilities need succession planning?
The same thinking isn't always applied to IT. Yet technology environments accumulate enormous amounts of institutional knowledge over time.
An IT Manager may know why a particular network is configured the way it is. They may remember which systems don't play nicely together, which devices need replacing next year, which vendor can solve a particular problem and which workaround was implemented three years ago to keep a critical application running.
Some of that information may be documented. Some of it may simply live in someone's head. That's where key-person dependency begins.
When we talk about relying too heavily on one person, it's easy to assume we're talking about staff turnover.
That's certainly one possibility, but it's far from the only one. What happens when your IT Manager:
A school doesn't need to lose a valuable IT employee for key-person dependency to become a problem. Sometimes all it takes is two important things going wrong at the same time.
One practical way to identify dependency is to look at administrative access. Who can access your school's critical technology environment? That might include:
Ideally, critical systems shouldn't depend on a single person's account, credentials or knowledge.
That doesn't mean giving administrative access to everyone. It means ensuring there is an appropriate, secure fallback if the primary administrator isn't available.
Privileged access should also be protected carefully. Strong authentication, appropriate permissions and secure credential management all matter when dealing with accounts capable of making significant changes to the environment.
The objective is straightforward: No critical system should become inaccessible simply because one person isn't available.
Good documentation isn't particularly glamorous. Until you need it.
A well-documented IT environment makes it easier for another qualified person to understand what exists, how systems connect and what needs to happen during an incident. Useful documentation might include:
Documentation also needs to remain current. A network diagram created four years ago but never updated may provide considerably less reassurance than everyone assumes.
The test isn't whether documentation exists. It's whether someone other than its author could use it when they actually needed to.
Even highly capable IT professionals can't specialise in everything.
Modern school environments can span networking, Microsoft 365, cloud infrastructure, cybersecurity, identity, backup and recovery, endpoint management, hardware, applications and increasingly AI.
Expecting one person — or even a small team — to maintain deep specialist expertise across every one of those areas isn't particularly realistic. This becomes especially important during unusual or high-impact incidents.
A cybersecurity event may require expertise the internal team rarely needs during normal operations. A complex infrastructure failure may need vendor-specific knowledge. A recovery problem may require additional resources quickly.
The question therefore isn't: “Is our IT person capable?” A much better question is: “When they encounter something outside their expertise or capacity, who can they call?”
Having an escalation path before it's needed can make an enormous difference.
Imagine a significant technology incident occurs tomorrow morning. Several systems are unavailable and staff are unable to work normally.
Who determines what's happened? Who contacts technology vendors? Who understands the backup environment? Who coordinates recovery? Who keeps school leadership informed? If the answer to every question is the same person's name, the school may have identified an important resilience gap.
This is particularly relevant during a cyber incident, where the internal IT person may simultaneously be expected to investigate the problem, contain it, coordinate external specialists, restore systems and brief leadership.
That's a lot to ask of anyone. Incident response works better when roles, responsibilities and escalation paths have already been established.
Your IT Manager should play an important role in that plan. They shouldn't have to be the entire plan.
This distinction matters. Identifying key-person dependency isn't a criticism of an internal IT team. Often, the opposite is true.
If one person has become indispensable to the technology environment, that's usually evidence of how much knowledge, responsibility and trust the organisation has placed in them.
The goal should be to protect that capability rather than replace it. That might involve:
For some schools, external IT support can provide an additional layer of capability around the internal team. This is sometimes described as co-managed IT: the school retains its internal IT people and institutional knowledge while gaining access to additional specialists, resources and escalation support when required.
It's less about outsourcing IT and more about giving the people already responsible for it a bigger bench.
Key-person dependency can be difficult to see because, when everything is running normally, the model may work extremely well. A few simple questions can help reveal where dependencies exist:
1. If our primary IT person was unavailable tomorrow, who could manage our critical systems?
2. Could another qualified person understand our environment from the documentation we have today?
3. Do we have secure backup access to every critical technology platform?
4. If our IT team encountered a problem outside its expertise, do we already know who we would call?
5. During a major incident, would one person be expected to diagnose the problem, coordinate recovery and brief leadership at the same time?
If some of those questions are difficult to answer, it doesn't mean the school needs a larger internal IT department. It may simply mean the people you already rely on need more capability around them.
A knowledgeable internal IT person can be an enormous asset to a school. They understand the environment, the staff, the technology and often years of decisions that have shaped how everything works today.
The goal shouldn't be to make that knowledge less valuable. It should be to make sure the school — and the IT person themselves — aren't exposed because too much depends on it.
Subnet works alongside internal IT teams across South Australia, providing additional technical capability, specialist expertise and escalation support when it's needed.
Because the best way to reduce dependency on a great IT person isn't necessarily to replace them. It's to make sure they don't have to carry everything alone.