Can Your Team Release Without Calling the Same Person?

Can the team go ahead, or does someone need to call them?

For a founder, that is a useful question. You do not need to know every deployment command. You do need to know whether ordinary work can continue when one person is unavailable.

I would start by looking at what the next person needs. Perhaps they cannot get into the right account. Perhaps a step is missing from the instructions. Perhaps they can run the release but cannot tell whether it worked.

The engineer who knows all this may have kept the product running for years. The job is to help the rest of the team share that responsibility, without making that person stay on call for every change.

Walk through a recent release. Find the point where someone had to ask the usual engineer to step in.

Imagine the deployment account still belongs to an old contractor. The team needs company access. Now imagine everyone has an account, but only one person knows what a particular warning means. Another login will not solve that.

Find the missing piece before deciding the answer is more documentation or another hire. You may need either. You may need someone to explain a decision they have been making from memory.

Watching an expert do a job can make it look easy. They already know which screen to open, which warning to check and what to do next. They may not realise how many steps they are filling in.

Ask another authorised person to use the instructions while the expert watches. Let them explain what they think each step means. When they stop, write down what they needed.

That is how you find the command that only works on one laptop, the missing permission or the check everyone assumed was obvious.

A useful result is simple: another person completed a normal release, checked the product and knew when to ask for help.

Keep a note of the help they needed. If the expert had to take over, the exercise still found a gap worth fixing. Try that part again after the process has changed.

Check recovery separately. A person who can ship a successful change may still need help when it fails. And putting the old code back may not undo changes to data or an outside service.

One successful attempt shows what worked that day. Repeat the important checks when the process changes.

When a deadline is close, calling the expert is often the quickest way through. It is easy to see why the team does it.

But each time the work goes back to that person, someone else loses a chance to learn. The expert gets another interruption and less time to explain what happened.

Give practice a place in the delivery plan. If it only happens when everyone has spare time, it may never happen.

Do this before an emergency. Pick a change the team understands and agree on who can approve it, who will carry it out and when to stop.

Check access first. The company should control the accounts, and people should have the permissions their role needs. Sharing an administrator password with everyone is not a good handover.

Keep the expert available, but let the other person do the work. Ask how they will check that the release succeeded. Walk through what they would do if it failed.

Use a test environment when an exercise could affect customers or data. Be clear about what you have not tested yet. Then fix the gaps and let the person try again.

A sensitive change may need a specialist or a second approval. Keep those checks. The team does not need everyone to be able to do everything.

It does need a plan for an absence. That might be another qualified person, someone to call for a decision or an agreement to wait before making a risky change.

You also cannot pass on years of judgement in one meeting. Start with the work the business most needs to keep doing, and make it clear where extra help is still needed.

Before calling the handover finished, ask someone else to use it. See where they stop, fix the missing pieces and try again.

The result you want is ordinary work that can carry on during an absence. The experienced person can still help with difficult decisions, without being needed for every release.