Most portfolios show the finished screen. I have been on enough teams to know that the finished screen is the least useful part of a project. The useful part is the decision that looked right on Monday and was wrong by Friday — and what the team did next.
So every case study on TaherSoft has a section called what went wrong. Here is why, and how I write them.
Blameless is not the same as soft
A blameless retro does not pretend nothing bad happened. It assumes everyone acted reasonably with what they knew at the time, and then asks why what they knew was not enough. People do not fail in a vacuum; systems, deadlines and missing information set them up.
When the question is “who”, people hide facts. When the question is “how did this make sense at the time”, they bring them.
The one-page template
- What we expected. One paragraph. The plan, in the words we used then.
- What happened. A timeline with times. Facts only, no adjectives.
- Why it made sense. The context behind each decision: what we knew, what we didn’t, what we were optimising for.
- Contributing factors. Usually several. If there is only one, keep digging.
- What we changed. Concrete actions, each with an owner and a date.
- What we still don’t know. The honest list. It keeps the next retro short.
Habits that make it work
- Write it within a week, while the details are still there.
- The person closest to the problem writes the first draft. The lead edits for tone, not for content.
- Share it wider than feels comfortable. Other teams learn more from your retro than from your wins.
- Track the actions like features. A retro whose actions never ship teaches the team that retros are theatre.
Why put it in public
Because it is the most honest signal I can give someone deciding whether to work with me. Anyone can describe what they built. What they learned when it broke tells you how they will behave on your project when something breaks — and something will.
The case studies, and soon a podcast season about them, live on TaherSoft.
