How to learn from mistakes at work

Learning from a mistake starts with correcting the consequences you can address, reconstructing the sequence of actions and choosing a change that fits the cause. Promising never to make another mistake does not explain what will be different. A more useful commitment identifies a check, its owner and an opportunity to see whether it helps.

Correct the immediate consequences

Consider an everyday work example: you send a proposal with an outdated attachment. Before the discussion moves further, identify the incorrect file, provide the current one and state which version to use. If a decision has already relied on the old information, find out what needs reconsideration.

A short message might say: “My previous email included an older attachment. Please use this version; the delivery schedule has changed. I am sorry for the confusion.” The facts, correction and impact are more useful than a long defence or a promise of flawless future performance.

If the consequences require a decision outside your authority, involve the person who can make it. Keeping the problem hidden while you try to solve everything yourself can leave others working with information you already know is wrong.

Reconstruct the sequence

Record where the document came from, how you selected its version and where a check should have occurred. Use available messages and revision history. “I am always careless” does not tell you what happened between opening a folder and sending an email.

Google SRE’s approach to incident reviews examines contributing conditions and follow-up actions without assigning blame. It comes from engineering practice. For an ordinary work task, the useful principle is to examine the process while still taking responsibility for the correction.

Separate established facts from possible explanations. Two similar filenames are visible in the folder; the effect of rushing may still be an assumption. Ask participants what information they had at the time, rather than asking why they failed to think.

If reconstructing events leaves several possibilities, examine the fishbone examples. Each connects a possible explanation with information that could help investigate it.

Match the change to the cause

Place the safeguard where the confusion occurred. An individual error does not automatically justify another organisation-wide procedure.

When somebody else received the task, check whether the handover included authority and acceptance criteria. Our guide to delegating a task covers those decisions. People should not have to guess requirements that were never communicated.

Try the safeguard in comparable work

For the document example, agree on the location of the current file and who checks the link before sending. In the next similar task, observe whether selecting the right version is unambiguous. That gives a general instruction such as “improve oversight” a specific owner and moment of use.

One successful email does not establish that version confusion is impossible. If the mistake recurs, check whether the safeguard was used and whether it addresses the cause. Perhaps the current link exists but is difficult to find during normal work.

Keep the review proportionate to the consequences and recurrence. A minor, isolated typo may need a correction and a brief note. It does not necessarily need a lengthy investigation that takes more effort than the problem warrants.

Close the review with a usable record

Keep a short account of what happened, what has been corrected, the process change and when it will be checked. If feedback exposed a quality issue, the guide to turning feedback into action can help clarify the expected result.

An unsuccessful outcome is not always a mistake. Use a review of an unsuccessful attempt when you need to investigate an assumption instead. Once the correction is complete and the next action has an owner, return to the work. Learning requires a change in how something is done, not an endless return to self-blame.