meta-learning-engineering-retrospection

name	meta-learning-engineering-retrospection
description	Use after completing major features, recovering from incidents, making architectural decisions that turned out wrong, or when repeated mistakes suggest stagnant mental models and missing feedback loops.

Meta-Learning & Engineering Retrospection

Overview

Build a feedback-driven improvement loop to accelerate long-term growth. Every project, incident, and decision is raw material for learning -- but only if you extract the lesson deliberately. Growth compounds through structured reflection, not just accumulated experience.

When to Use

• After completing a major feature, project, or migration.
• After an incident, outage, or production issue.
• When a prediction about a design turned out to be wrong.
• When the same class of mistake keeps recurring.
• When reviewing past decisions with new knowledge.
• At regular intervals (weekly, monthly, quarterly) for personal retrospection.

When NOT to Use

• Mid-implementation when focus should be on execution.
• For trivial tasks that carry no learning signal.

Core Competencies

Competency	Key Question
Structured retrospectives	What went well, what went wrong, and what would I change?
Flawed assumptions	Which beliefs turned out to be incorrect?
Prediction accuracy	How did my estimate or design assumption compare to reality?
Reusable lessons	Can this learning be generalized and applied to future work?
Heuristic refinement	Should I update my decision-making rules based on this outcome?

Practice Loop

1. Document surprises -- after major work, write down what you did not expect.
2. Identify root causes -- for mistakes, trace the reasoning chain that led to the wrong decision.
3. Refine heuristics -- update personal rules of thumb based on observed outcomes.
4. Update tooling -- if a process failed, improve automation or checklists to prevent recurrence.
5. Revisit past decisions -- periodically review old choices with current knowledge; note what changed.

Failure Signals

Stop and reflect if you observe:

Signal	Root Cause
Repeating the same mistakes	No retrospective performed; lesson not extracted
No documentation of lessons	Learning stays tacit; lost when context fades
Defensive reaction to failure	Failure treated as threat instead of data
Stagnant mental models	No new inputs challenging existing assumptions
Estimates consistently wrong in the same direction	Systematic bias not identified or corrected
Same incident class recurring	Postmortem action items not completed or not effective

Quick Reference

Personal Retrospective Template:

## What I Worked On
Brief description of the project, feature, or incident.

## What Went Well
- What decisions paid off?
- What processes worked?
- What would I repeat?

## What Went Wrong
- What surprised me negatively?
- Where was my mental model incorrect?
- What took longer or was harder than expected?

## Root Causes
- Why did the wrong things go wrong? (not symptoms, causes)
- What assumptions were flawed?
- What information was I missing?

## Prediction vs Reality
| Prediction | Reality | Delta |
|------------|---------|-------|
|            |         |       |

## Lessons Extracted
- What reusable principle can I take from this?
- Does this change any of my decision heuristics?
- Should I update a checklist, skill, or process?

## Action Items
| Action | Type (process/tooling/knowledge) | Due |
|--------|----------------------------------|-----|
|        |                                  |     |

Heuristic Refinement Log:

## Heuristic
State the rule of thumb.

## Origin
When and why did I adopt this heuristic?

## Evidence For
Instances where it held true.

## Evidence Against
Instances where it failed or misled.

## Updated Heuristic
Refined version based on accumulated evidence.

## Confidence
High / Medium / Low -- based on evidence volume.

Common Mistakes

Mistake	Fix
Skipping retrospectives when things went well	Success hides lessons too; review what worked and why
Retrospectives without action items	Every retrospective must produce at least one concrete change
Blaming external factors exclusively	Focus on what was within your control and what you would change
Documenting lessons but never revisiting	Schedule periodic reviews of past lessons; update or archive
Treating heuristics as permanent rules	Heuristics are hypotheses; update them as evidence accumulates
Reflecting only on failures	Successes reveal which heuristics and processes are worth keeping