Symptom: the ticket is closed, the customer is happy and you could not tell a colleague what actually fixed it. If that sounds familiar, you are not alone, and it is worth treating as a fault to diagnose rather than a quirk of busy weeks. A fix you cannot explain is a fix you will have to rediscover. Below is a plain diagnosis of why support engineers end up there, and a short treatment that costs about twenty minutes per incident: explain what you just learned to a beginner, in writing, while the details are still fresh.

The symptom in detail

You restart a service, clear a cache or roll back a setting, and the problem disappears. The pressure to move on to the next ticket is real. Because you are not sure which of your three actions did the work, you record “resolved after restart” and close it. Two weeks later a different engineer meets the same alert, reads your note and restarts the service again, only to find it does not help this time. The note had the outcome but not the understanding.

Diagnosis: three root causes

• Changing several things at once. Under pressure we apply every plausible remedy in a row. The system recovers, and the cause stays hidden among the actions.
• Recognition mistaken for understanding. You have seen the error before, so it feels known. But feeling that you know a symptom is different from being able to say why it happens.
• No audience. A closing note written for yourself skips the reasoning, because you already hold the reasoning in your head, or believe you do.

The third cause is the one a teaching exercise fixes directly. The moment you imagine a beginner reading your note, you find out which parts of the reasoning you cannot supply.

Treatment: the twenty-minute teach-back

Right after the incident, before you pick up the next ticket, do the following.

1. Write the symptom as the customer saw it. One or two sentences, no internal jargon.
2. Write what you believed at the start, including the wrong theories. These are gold for the next reader, who will probably start from the same wrong theory.
3. Write the sequence of actions and, beside each, whether it changed anything. If you cannot say, mark it “unknown” rather than guessing.
4. State the cause in one plain sentence. If you cannot, say what the leading explanation is and what evidence would confirm it.
5. Add one check a newcomer could run in under a minute to tell whether they are looking at the same problem.

Whenever you hit an “unknown”, resolve it properly: reproduce the problem in a test environment and apply the actions one at a time. A home lab is ideal for this, and a hands-on tutorial like setting up a safe practice space for DevOps at home shows how to build one cheaply. Reproducing the fault turns a lucky fix into knowledge.

Verification: how to tell the treatment is working

Give the finished note to someone newer than you and ask one question: “What would you do if this alert fired tonight?” If their answer matches what you did, the note works. If they ask something your note does not answer, you have found the next gap, and you can patch it immediately. Over time you should see fewer repeat tickets that start from the same confusion and fewer escalations that begin with “I do not know why this worked last time”.

Contraindications

This method has limits, and it is better to be upfront about them.

• During a live outage, restore service first. The teach-back happens afterwards, not during.
• Do not publish anything containing customer data, internal hostnames or credentials. Strip the details; keep the pattern.
• Do not turn the write-up into blame. Describe what the system did and what you believed, never who failed.

Prescription: give the notes a home

A pile of private notes helps one person. Shared and public notes help many. For internal material, a team wiki works. For general lessons stripped of anything sensitive, consider a public blog. MyBlogPad is a blogging network where a blog gets its own subdomain, sign-in is through Google, and several people can contribute; the service describes itself as free to start. Short “what I learned” posts there double as a visible record of how you reason, which is useful the next time someone asks what you have been working on.

A sample entry, trimmed

To make this concrete, here is the shape of a good entry. Title: “Why the nightly job reported success but produced an empty file”. Symptom: reports arrive blank every Monday. First belief: the job crashed silently. Actions: checked logs, reran manually, widened the disk quota. Which one mattered: unknown until I reran it in a test copy, where only the quota change failed to help. Cause: a source folder was being rotated at the same moment the job started, so it read nothing. Quick check: compare the folder’s modification time with the job’s start time. Nothing in that entry is clever, yet it would have saved me two hours the previous month.

For the broader picture of how engineers grow into this kind of thinking, a practical case for people on the development side picking up operational skills is a useful companion, because the same explain-it-back habit works in both directions.

Follow-up

Review your last three closed tickets. For each, ask whether you could explain the cause to a beginner without looking at the notes. Where the answer is no, run the teach-back now. You will find the cure is cheap, the side effects are good, and the next engineer to meet the same alert will thank you.