If you’ve built a system that’s supposed to be reliable, you shouldn’t be up fixing it at four in the morning. You shouldn’t be getting paged at all hours. Sure, you might need to do some occasional planned after-hours maintenance, or some very occasional unplanned-but-process-driven disaster recovery, but you shouldn’t need a hero.
Man, I wish I had been able to read this post when I was still at my previous gig in IT. I would have posted this all over the office.
We had a hero — a really good hero. He’d been the hero for so long that management barely understood that there was a problem. Oh, they recognized that if our hero ever went down, we were toast. A common phrase in leadership meetings was, “If [our hero] gets hit by a bus, we’re in big trouble. We need some redundancy.”
The trouble was, our hero loved being a hero. He complained often and loudly about the crazy hours he had to work and how management made so many poor decisions, but man did he love to be the hero when it was hitting the fan.
But he wanted to be the only hero and rejected every attempt to hire on someone else to duplicate what was in his head. And documentation? Fohgeddaboutit! He was too busy being the hero.
The fact is, I loved the hero. We got along great — he was a great guy. But he couldn’t see how his actions hurt our team as a whole. Alex gets this so right in his post. If you work with a hero, do better than I did — pull him/her aside and give it to them straight.
Your team deserves it.
-
assortments liked this
-
bananacasts liked this
-
gidogeek liked this
-
chaochun liked this
-
gean liked this
-
chrisbowler posted this
