Heroes Not Required for Coders
When the System Runs on You
Are you the only one who can ship? Is the on-call an endless emergency? Does the legacy system require your brain to keep running?
Engineering teams have a pattern: one engineer becomes indispensable. They own the deployment process, the on-call runbook, the decision logic for releases, the institutional knowledge that lives nowhere else. The team says it's because they're great. The engineer keeps getting praised for their dedication. Meanwhile, no one can take vacation. The system breaks when they go sick. They can't change teams without leaving a crater.
That's not dedication. That's system failure hiding behind individual heroism.
This book is for engineering teams where the system is missing pieces that are being compensated for by individual excellence. It maps where overload concentrates in software teams—the deployment gatekeeper, the permanent on-call person, the person who owns every decision, the keeper of legacy knowledge—and gives you specific moves to move that burden into systems, runbooks, documentation, and decision criteria that don't require a person to be exceptional.
Use this book with AI tools
Prompts and instructions for working with this book inside ChatGPT, Claude, or any AI tool. Reader and practitioner editions available.
What's Inside
- When You Can't Take Vacation — The pattern of indispensability in engineering teams
- The Hero Trap — How competence becomes a system dependency
- What Overload Looks Like in Software — Recognizing compensatory patterns in code and process
- The Three Questions — Diagnosing whether load is system-based
- Mapping Load Placement — Where overload concentrates in engineering orgs
- Common Misreads — Why organizations misdiagnose system problems as people problems
- On-Call and Incident Response — When operational heroism masks system gaps
- Deployment and Release — When only one person can ship
- Technical Debt and Legacy Systems — When one person becomes the system
- Documentation and Knowledge Management — When the documentation is people
- Decision-Making and Architecture — When criteria don't exist
- Create What's Missing — Moves that get the burden off people
- Stop Before It Becomes Permanent — Preventing temporary heroism from hardening
Who This Is For
- Software engineers who've become the person everything depends on
- Tech leads and engineering managers whose teams only function through individual heroism
- Anyone who can't take vacation because the deployment, the on-call, or the legacy system requires them
- CTOs and VPs of Engineering who see the same patterns across their org
What Shifts After Reading
You stop seeing constant effort as dedication and start seeing it as system signal. The question changes from "How can I handle more?" to "What should the system be carrying that I'm carrying instead?"
The book gives you specific moves—write the runbook, document the decision rule, automate the emergency process, externalize the knowledge, make yourself replaceable—not as productivity tips, but as moves that get the burden off people and into the system.
Where to Go Next
Use this book with AI tools
Prompts and instructions for working with this book inside ChatGPT, Claude, or any AI tool. Reader and practitioner editions available.