TwitterDon’t be a hero by Alex Payne
Every team I’ve ever worked on has had a hero. You’ve probably worked with one too: the guy or gal eager and willing to pull all-nighters, work weekends, and take over on-call duty when nobody else wants to.
Heroes of this type do exist in most of the workplaces. I myself has seen plenty of heroes at the place I work. The sad part about this is that while heroes provide a feel good factor to managers because they are able to complete their work in a crunch situation, they hide away the real cause of the problem which occurs in the first place.
If you’ve built a system that’s supposed to be reliable, you shouldn’t be up fixing it at four in the morning.
These problems are about improper estimation of the time, tools and techniques used or the design. But since in the end, everyone or at least the management is happy that the project was completed even under a pressure situation, the cycle continues with the next project. Heroes will continue to exist as management gets impressed with such results. Good software development just gets thrown out of the window.
A hero will burn out eventually because his work/life balance and health will be affected. If we continue to be a hero consistently, then management and co workers tend to rely on the hero for bailing them out of every troublesome situation. This does not create a good work environment for any of those involved in the project.
The post rightly mentions that the managers have to take the initiative to know that something is quite wrong if a hero is being created. That hero can be turned into a real hero in the project development if his motivation is channelled properly.
Related Posts:
Tags: today's read
Frank Silbermann (2)
Abhishek (1)
Asim (1)
Igor Popov (1)
ManiKanta (1)