End-of-Year Retros: What Worked, What Didn’t

My annual ritual for getting better as a developer and a leader.

The end of the year is a useful point to look back, once the temptation to rewrite history has been resisted. A good retrospective is less about celebrating a flawless plan and more about noticing which habits helped, which did not, and which meetings could have been an email.

The useful question behind “End-of-Year Retros: What Worked, What Didn’t” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.

The answer is rarely a universal rule. It is a way of looking at the decision clearly enough to choose on purpose.

Notice what the work is teaching

The most useful lessons often arrive through ordinary work. A choice feels awkward, a conversation goes better than expected, or a supposedly small task reveals something important about the system around it.

I try to make those lessons explicit. Name the trade-off, test the assumption and leave a note for the next time. Reflection is most useful when it changes a future action.

Experience becomes useful when it changes what you do next.

A practical way to start

Before changing anything, I try to answer three ordinary questions:

• What problem are we actually trying to remove?
• Who will have to understand this after us?
• What evidence would make us change direction?

None of those questions produces an automatic answer. They do make the trade-offs visible, which is usually the point where a team can stop arguing from instinct and start making a decision together.

Craft improves through attention. Do the work, notice the result, and carry the useful part forward.

There will always be exceptions. The trick is to make them deliberate exceptions rather than habits nobody remembers choosing.