Don't (Always) Be a Hero

  • Comments posted to this topic are about the item Don't (Always) Be a Hero

  • There is nothing "heroic" about establishing yourself as a lynchpin, keeping your co-workers in the dark about how things work, and then bailing one day for a better job.

    Of course, management needs to foster that environment transparency. For example, where I work, we track most everything we do in JIRA and document the architecture of every project in Confluence. Cross-training and technical presentations are considered deliverables and show up on our list of PMP goals.

     

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • It can be a weird line here.

    At my previous job, we were moving our entire data center from one building to another. As part of it, we wanted to, just in case, get a backup of every database right before the machines were unplugged. I wasn't involved in the setup at all, but I was going to be one of the people doing the work (we did it in shifts over the weekend). I was the 3rd of 6 or 8 shifts. I get in to get briefed by the last person. I'm told:

    Here's how it works. We have a script that will back up the databases. You have 20 servers you're responsible for. Open twenty windows in SSMS, start the script on each of the twenty servers through the twenty windows, then copy & paste all the results.

    I lost my mind.

    Instead of immediately opening a bunch of windows, I sat down and worked on a Powershell script for about the first hour when I was supposed to be running backups. Give it a list of servers and it opened a threaded connection to each and ran the script, waited for all the results and put them all into a single output file. My method ran about 2-3 hours faster than the "open all the windows" approach, and it involved zero copy & paste. I handed the script to the next person, who used it successfully. It was used the rest of the weekend.

    Now, is that being a hero, or just helping out where it was pretty obvious that help was needed? I could see arguments on both sides.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • To be a "hero" means to never be able to take a proper vacation. Even if you're lucky enough to be granted permission to leave, there's always the risk of that phone call or text message ruining your relaxation.

  • Eric M Russell wrote:

    There is nothing "heroic" about establishing yourself as a lynchpin, keeping your co-workers in the dark about how things work, and then bailing one day for a better job.

    Of course, management needs to foster that environment transparency. For example, where I work, we track most everything we do in JIRA and document the architecture of every project in Confluence. Cross-training and technical presentations are considered deliverables and show up on our list of PMP goals.

    I agree, though I've seen too many people constantly be heroes when they're aren't linchpins. I think there's a lot of FOMO, either from learning or being visible to management. When I've managed incidents, sometimes the hardest thing is to get people to go home and rest because either I need them to staff an ongoing incident in 8 or 12 hours, or I need them to handle business as usual the next day.

  • cgumprich wrote:

    To be a "hero" means to never be able to take a proper vacation. Even if you're lucky enough to be granted permission to leave, there's always the risk of that phone call or text message ruining your relaxation.

    Been there, learned to not do this.

  • Grant Fritchey wrote:

    It can be a weird line here.

    ...

    Now, is that being a hero, or just helping out where it was pretty obvious that help was needed? I could see arguments on both sides.

    Can be a weird place to decide how to do this. I've scripted upgrades like this, but I've also found that depending on load, it might be quicker to pop 20 windows.

    That skill of managing 20 remote desktop connections has come in handy this year. When I work with our SEs checking VMs, I'm quicker than they are to get through 10 VMs because I parallelize my work 😉

  • Long ago when I was a young IT pro and still had that fresh out of school shine, I had dreams of an exciting IT career.  I was quickly instructed by veterans that the primary goal of my job was to make things boring.  Excitement was going to happen at times due to factors outside our control and require heroic acts, but our goal was always to make the exciting times somewhat boring.  If the atmosphere is constant chaos, somebody is doing something wrong.  The true hero is the one who makes sure heroes are rarely needed.

  • I've not met many "heros" like you've described, but I have met some. I think they like being the one that everyone depends upon, because they think it's job security.

    Rod

  • Another draw back of management seeing you as a hero is that you will be the one they dump all of the extra work on after they cut 6+ members of your team.  "You've shown that you can handle more work, so we are relying on your years of expertise..."  Or some other BS like that.

    Around 8 years ago I was part of the downsizing.  At the time I felt hurt and envied those that got to keep their jobs.  I soon learned I was one of the lucky ones.

    Now being on the other side and being the one keeping my job, I envy those let go.

    Every time I've seen someone be the 'Hero' it has bit them in the behind.

    One of the other people keeping their job had a hart attack only a couple weeks after they let the others go.  The person is home now recovering and expected to be OK, just out for awhile.

    Now was it a consistence on the timing?  Or was it the extra workload?

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    Don't fear failure, fear regret.

  • I had a job when I was 30 that involved my keeping a sleeping bag under my desk for a few months. There was a tight externally-driven deadline, the product owners underestimated the work, and it was discovered too late to bring in additional staff and get them up to speed in time for them to produce enough before deadline to have a net benefit. So we just did whatever it took to get the job done. It was a team effort by over a dozen people. The company even had lunch brought in every day so we could work through our lunch hour and gave us good bonuses. I worked there almost 10 more years and never saw another project anything like that there again. The company felt bad it happened and did everything they could to keep it from happening again. No hard feelings.

    I had a job decades later where the "process" was to constantly throw code into production and fix any messes afterward. There were a lot of messes and a lot of weekend emergency work. Management not only supported this, but was often the cause of it. I fixed that problem (after too long) by finding a new job. 🙂

    My current employer runs a disciplined ITIL shop with good functional test, load test, and UAT environments. In 6 years, I've been called outside of work hours about 3 times. Once involved almost two straight weeks of overtime. I didn't mind. It was a true emergency, not some artificial deadline or due to anything that could have been foreseen. I've been working on a bit of a crisis for the last two months but without any overtime! The customer is impatient for a solution, and I don't blame them. But my management values my health and sanity over getting things fixed quicker and is keeping any customer relations issues away from me.

    The trick is to know the difference between being a hero once in a while or constantly. The former feels good, but the latter feels abusive. Don't volunteer for abuse.

  • This was removed by the editor as SPAM

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply