Help Yourself and Everyone Else: Don’t be a Shrugger
What is a Shrugger?
I don’t mean the Urban Dictionary definition (it’s safe for work if you’re curious) and the word isn’t found in any reputable printed dictionary. Wiktionary simply defines it as “one who shrugs.”
I’ll illustrate what a Shrugger is with an example:
You’re working on a project with a team. As usual, this week you have a deadline to complete some tasks. It’s Monday, and you begin reviewing the task list independently. You’re surrounded by team members who are settling in for the week when you realize the task list makes no sense.
Of course, you could complete the tasks like an automaton and let the project manager take the fall for making a schedule that doesn’t make any sense… or you could do something.
You point out the issue to your nearest teammate, and they look at you with dead eyes, shrug, and fire up Excel to presumably begin completing nonsensical tasks.
THIS TEAMMATE IS A SHRUGGER.
Whatever happens to you in your career, PLEASE DON’T BECOME A SHRUGGER.
In said scenario, get ahold of the project manager immediately.
There is no reason to do work that doesn’t make sense. You might get a bit of blowback in the short term for asking a lot of questions if you’re in a place with poor workplace culture. If you can stay curious and vocal people will notice and you will eventually be rewarded with higher-level opportunities.
The skills you are displaying by just asking questions of the right people when you encounter things that don’t make sense are called “spotting opportunities” and “escalating issues” in corp-speak.
It’s also possible there is a misunderstanding on your end – maybe there is a reason the tasks are set up this way, maybe the PM knows something you don’t. It’s unlikely based on your assessment, but better to keep an open mind and communicate your questions to them objectively (definitely not a time to go busting into a call or meeting with the PM telling them their schedule is shit – be gentle but ensure you get your concerns across).
With trending terms like “Quiet Quitting” at top of mind right now, do not confuse the difference between wrangling your work-life balance and becoming a Shrugger.
Shruggers do exactly what is asked of them, even when it makes no sense. They leave others open for failure by not helping them out when they notice errors. Over time, they can even lose the ability to spot issues (if they had it at all to begin with) because they don’t care enough to look for them and just blindly charge forward.
Shrugging can also be caused by insecurity or fear, or by cultural differences, so it is important to watch for hesitancy and help those around us who might be redeemable Shruggers. These are different types of Shruggers. They are likely under internal stress from spotting issues and keeping quiet because they aren’t sure what to do or say and don’t want to be punished or judged for speaking up.
While also extremely problematic, if you spot any kind of Shrugger, do your best to help bring them along with you and end the behavior cycle. “I’m going to talk to the project manager and see if there has been a miscommunication before we dive into these tasks, would you like to come along?” They can sit silently the whole time if needed, but they’ll see that there isn’t [usually] a negative consequence for speaking up appropriately and have the opportunity to become a stronger teammate.
How I Learned about “Shrugging” at Work
I’ve been on more than one project that I realized wasn’t going to succeed even if we stayed on schedule (other people seemed aware but no one was doing anything about it yet). The first time it happened I was really rocked by it. During that time a coworker and I started using the phrase “Don’t be a Shrugger” as a sort of inside motivational phrase.
The project was a software implementation and I was a tester and data wrangler.
I didn’t have experience testing software, but from the start I had concerns. During my onboarding no one seemed to have a working version of the software. This was written off as normal, but it was really broken and we rapidly failed to meet the first phase (System Integration Testing) goals.
For a while when it was unclear due to a string of delays whether we were going to go to the next phase (User Acceptance Testing) or not I just worked on data independently, cleaning and categorizing and training my site how to generate clean data for the future. I was treading water while I waited to see what happened next. I had voiced my concerns but no one executive I’d spoken to seemed able to stop the project from rolling forward.
The company plowed forward and flew 20 superusers across the globe to participate in User Acceptance Testing anyway. It became a real problem.
The software didn’t work at all. Even properly set up, the equipment we had been provided would freeze mid-use. We could hardly get to the end of even the shortest test scripts. At least while we were all together it felt like we gained some ground and I learned a lot. I spent eight weeks travelling to the UK for the project.
While I was there, I noticed that some of the contractors arrived very late each morning (after 10am!) and left early (by 3pm!). They were friendly enough and every once in a while would make a big show of running a meeting, but I wasn’t sure what they were actually doing.
Turns out, a lot of them were just showing up and Shrugging through their work day as challenge upon challenge drowned the project. We joked that everything was becoming “workarounds” because not much worked as intended. The project rolled back one phase and they claimed they would fix the integrations, but I still had concerns.
After flying home the final time, we continued remotely. Things got quieter as the team pushed forward with what was cobbled together. People started quitting.
Every day we got more nonsensical tasks. Keep-calm-and-carry-on type shit.
The Shrugging behavior in that project cost the company I worked for millions of dollars and if the software solution we were testing had gone live, it would have tanked the company for at least a few months, stopping the flow of orders completely.
Thankfully a few of us weren’t Shruggers, and didn’t care about whether we offended anyone (we also had the luxury at the time of not being managers, so we knew we probably wouldn’t get fired for the outcome – which we knew needed to be to send the software back to the design phase).
When the project rolled back our direction we knew it wasn’t going to be good. To avoid any possibility of going live, my coworker and I made a plan to lead and execute the User Acceptance Testing schedule to a “T.” User Acceptance Testing is meant to be the final stage of testing. By this point things are supposed to function so end users can test them in real environments. A lot of times this means it is a checkbox exercise and then you quickly proceed to training and go-live.
Our sarcasm was palpable.
Software not working? No problem. It’s called testing, right?
We gathered a team of managers and trained them on the software as best we could. They saw the issues immediately. They questioned what we were doing and why we were taking their time. We told them that the only way to move forward was through – we needed to clearly and reliably demonstrate the issues and document them clearly. We also planned to use video to capture the extreme reality of the time we knew it would take to scan items into inventory with the freezing equipment, software issues, and more.
As a team we logged thousands of bugs and took videos of the broken processes in test. Project managers could no longer deny the issues when they saw our numbers in Jira, but despite them they still pressed on toward go live.
It was ominous.
It was during the most ridiculous and painful part of this project that my teammate and I started saying to each other “Don’t be a Shrugger.”
We said it every day. We said it when we saw “that look” on each other’s faces that you get when you read an email that makes no sense. We said it enough that we internalized it, and fought through the chaos, kept our jobs, and helped the company get back on track. With the right evidence gathered during software testing on video for everyone to see and the right executive’s ear, we were able to finally get the message across that the software solution WAS NOT GOING TO WORK AT ALL no matter how much busy work we all did.
In the end, it was a short video we took that made it from executive to executive showing the broken scanning process (that we could not “work around” due to the system design) that finally ended the project abruptly.
We were not executives, we weren’t even managers at the time. But we stood up for the real issues and avoided a failure at go-live.
I won’t belabor it longer. Help yourself and everyone else:
Don’t be a Shrugger.
