“Be more careful” won’t fix your release process

A release uses the wrong configuration. The team restores the service, checks the impact and starts discussing what happened. Someone suggests reminding everyone to be more careful.

That reminder leaves a lot unexplained. What could the person see? Which instructions were current? What happened during the handover? Could someone else face the same conditions tomorrow?

Human factors gives you a way to explore those questions and choose a change that reaches beyond the person who made the final click.

The UK Defence connection

Human factors examines how people interact with their tasks, tools, working environment and one another. It is a broad discipline used in many fields, including UK military aviation.

The Military Aviation Authority’s March 2026 training framework includes attention and perception, situation awareness, fatigue, workload, communication and error management. Those topics offer a useful starting point for examining tech work. The review below is a practical workplace adaptation.

A practical tech example

For example, a developer prepares a configuration change for a customer-facing application. During a handover, the colleague taking over is interrupted by a support message. They return to an open deployment window and assume the displayed configuration is the approved version.

It is an earlier version. Both files have similar names, and the handover notes say “ready to deploy” without linking to the reviewed change. The incident review needs to understand how that state became plausible to the person doing the work.

How to put it into practice

1. Reconstruct the work people actually saw

Purpose: Understand the decision with the information available at the time.

Build a short timeline using the handover record, change history and accounts from the people involved. Separate evidence from interpretation. Ask what each person believed had already been checked.

Avoid rewriting the story using knowledge gained after the incident. “They should have known” is less useful than identifying which visible cue suggested that the configuration was ready.

2. Look for competing demands

Purpose: Identify pressures the process needs to accommodate.

Ask what else required attention during the handover. Was the receiving colleague also handling support? Did they know whether the release could pause? Were there enough people to cover both responsibilities?

If workload or fatigue is raised, discuss the working conditions and available support. Do not make a colleague justify private circumstances to explain why a fragile process failed.

3. Make the current state explicit

Purpose: Reduce the amount people must infer or remember.

Replace “ready to deploy” with a link to the exact reviewed change, the target environment and the checks already completed. Record what remains to be done and who now owns it.

The receiving colleague can summarise their understanding before taking over: “This is the approved configuration for production. The deployment has not started. I own the next step.” Resolve differences before proceeding.

4. Give interruptions a recovery step

Purpose: Help people resume with reliable context.

Agree how to leave work in a clear state when attention shifts. In this example, the team could close stale deployment windows and reopen the approved change from the handover record before resuming.

Define when a release should pause and who covers urgent support. An instruction to avoid interruptions needs a workable way for the team to handle the interruption that still arrives.

5. Check the improvement in normal work

Purpose: Find out whether the change helps the next handover.

Choose a small change with an owner and a review date. Walk through the revised handover using a safe test environment, including an interruption before the next step.

Then ask colleagues who use it whether they can identify the approved version and remaining checks without asking the original developer. If the record takes too long or is routinely bypassed, inspect that friction before adding another reminder.

A record you can use

What to try next

Choose one recent handover that caused confusion. Ask the people involved to describe what they understood at the point they took over, and compare that with the record they received.

Keep responsibility clear while examining the surrounding conditions. A useful review leaves the next person with a clearer task, reliable information and a realistic way to ask for help.

Source: Military Aviation Authority, Human Factors training requirement, version 5.1 (March 2026). The tech examples and working tools are Coded Female adaptations.