How do I learn from a task that went well, not just one that went wrong?

Treat the review as curiosity, not a victory speech. Write down the intended result and what actually happened, using observable details rather than labels such as “I was brilliant” or “the team was great.” Then reconstruct the sequence: what you did before starting, what decisions you made during the task, and what you did when something changed.

For example, suppose you prepared a short project update and the meeting reached a decision. Record that concrete outcome. Then ask what might have contributed: perhaps you sent a brief agenda in advance, brought two options, or asked for the decision early. Those are possibilities to examine, not automatic causes. A smooth meeting could also have depended on the attendees already agreeing or on a change in priorities. The point is to find plausible factors worth checking, not to claim certainty.

Make two columns: “my choices” and “other conditions.” In the first, list actions you could choose again, such as clarifying the request, setting a checkpoint, or asking a focused question. In the second, note factors like a colleague’s timely input, a lighter workload, or a decision that arrived sooner than expected. Some items involve both: you may have requested help, while another person supplied it.

For each possible contributor, ask: “What did I observe that makes me think this mattered?” and “What else could explain the result?” If you have a concrete clue—say, the requester answered your clarification before you drafted—include it. If it is only a hunch, mark it as one. This keeps credit fair and helps you avoid turning one successful result into a sweeping story about your ability or someone else’s contribution.

Translate the lesson into a small experiment, not a rule you must follow everywhere. Write: “Next time, I will try [action] when [condition], because [reason]. I’ll check whether it helped by noticing [observable sign].” Then name what differs in the new situation. A preparation habit may transfer to another project, while the exact format, timing, or people involved may not.

Worked example, using an assumed situation: “The project update ended with a clear decision. I had sent two options beforehand, and the decision-maker chose one during the meeting. Next time I’ll send options in advance when a decision is needed, then check whether the group can use the meeting to choose. If the decision-maker has not reviewed the options, I’ll ask what preparation would be useful instead.” That preserves the possible lesson while leaving room to adapt.

Use this as a five-minute success review. Short answers are enough; “not sure yet” is a useful answer too.

Success review

• Task and date: [task] / [date]
• Intended result: [what I was trying to accomplish]
• What happened: [observable result]
• Choices I made: [actions I could choose again]
• Helpful conditions or support: [what else may have contributed]
• Clues and uncertainties: [what I observed; what I’m only guessing]
• What may transfer: [one action and the conditions where it may help]
• Next small test: [action] / [sign I’ll look for]

Keep the note for your own working reference or share it if that suits the task. Review it later when a similar situation comes up: keep what still fits, adjust what does not, and add what you learn. The worksheet is a reflection aid, not a way to prove cause and effect from a single result.