The cost of Heroes on your software team

Over the years, I've seen all sorts of organizational and systemic problems within organizations that actively cause them to work against themselves. These ultimately manifest as missed deadlines and, unmet goals while incurring additional costs. One such issue I see fairly often is the Hero problem. I consider Heroes to be those indispensable individuals in any role that consistently swoop in at the 11th hour to put out fires right before the product ships. They are often considered to be the most productive contributors and absolutely have to be included in every meeting they tend to be the core decision-makers.

Let's regroup on this since person X isn't here right now. I'll reach out to them and setup another meting.

It's really hard not to look up to these individuals since they put in a lot of effort and their willingness to often go the extra mile comes from a genuine desire to see everyone's hard work come to fruition. They often work nights and weekends taking to meet that critical deadline.

commit 3b981382881aa88555ae7585dab7351217375e4c (HEAD -> master, origin/master, origin/HEAD)
Author: John Doe <hero@example.com>
Date:   Wed Feb 10 02:34:00 2021 -0800

    Implement some feature to meet a big deadline

Their work often doesn't go unnoticed. Everyone knows who they are and just how much they've put into the project and the company. This often leads to advancements quickly through the ranks as an explicit reward for their efforts. After all the project would not have shipped or seen nearly as much success without their contributions.

This sets a devastating cultural precedent. Specifically, one that thrives on crisis, big and small. This is partly because rewards and advancement become tied to heroics. Working unsustainable hours and being the go-to resource for every problem is a sign of commitment to the project and the organization

“it’s critical to admit that this type of heroism is not a sign that you have very committed people — it’s a sign that you have a very immature organization. The need for heroism is revealing the fact that you haven’t scaled your organization’s processes to effectively withstand the brunt of the unexpected, leaving it on individuals to bear.” [1]

I see this the most in organizations that failed to scale effectively. They often did not invest in the cultural aspects of building a high-functioning organization and inadvertently created an environment where only a handful of people were directly responsible for pushing the product forward. Over time, this led to periods of mass voluntary attrition because not everyone is ready to live through the periods of burnout and mental anguish that come at the cost of heroism.

Hiring replacements is often sold as the solution to the problem. "As long as the heroes stick around, we can always hire and train new talent". What this ignores are the costs associated with high attrition.

“Financial losses aside, there are also hidden costs of turnover. The departure of great people can have a major influence on team morale and places an unnecessary burden on remaining employees who acquire the extra workload. All too often, the ripple effect of leaving causes employees to question if they, too, should jump ship. Further, the “tribal knowledge” loss that happens makes the segue from replacing a seasoned employee with a new hire even more difficult.” [2]

Great team members are difficult to replace because of the context that builds up over time. I'm talking about decisions that had to be made as a result of esoteric problems that never made it into documentation because they were either made in the moment or unplanned as a result of unexpected circumstances. All of this context has to be learned by new hires. This means that they are low-value adds that require significant onboarding resources dedicated to them to deliver long-term value.

“When you look at high-level employees transitioning within a company, research indicates they feel they add value by about six months,” he says. “But if you’re coming into a challenging job from outside the company, it may take a year.” [3]

This usually ends up making heroes even more indispensable to the organization. They can never leave because they have all the context, and they have all the context because everyone around them tends to leave due to the unsustainable work culture. The entire organization has to work around them even when they make bad decisions because no one wants to risk pissing them off and being the reason why that one indispensable resource left the company and now the project is in jeopardy.

💡
Ironically, I would argue that cutting them loose (or at least moving them to a new team where one can reset expectations) is the right thing to do under these circumstances. Having high bus factor individuals is a recipe for disaster given all of the risks associated with them. The best time to begin rebuilding your team culture is as soon as you identify the issue.

Having all this context collected in one place has the added effect of making Heroes information silos. They often don't invest a lot of time in training other engineers because they are too busy addressing all the problems that they've taken on as well as attending every meeting. After all, decisions can't be made in their absence. This means that despite all of their hard work and good intentions they simply cannot help you scale your organization.

“As with any other role, the end goal is to replicate yourself. For Staff Engineers, this means creating more Staff Engineers. A convenient byproduct of creating a prioritized list of technical problems is that you’ve automatically created a set of high-impact projects for growing senior engineers. This is a great way to elevate your colleagues while giving yourself extra bandwidth.” [5]

Conclusion

Engineers generally enjoy feeling needed. It's definitely a great feeling to be the hero the project needed when the team needed one the most. However, it should never be allowed to become a culture. The risks attached to it are much too great to build a sustainable engineering practice. Heroes just aren't worth the long-term cost.


  1. Harvard Business Review. (2021). Does Your Company Lurch from Crisis to Crisis? [online] Available at: https://hbr.org/2021/03/does-your-company-lurch-from-crisis-to-crisis. [Accessed 20 Mar. 2022]
  2. ‌Fellay, M. (n.d.). Council Post: Why Your Employees Are Leaving En Masse And The Surprising Factor That Will Keep Them. [online] Forbes. Available at: https://www.forbes.com/sites/forbestechcouncil/2021/07/28/why-your-employees-are-leaving-en-masse-and-the-surprising-factor-that-will-keep-them/?sh=7215a73140fb [Accessed 20 Mar. 2022]
  3. ‌Stibitz, S. (2015). How to Get a New Employee Up to Speed. [online] Harvard Business Review. Available at: https://hbr.org/2015/05/how-to-get-a-new-employee-up-to-speed. [Accessed 20 Mar. 2022]
  4. Sostrin, J. (2018). To be a great leader, you have to learn how to delegate well. [online] Harvard Business Review. Available at: https://hbr.org/2017/10/to-be-a-great-leader-you-have-to-learn-how-to-delegate-well. [Accessed 20 Mar. 2022]
  5. Xiang, D. (2021). Staff Software Engineer Responsibilities. [online] David Xiang. Available at: https://davidxiang.com/2021/01/19/staff-software-engineer-responsibilities/ [Accessed 20 Mar. 2022].

Subscribe to Another Dev's Two Cents

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe