The childcare centre shouldn’t stop because one key person is away

Every early learning service has people who know how things really work.

They know which computer controls the sign-in system, who to call when the internet drops out, how to reset the printer, where the passwords are kept, which supplier manages the security cameras, and what to do when a software update breaks something important.

The problem starts when all of that knowledge lives with one person.

That person may be the centre director, an administrator, an educator who happens to be good with technology, or a trusted external provider who has been involved for years.

While they are available, everything appears to work.

When they are away, the service can suddenly discover that essential operational knowledge was never actually documented.

Key-person dependency is an operational risk

Technology in early learning services is no longer limited to a few office computers.

Centres may rely on digital systems for attendance, parent communication, enrolments, billing, payroll, rostering, compliance records, security, cameras, printing, internet access, cloud storage and communication with external services.

If one person is the only one who knows how those systems fit together, the risk is not simply an IT issue.

It becomes an operational issue.

A password cannot be found.

Nobody knows who owns an online account.

The person who normally deals with the software provider is on leave.

A new computer is installed, but nobody knows how to reconnect the application used every day.

The internet fails and staff do not know whether the problem belongs to the carrier, router, internal network or a cloud service.

Individually, these may sound like small problems. During a busy childcare day, they can quickly become disruptive.

Document what people currently carry in their heads

The goal is not to turn every educator into an IT specialist.

It is to make sure critical knowledge exists somewhere other than one person’s memory.

Start by identifying the systems the service cannot comfortably operate without.

For each one, record basic information such as:

• what the system is used for;
• who owns the account;
• who the authorised contacts are;
• which provider supports it;
• where support details are kept;
• when licences or subscriptions renew;
• what equipment it depends on;
• where recovery information is stored; and
• what staff should do first if it becomes unavailable.

Passwords should not be placed in ordinary documents or spreadsheets. They belong in an appropriate password-management system with controlled access.

The documentation only needs to explain where authorised staff can obtain the credentials when required.

Avoid accounts tied to one person

A common source of dependency is the use of individual accounts for business-critical services.

A system may have been created years ago using a director’s personal email address or an employee’s individual login.

That may work until the person leaves, changes roles or becomes unavailable.

Where possible, important business systems should be owned through organisation-controlled accounts with clear recovery arrangements.

The same principle applies to multi-factor authentication.

If a critical account can only be accessed because verification codes go to one person’s phone, the organisation has created another form of key-person dependency.

There should be an appropriate way for authorised personnel to recover access without weakening security.

Make the first response simple

Technology failures become harder when nobody knows where to begin.

A simple first-response guide can remove much of that uncertainty.

If internet access stops, for example, staff should know who the service provider is, where the network equipment is located, what basic checks are authorised, and who to contact if those checks do not resolve the problem.

The same approach can be used for printers, sign-in systems, shared computers, cloud platforms and other important services.

This does not replace professional technical support.

It simply prevents staff from losing valuable time trying to work out who is responsible for what.

Test the documentation before you need it

A useful question for any service is:

Could another authorised person keep things running if the person who normally handles the technology was unavailable tomorrow?

One of the easiest ways to test this is during normal leave.

Have another staff member use the documentation to carry out a simple task such as locating support information, identifying the correct account owner or following the first-response process for a known system.

Any gaps quickly become obvious.

That is far better than discovering them during an outage.

Build continuity into normal handover

Key-person dependency rarely appears deliberately.

It builds slowly as someone becomes the person who “just knows” how everything works.

The solution is not more technology. It is better ownership, documentation and handover.

Whenever a new system is installed or an important service changes, record who owns it, how it is supported, where the relevant information is stored and what someone else would need to know to manage it.

Then review that information periodically.

Early learning services already put considerable effort into ensuring children, families and staff are not dependent on one fragile operational process.

Technology should be treated the same way.

The real test of a well-managed system is not whether it works while the usual person is there.

It is whether the service can still operate when they are not.

Author: Mervyn Jackson is Founder and Principal Consultant at IT-ICU, an Australian technology consultancy established in 1997. He has more than 20 years of hands-on experience across business systems, infrastructure, networking and complex technical troubleshooting.