At 4am, James was a hero. Again.
He’d fixed production. Saved the company. Everyone would thank him on Monday.
Six months later, James burned out and quit. The platform collapsed within a week.
Your heroes aren’t saving your platform. They’re hiding its failures.
THE HERO PARADOX™
Every failing platform has the same story:
One brilliant engineer holds it all together. They know every system. Fix every issue. Answer every question.
Everyone says: “Thank god for [Hero’s Name]!”
I say: “Your platform is already dead.”
Here’s why:
Heroes Don’t Scale
- Bus factor: 1
- Knowledge silo: 100%
- Burnout rate: Guaranteed
- Documentation: “Ask James”
Heroes Hide Problems
- Broken process? Hero fixes it
- Bad architecture? Hero works around it
- Missing automation? Hero does it manually
- Team gaps? Hero covers them
Heroes Prevent Growth
- Others stop learning (why bother?)
- Innovation dies (hero’s way only)
- Ownership disappears (hero will handle it)
- Culture toxifies (heroes vs everyone)
HOW LOUD VOICES CREATE HERO CULTURE
Heroes aren't born. They're created by broken systems and loud architects.
It starts with complexity worship. The loudest technical voice insists on:
- "Proper" abstractions
- "Best practice" everything
- "Future-proof" architecture
Soon, only they will understand it.
They become indispensable. They've architected their own job security.
I saw this at a startup. Their "10x engineer" built a platform so complex, he was the only one who could operate it. He wasn't a hero. He was a hostage-taker.
The real tell? Heroes who resist documentation, pairing, or simplification. They're not protecting the platform. They're protecting their status.
THE 2-PIZZA PLATFORM TEAM RULE
Amazon got one thing right: 2-pizza teams.
Your platform team should be:
- Small enough to share 2 pizzas
- Large enough to take vacations
- Diverse enough to challenge ideas
- Autonomous enough to ship
The magic number? 5-8 people.
Fewer: Hero dependency. More: Communication overhead
In last week’s masterclass, we analyzed team structures. The pattern was clear: Teams under 5 always had a hero. Teams over 10 had communication chaos. Sweet spot confirmed.
THIS WEEK’S PLATFORM PSYCHOLOGY INSIGHT
Your responses revealed a painful pattern:
“We can’t let [Hero] take vacation. Everything breaks.”
If your platform can’t survive a vacation, it’s not a platform. It’s a house of cards with a human support beam.
Real quote from a “hero” who emailed me:
“I haven’t taken a real vacation in 3 years. I’m exhausted, but if I leave, everything burns. I created my own prison.”
THE HERO DETOX PROGRAM
How to save your platform from hero dependency:
Week 1: The Knowledge Audit
- List everything only one person knows
- Rank by criticality
- Start documenting the top item
Week 2: The Rotation Requirement
- Every task must have 2 people who can do it
- Rotate weekly
- No exceptions
Week 3: The Documentation Sprint
- If it’s not written, it doesn’t exist
- “Ask X” is not documentation
- Record every hero action for a week
Week 4: The Forced Vacation
- Hero takes a day off
- No calls, no Slack, no “quick questions”
- Let small things break
- Document what failed
Week 5: The Handoff Protocol
- Every hero task gets an owner (not the hero)
- Hero advises only
- New owner documents as they learn
Want to see this program in action? In the August masterclass, I’ll walk through a real team’s hero detox, including the surprises they discovered.
REAL STORY: THE £10M HERO DISASTER
FinTech company. One “10X engineer” built their entire platform. Everyone praised his brilliance.
The architecture:
- Custom everything
- Zero documentation
- Proprietary DSL
- His personal AWS account
He asked for a raise. They said no. He left.
Result:
- 3-month platform rebuild
- £10M in delayed features
- 5 engineers to replace 1
- Customer trust destroyed
The CEO’s reflection: “We didn’t have a platform. We had an extremely expensive single point of failure with a name badge.”
BUILDING PLATFORMS WITHOUT HEROES
Instead of Hero Worship: “Sarah fixed production at 2am!”
Build Hero Prevention: “Why did production break at 2am?”
Instead of Secret Knowledge: “Only Tom knows how the deployer works”
Build Shared Understanding: “Let’s pair on the deployer until we all get it”
Instead of Clever Solutions: “Mike’s ingenious workaround saved us!”
Build Boring Reliability: “The system handled it automatically”
YOUR ACTION PLAN: ELIMINATE HERO DEPENDENCY
This week, pick your biggest hero dependency and:
- Shadow the hero for one day - Document everything they do
- Create a runbook for one critical task - Test it with someone who’s never done it
- Implement one automation - Replace one manual hero action
- Force-rotate one responsibility - Hero can advise but not touch
- Celebrate boring success - Praise the non-heroic work
Bring your results to the masterclass - we’ll troubleshoot what didn’t work.
THE BUSINESS COST OF HERO DEPENDENCY
Let's talk money. A platform that needs heroes is expensive:
Direct Costs:
- Hero salary premium: +£20-40K
- Can't take vacation: -£5K productivity
- Bus factor insurance: Priceless
Hidden Costs:
- Other engineers learn less: -20% team productivity
- Fear of change: -50% innovation speed
- Burnout replacement: £50K hiring cost
Real example: Retail client's hero left. Platform was down for 3 days. Cost:
- Lost revenue: £2.3M
- Emergency contractors: £45K
- Customer trust: Immeasurable
- New hire (3 people to replace 1 hero): £250K
The math: Heroes cost 5-10x their salary when they leave. Build systems, not dependencies.
READER QUESTION: “BUT WE NEED HIGH PERFORMERS!”
“Steve, aren’t you discouraging excellence? We want 10X engineers!”
No. I’m discouraging single points of failure dressed up as excellence.
Real 10X engineers: - Make their team 10X better - Build systems that don’t need them - Document obsessively - Teach constantly - Eliminate heroics
Fake 10X engineers: - Hoard knowledge - Build job security through complexity - Work alone - Create dependencies - Thrive on emergencies
One multiplies. The other divides.
⚠️ PLATFORM ALERT: THE BITNAMI TIME BOMB ⚠️
Speaking of hero dependencies, here's one ticking in your infrastructure right now.
On August 28, 2025, Bitnami is restructuring how they distribute containers. Most of their public images are moving to a Legacy repository. No updates. No patches. Just frozen-in-time containers.
Why this matters: Your "boring" PostgreSQL container? Probably Bitnami. That Redis instance that "just works"? Likely Bitnami. Your entire Helm chart collection? Check for docker.io/bitnami.
The Hero Creation Pattern:
- Builds mysteriously fail after August 28
- Your hero "quickly fixes" with workarounds
- Security scanners find vulnerabilities (no patches available)
- Hero maintains custom patches nobody else understands
- Hero burns out → Platform collapses
What's changing:
- Free tier: Only hardened, latest-tag images
- Version pinning: Gone
- Security patches: Paid tier only
- Your stable infrastructure: About to become unstable
THE 5-MINUTE BITNAMI AUDIT
Before this becomes another 3am emergency:
# Find your exposure
grep -r "docker.io/bitnami" . | wc -l
kubectl get pods -A -o jsonpath="{.items[*].spec.containers[*].image}" | \
tr " " "\n" | grep bitnami | sort | uniq
If you see ANY results, you have work to do.
Your options:
- Ignore it → Create future heroes and emergencies
- Pay for Secure Images → Vendor lock-in, ongoing costs
- Migrate now → One-time effort, permanent solution
This week's action: Run the audit. Pick ONE service to migrate. Start simple - Redis or Memcached. Build momentum before the end of August.
Resources:
Don't let "boring" infrastructure become your next hero emergency.
YOUR INVITATION: THE AUGUST MASTERCLASS
Building on July’s success, our August session tackles the human side of platforms.
“The Boring Technology Revolution: Building Hero-Free Platforms”
What we’ll cover: - Live Knowledge Post-It Audit (volunteer your team!) - The Hero Detox Program walkthrough - Building platforms that run themselves - Creating documentation culture - The “Vacation Test” for your platform
When: Tuesday 19th August, 2pm UK / 9am ET
Format: 90 minutes of transformation
Spots: 12 only (July filled in 48 hours)
Reserve Your Free Spot →
Special focus: We’ll combine July’s deletion lessons with hero-free principles. Less complexity + shared ownership = sustainable platforms.
THE HERO-FREE PLATFORM METRICS
Track these monthly:
✓ Bus Factor: How many people can fix each system?
✓ Vacation Days: Actually taken, not accrued
✓ 3am Calls: Should approach zero
✓ Documentation Coverage: Runbooks for every alert
✓ Knowledge Distribution: No single expert areas
If these improve, you’re building sustainably.
📢 FROM THE NEWSLETTER TO THE STAGE
I am taking the deletion philosophy on the road!
I'll be at BitSummit Hamburg (Sept 4th) sharing the full story behind our biggest platform transformation - the one that started with pink post-its and ended with GitOps clarity.
"From Console Chaos to GitOps Clarity: A FinTech Transformation Tale"
Newsletter readers get 15% off with code: STEVE_BITSUMMIT
Register: https://bitsummitapp.eventify.io/t2/tickets
See you in Hamburg? Reply and let me know!
WHAT’S COMING NEXT WEEK
Issue #007: “The Platform Metrics That Actually Matter”
- Why CPU usage is vanity
- The five numbers that predict platform health
- Building dashboards developers actually use
- Plus: Results from August’s Knowledge Audits!
Build platforms, not heroes.
Steve
P.S. Best response this week: “We read this issue as a team. Our ‘hero’ almost cried with relief. He thought we wanted him chained to his desk. We’re starting rotations Monday.” This. This is how change happens.
P.P.S. If you’re the hero reading this: It’s not your fault. But it is your responsibility to stop being one. Your platform, your team, and your sanity depend on it. Come to the masterclass - you’ll meet other recovering heroes.
📅 AUGUST MASTERCLASS: Building Hero-Free Platforms
Date: Tuesday 19th August, 2pm UK
Topic: The Boring Technology Revolution Continues
Can’t make it? Register anyway for the recording. But the live Knowledge Audits are worth clearing your calendar for.