Celebrate Wins, Learn from Losses

Of the twelve principles I use for building high-performing engineering teams at RJL.dev, one gets dismissed as the soft one - right up until it decides whether a team transforms or stalls. The principle: "We celebrate individual and team achievements. We conduct blameless retrospectives to learn and improve. This commitment to continuous improvement is our engine for transformation." Two sentences of culture, one sentence of consequence. Here is why it works and how to install it.

Two Halves of One System

Most teams treat celebration and retrospectives as unrelated rituals - one for morale, one for process. They are two halves of the same system: honest attention to outcomes. Split them apart and each fails alone:

• Celebration without retrospection turns hollow - a team cheering milestones while the same problems recur is performing happiness, not building capability.
• Retrospection without celebration becomes a grind - a culture that only convenes to dissect failure teaches people that attention means trouble, and engagement bleeds out.

Run together, they make every outcome - good or bad - into fuel. That is what "engine" means in the principle: not a metaphor, a mechanism.

Celebrate Individuals AND the Team

The wording is deliberate: individual and team achievements. Celebrate only teams and your strongest contributors become anonymous; celebrate only individuals and you breed internal competition on work that only collaboration can deliver. Doing both, well, has rules:

• Specific beats generic. "The migration cutover had zero customer-visible downtime because of the rehearsal you insisted on" outperforms "great job everyone" by a mile.
• Soon beats scheduled. Recognition within days of the win, not bundled into a quarterly review.
• Public beats private. Praise in the channel everyone reads; teams repeat what they see recognized.
• Progress counts. The failed experiment that produced a real lesson is an achievement - celebrating it is how you keep people experimenting.

Blameless Means Blameless

The retrospective half fails most often at one word. A blameless retrospective starts from the premise that people made reasonable decisions given what they knew - so the interesting question is never "who did this" but "what made this the reasonable thing to do." Fix the system that produced the decision: the missing alert, the ambiguous runbook, the deploy process that made the shortcut attractive. This is where psychological safety stops being a poster: people will only challenge ideas, admit mistakes, and ask questions when doing so is safe, and one blame-shaped retrospective destroys quarters of built trust. Blame drives information underground, and information underground is how near-misses mature into outages.

The Retro That Actually Changes Things

Blameless does not mean toothless. A retrospective earns its hour with three mechanics:

1. Every finding becomes an action with one owner and a date. Not "we should improve monitoring" - "Sam adds the missing alert by Friday."
2. Every retro opens with the last retro's actions. Done, blocked, or dropped - reviewed out loud. Nothing kills the ritual faster than actions that vanish.
3. Changes ship as small experiments. Try the new on-call handoff for two sprints and re-examine it, instead of decreeing a process forever.

A retro that produces discussion but no owned actions is a venting session with a calendar invite.

The Engine for Transformation

The third sentence of the principle is the payoff: continuous improvement as the engine for transformation. The math is compounding. A team that gets one percent better each week is not one percent better after a year - improvements stack on improvements, and the retro habit that fixed the deploy pipeline gets applied to onboarding, then to incident response, then to how decisions get made at all. Transformation programs fail when they arrive as a big bang from above; they succeed when they arrive as hundreds of small, owned, team-generated improvements - which is exactly what this loop produces. Sustainable performance follows for the same reason: teams that see their wins recognized and their problems actually fixed stay engaged, and engaged teams do not need heroics to deliver.

Why the Soft Principle Is Hard

If this loop were easy, every team would run it. The failure modes are predictable, and naming them is half the defense. Celebration feels awkward at first - engineers are trained to find flaws, and public praise reads as performative until it has happened enough times to be normal; the fix is for leaders to go first and keep going. Retros drift into status meetings - the moment updates crowd out examination, the hour is lost; guard the agenda. Blame sneaks back dressed as accountability - "who owned this?" sounds responsible while quietly re-teaching people to hide; keep ownership attached to actions going forward, never to fault looking backward. And the loop gets cut first under pressure - the sprint runs hot, the retro gets skipped, the win goes unmarked, and six months later leadership wonders where the engagement went. The teams that transform are not the ones that run the loop when it is convenient. They are the ones that run it especially when it is not.

Signs It Is Working

The culture is installed when you observe these without prompting:

• People report their own mistakes before anyone else finds them
• Retro actions ship, and the next retro references them
• Wins get named specifically in public channels, fast, by peers - not just by managers
• Near-miss reports increase while repeat incidents decrease
• Process changes come from the team, not just from leadership

Start Here

To install the loop on your team:

1. Celebrate the next real win within 48 hours - specifically, publicly, naming people.
2. Schedule a retrospective with the blameless premise stated out loud at the start, every time.
3. Leave with owned, dated actions - and open the next retro by reviewing them.
4. Once a quarter, celebrate a failure that taught you something real. That is the day the culture becomes believable.

Wins celebrated, losses converted to lessons, lessons converted to changes that stick. That loop, run relentlessly, is the engine - and teams that run it transform themselves.