🔸 TL;DR 🧭
Heroing = repeatedly “saving” releases by fixing others’ work at the last minute. It feels helpful but breeds undisciplined coding, trust issues, and tech debt. Replace heroics with habits: earlier feedback, shared ownership, and stable delivery practices.
🔸 What is “Heroing”? 🦸♂️
A recurring pattern where one person jumps in right before release to “fix” things. Over time it: undermines growth, short-circuits feedback loops, creates dependency on the Hero, and seeds technical debt.
🔸 Why it’s harmful 🚫
▪️ Encourages undisciplined programming (“the Hero will fix it anyway”)
▪️ Erodes trust and healthy delegation; invites micro-management
▪️ Hides systemic issues behind last-minute patches
▪️ Increases risk right when quality should be highest (release)
▪️ Slows learning—engineers don’t get timely feedback
🔸 How to recognize it 🔍
▪️ Self-merged PRs or rushed approvals with low receptiveness to review
▪️ Spikes of activity only right before release
▪️ Repeated “critical saves” by the same person across sprints
▪️ Vague ownership; unclear Definition of Done
🔸 Root causes 🧩
▪️ Weak delegation, unclear roles & ownership
▪️ Late feedback cycles (reviews start days after code is written)
▪️ Overstuffed sprints, no WIP limits, poor release discipline
▪️ Missing guardrails (tests, CI, quality gates)
🔸 What to do instead ✅
▪️ Shift feedback left
▪️ Pair/Mob programming; short, early PRs; review SLAs
▪️ Trunk-based development with feature flags
▪️ Build guardrails
▪️ Mandatory checks: tests, linters, static analysis, coverage, quality gates
▪️ CI/CD with fast pipelines and pre-prod smoke tests
▪️ Clarify ownership & flow
▪️ Definition of Ready/Done; small batch sizes; WIP limits
▪️ Rotate “release shepherd” and on-call to spread context
▪️ Coach the Hero
▪️ Turn last-minute “fixes” into documented, actionable feedback
▪️ Mentor teammates; write runbooks instead of doing silent rescues
▪️ Make work visible
▪️ Track escaped defects, late merges, and review latency as team metrics
▪️ Run blameless retros focused on system changes, not individuals
🔸 Takeaways ✍️
▪️ Heroing is a signal, not a solution—treat the system, not the symptom.
▪️ Replace personal heroics with team habits and automation.
▪️ Early collaboration beats late rescue every time.
▪️ Sustainable delivery > last-minute glory.
#Agile #SoftwareDevelopment #EngineeringManagement #TeamCulture #DevOps #CodeReview #TechDebt #Quality #Leadership #SoftwareEngineering
Go further with Java certification:
Java👇
Spring👇
Stavros said :
Great post Vincent. Hero culture often feels like dedication, but in reality it hides systemic weaknesses. I have seen how shifting feedback earlier, clarifying ownership, and limiting WIP reduce the need for last minute “saves.” When teams move from individual heroics to shared responsibility, delivery becomes both faster and more stable.
Curious, in your experience, which practice has had the biggest impact on reducing heroing? Feedback cycles, ownership clarity, or guardrails?
I answered:
What makes me the life easier was the feedback loop 🔄️; not having a last minute feedback was terribly helpful.