I really enjoyed reading this article in large part because I have been preaching 'anti-hero' stance for quite a while in favor of consistent stability. I see two big consequences to hero culture in IT.
1. People will develop unrealistic expectations of you. The more you exceed expectations, the more they will increase until eventually you will break, physically, mentally or both
2. You will develop unrealistic expectations of others. Listen, there's a reason you're a top performer. Not everyone around you is though. The only guarantee that comes from holding everyone to your high standards is disappointment
If the era of individual heroes belonged to the past, the present, with its multitude of stars, is about collective heroism. Without a team, it's nearly impossible for an individual to handle the surge of peak traffic or manage the foundational technical architecture.
From experience, the higher the engineering requirements of a project, the more challenging it becomes to use agile development. Why is that?
Higher engineering requirements mean increased complexity. Take our project as an example. In a web project, many planned features require cutting-edge technology, most of which we have little experience with.
Fortunately, our technical star quickly understood the new technology, wrote some code, and established a perfect process for others to follow.
Without him, the team would struggle with the technology and would not be able to make early decisions as encouraged by agile development.
We have witnessed many project failures due to excessive engineering demands.
In such cases, if you don't have an experienced architect, do not use agile.
Good starting for why heroism is bad for you, as an engineer, but it's even worse for the company:
* Any overtime is an extra cost for the company, even if they don't pay extra hours. The recovery alone, the time of low productivity, is money lost, but also sick time, departure, burnout. OT should never be normal. It's a sign of very bad management.
* Heroism is often characterized by less team communication, less review by peers, and an abandon of standards of quality and process. This lead directly to a technical and knowledge debt for the project, which will have to be paid later.
* Heroism is almost always done in stressing and overwhelming situations, which are very rarely where we do our best job. So, they are more likely to introduce bugs, design oversights, and people just taking shortcuts. Overall, you get a lower quality work than you can expect by your staff.
* Heroism is too often celebrate to the detriment of smart work. It makes for better stories to tell our entourage, and encourages people to not change their habits and create not only expectations on crunch, but also a belief that those are inevitable, and nothing you can do could change it. People causing the crisis refuse to take responsibility of it. People doing smart work feel ignored and quit. At its worst, heroism will beg for crisis and create them to justify itself.
I past the last 15y in the game industry, and I've seen heroism there more than anywhere else. As CTO, I found the hard way how this is part of our culture and as such, very difficult to change. It needs to change on all levels: engineering, management, leadership, investment and even in media. It's, at the end, everyone's responsibilities.
Very well written, I would add that coming up with repeatable procedures for any task that team cares about is a huge plus. It helps teams in two ways, first it keeps the procedures/playbooks documented and same for everyone and it also protects teams from occasional political interference from uninformed leaders.
Thanks for your kind words Sreedhar! Yes, definitely, documenting the “how” behind how you did something, can really speed up the process when you need to do it the second time.
It’s a good practice in freelance work as well, when you do work for a client and then similar work for another client in the future.
Very well written, Gregor! There is an internal memo I came across when working at Google called “No Heroes” that is along similar lines as this article. It encourages employees to let a system fail rather than continually bandaging it with acts of heroism, since letting it fail will help get the attention of the people who can allocate more resources towards fixing the root cause behind a system that is prone to failure. This is a more sustainable solution, and a better one for both the company and its employees in the long run.
I really enjoyed reading this article in large part because I have been preaching 'anti-hero' stance for quite a while in favor of consistent stability. I see two big consequences to hero culture in IT.
1. People will develop unrealistic expectations of you. The more you exceed expectations, the more they will increase until eventually you will break, physically, mentally or both
2. You will develop unrealistic expectations of others. Listen, there's a reason you're a top performer. Not everyone around you is though. The only guarantee that comes from holding everyone to your high standards is disappointment
Thanks a lot Khal! Glad the article resonated. These are 2 really good points, thanks for bringing them up!
If the era of individual heroes belonged to the past, the present, with its multitude of stars, is about collective heroism. Without a team, it's nearly impossible for an individual to handle the surge of peak traffic or manage the foundational technical architecture.
From experience, the higher the engineering requirements of a project, the more challenging it becomes to use agile development. Why is that?
Higher engineering requirements mean increased complexity. Take our project as an example. In a web project, many planned features require cutting-edge technology, most of which we have little experience with.
Fortunately, our technical star quickly understood the new technology, wrote some code, and established a perfect process for others to follow.
Without him, the team would struggle with the technology and would not be able to make early decisions as encouraged by agile development.
We have witnessed many project failures due to excessive engineering demands.
In such cases, if you don't have an experienced architect, do not use agile.
Good starting for why heroism is bad for you, as an engineer, but it's even worse for the company:
* Any overtime is an extra cost for the company, even if they don't pay extra hours. The recovery alone, the time of low productivity, is money lost, but also sick time, departure, burnout. OT should never be normal. It's a sign of very bad management.
* Heroism is often characterized by less team communication, less review by peers, and an abandon of standards of quality and process. This lead directly to a technical and knowledge debt for the project, which will have to be paid later.
* Heroism is almost always done in stressing and overwhelming situations, which are very rarely where we do our best job. So, they are more likely to introduce bugs, design oversights, and people just taking shortcuts. Overall, you get a lower quality work than you can expect by your staff.
* Heroism is too often celebrate to the detriment of smart work. It makes for better stories to tell our entourage, and encourages people to not change their habits and create not only expectations on crunch, but also a belief that those are inevitable, and nothing you can do could change it. People causing the crisis refuse to take responsibility of it. People doing smart work feel ignored and quit. At its worst, heroism will beg for crisis and create them to justify itself.
I past the last 15y in the game industry, and I've seen heroism there more than anywhere else. As CTO, I found the hard way how this is part of our culture and as such, very difficult to change. It needs to change on all levels: engineering, management, leadership, investment and even in media. It's, at the end, everyone's responsibilities.
Thanks for this great additions Fabien! Very good reasons why heroism is not the way to go. Appreciate your insights!
Very well written, I would add that coming up with repeatable procedures for any task that team cares about is a huge plus. It helps teams in two ways, first it keeps the procedures/playbooks documented and same for everyone and it also protects teams from occasional political interference from uninformed leaders.
Thanks for your kind words Sreedhar! Yes, definitely, documenting the “how” behind how you did something, can really speed up the process when you need to do it the second time.
It’s a good practice in freelance work as well, when you do work for a client and then similar work for another client in the future.
Very well written, Gregor! There is an internal memo I came across when working at Google called “No Heroes” that is along similar lines as this article. It encourages employees to let a system fail rather than continually bandaging it with acts of heroism, since letting it fail will help get the attention of the people who can allocate more resources towards fixing the root cause behind a system that is prone to failure. This is a more sustainable solution, and a better one for both the company and its employees in the long run.