Business / The TecBase journal

What Breaks If Your Best Employee Takes Two Weeks Off?

If one person’s holiday turns into everyone else’s emergency, you may have built a business around memory instead of a shared way of working.

An empty blue office chair beside a suitcase, with a phone and notebooks left on the desk
Editorial illustration

The holiday test

Imagine that the most dependable person in your business is away for two weeks. They have done a careful handover. Their out-of-office reply is on. By Tuesday, someone is asking which customer was promised a special price. By Wednesday, an order is waiting because nobody knows who usually approves it. By Thursday, the team is considering sending a ‘quick question’ to their personal phone.

This is not a failure of commitment. It may be evidence of how much invisible work that person has been doing. They remember the exceptions, connect the departments and know which answer is current. Over time, a capable employee can become the place where the business stores its operating knowledge.

Now change the scenario. The customer record shows the agreed price and who approved it. The order shows what is waiting, and the approval rule names a deputy. The employee is still missed: their judgement and relationships matter. But their absence no longer makes basic facts inaccessible. That difference is what a useful handover process should achieve.

Being indispensable has a hidden cost

There is a flattering version of this story: nobody can do it quite like them. There is also a tiring version. They cannot finish focused work without interruption, colleagues cannot move ahead without asking, and a routine absence creates a queue of unresolved decisions.

The aim is not to replace someone’s experience. Experience is what helps people handle a genuinely unusual situation. The opportunity is to stop requiring that experience for every ordinary step. A colleague should not need a personal introduction to find the latest order status or learn whether a document has been approved.

Separate information, authority and judgement

When work stops in someone’s absence, ask exactly what is missing. Information is a fact someone cannot find: a deadline, specification or customer promise. Authority is permission to proceed: who can approve a change or release a payment. Judgement is the experience needed to weigh an unfamiliar situation. These are different dependencies, even when the same person currently supplies all three.

A shared record can solve an information gap. It cannot grant authority unless the business has agreed who may decide. An approval rule can clarify authority, but it cannot make a novice experienced in a complicated negotiation. For that, a named backup, shadowing and a sensible escalation path may be more appropriate.

Write down the last ten questions directed to your most frequently interrupted colleague. Label each one information, authority or judgement. The pattern will help you avoid building a knowledge base for a permission problem, or adding approval software when people simply need access to an existing answer.

Document decisions, not just instructions

A guide that says ‘send this to the manager’ is incomplete if three different managers might be responsible. A folder full of templates helps little if nobody knows which template applies. Useful shared knowledge includes the decision rule, the owner and the place where the outcome is recorded.

Try capturing one recurring exception. What triggered it? What information was needed? Who had authority to decide? Where could the next person see the result? This gives you more than a long procedure document. It reveals which parts belong in guidance and which should become visible steps in the everyday workflow.

Consider a hypothetical event business deciding whether it can accept a late booking. A weak instruction says to ask the operations lead. A useful record shows the venue capacity, staffing requirements, supplier deadline and who may approve an exception. It also records what was promised to the customer. The next person can understand the decision instead of trying to reconstruct it from a chat history.

Keep this record close to the work. A beautifully written procedure that lives in an unfamiliar folder may be less useful than a short explanation beside the booking. Give the rule an owner and a review date. When the team discovers an exception, update the shared guidance instead of allowing another private version of the process to form.

Make the next action visible

A shared system can help when it shows enough context to act: the current record, its owner, what is waiting and why. It does not need to show everything to everyone. It needs to make ordinary handovers dependable, with appropriate access to the underlying information.

An additional app is not automatically the answer. Sometimes a clearer shared list and an agreed rule solve the problem. Sometimes the team is already maintaining several lists that disagree, and connecting the work becomes worthwhile. Start with the repeated question rather than a shopping list of features.

Do not turn knowledge sharing into extra unpaid work

The person holding the knowledge may already be the busiest person in the room. Asking them to document everything in their spare time adds another responsibility to the dependency you are trying to reduce. Set aside time and have a colleague capture the steps while the expert demonstrates real work.

Give the expert credit for improving how the team operates. Explain that the exercise is intended to reduce interruptions and make leave possible, not to erase the value of their role. Ask which repeated questions they would most like to stop answering. Their frustration is often a practical guide to where the first improvement should go.

Avoid publishing sensitive information simply because it would be convenient. Share what a role needs to act, give access through the proper accounts and arrange backup access before it is urgent. A common password sent around a chat group is a fragile substitute for an intentional handover.

What belongs in a useful handover?

For one recurring task, aim for a compact record that answers six questions: what triggers the work, where the current information lives, what the next action is, who may decide, what could go wrong and where the result should be recorded. Include one completed example and one exception with its reasoning. These examples give a colleague something concrete to compare with the job in front of them.

Then test whether someone can find the record without being told its exact filename. Searchability and clear names are part of the process. If the team still asks the expert for the link every time, the answer has moved out of their head, but access to it has not.

Keep the handover small enough to maintain. A living page for an important workflow is more useful than a complete manual that becomes out of date after the next change.

Try a small absence before a real one

With the person’s agreement, choose a routine task and have a colleague complete it without live coaching. Keep a route for urgent issues, but write down every point where the colleague needs extra context. Treat those moments as gaps in the process, not a test of either person’s ability.

The useful measure is not how many pages you document. It is how much ordinary work can continue without interrupting the same person. A business that makes room for someone to be away also gives that person room to think, improve things and return to a manageable inbox.

After the exercise, agree on the three gaps most worth fixing and repeat the task later with a different colleague. Look for fewer interruptions, fewer avoidable corrections and a clearer path for unusual cases. The point is to build continuity into normal work, so holidays do not require a separate operating system.

BusinessTechnology