The pattern outlined here and the problems it causes are certainly real - I think most people who've seen a few large projects will recognize it. I wonder, tho

The pattern outlined here and the problems it causes are certainly real - I think most people who've seen a few large projects will recognize it. I wonder, though, at the final section about how converting 'hero engineers' back into regular ones is possible, but unpleasant and unreliable. If you try to change someone's role to involve less work and shorter hours and they hate you for it, something has probably gone very wrong. I've been friends with a couple of perennial 'hero engineers', as opposed to people pushed into that by a specific crisis. By and large, they like working that way, and would be very unhappy to swap into 'normal' roles. That's a useful trait! It's just squandered by a career of 12+ hour days and random priority shifts. (More broadly, I think healthy insight that software doesn't come from lone geniuses often neglects the value of those people and tries to reduce them to line programmers. Roles like hero engineer, guru, or hermit hacker can be perfectly useful in a business - just not as ways to produce day-to-day features in a larger project.) What's the alternative? Some of them have become excellent managers, using the same resourcing and firefighting skills more proactively. Others have ended up as sort of 'internal contractors', doing hero engineer work with a few key changes. In particular: time off and/or not working long hours between crunches, setting priorities by importance rather than convenience, making their role clearly distinct from 'normal' engineering expectations, ensuring teams understand and have a say in changes, and recognizing that this is the 'unhappy path' for projects to take. It generally seems to work best for companies doing things like selling customized software platforms, since they have many different 1-6 month projects going with independent schedules and shared domain knowledge. In practice, this looks something like: a projects falls behind or gets new requirements, an extra engineer (or several) are brought in, they work long hours getting up to speed and helping solve problems, once things are stable they spend some normal-length days with the team on training and tech debt to avoid 'owning' the result, then take some time off before the next cycle.