Some years ago I joined a company tech division and a manager–let’s call it Seamus–was practising management by fear.
It was a daunting but insighful experience that lasted about 5 months.
I decided to document that story and extract a series of pillars to help others confirm if they’re working in a workplace that uses management by fear–often people think breaking those pillars is ok for some greater good but I stronly disagree–I think breaking those pillars will bring talent away from the organization.
Definition
I think management by fear is a product of the fixed mindset–I am defining it as:
a management style used to achieve unopposed obedience and enforce decisions trough the chain of command. It’s a tense work relationship where any innovation or initiative might upset the manager and bring negative repercussions to the underdog labeled as a troublemaker–often many others feel uncomfortable but are afraid to speak up.
Management by fear brings employees to resign or avoid any critical thinking to prevent getting in trouble with that manager–the result is a blindsided organization.
The pillars
- PILLAR I freedom to ask questions and get a polite answer
- PILLAR II speak in front of the team not behind closed doors
- PILLAR III don’t be afraid of what you don’t know
- PILLAR IV trust and talent recognition
- PILLAR V beware of undermining to hide fear
- PILLAR VI supporting colleagues
- PILLAR VII people should not feel helpless
- PILLAR VIII having lunch should not be the best part of your job
PILLAR I
freedom to ask questions and get a polite answer
Shortly after I started I was in a meeting with 3 other developers, a director of technology and Seamus. It was meant to be an agile release planning as well as an iteration planning with no product owner–I won’t focus on the lack of process–after being briefed with the product vision I started asking questions like “How much data do we need to migrate and how many requests is this meant to support?” and “Who’s the product owner?”. Seamus gave away his discomfort changing face color from white, to red, to pompei red, to purple and shut me off saying that he was going to be the product owner and the rest of the questions were irrelevant. The shocking part was he was backed up by a director of technology sitting next to him that said something along the lines of “let’s not focus on those details” and none of the other 3 developers spoke up which made me think there was something wrong with me. I initially thought they didn’t ask questions because they knew all the answers but instead it was a symptom of inexperience, insecurity and fear.
Your team should be glad of your questions and give polite answers or get back to you, when they think the question is not relevant they should politely explain why.
PILLAR II
say things in front of the entire team not behind closed doors
Sometime Seamus would not answer your question in front of the team instead you were politely invited to go in a room alone with him so he could attack you or ask you to support him. After being in such a situation with another developer–let’s call him Luke–I walked out with him for coffee but I was unsure how much to bring up. As soon as I started talking about Seamus management style he said “I know exactly what you mean” and started unburdening. I felt relieved I could talk about a subject that everyone else was scared to talk about. I wasn’t alone anymore, Luke worked with Seamus for three months before I joined and his patience was running out, he didn’t tell me at the time but he already reported him with human resources.
Personal conversations require private meeting but you need to be able to constructively argue and confront your ideas in front of the entire team.
PILLAR III
do not be afraid of what you don’t know
The feeling I had was the company technical level was average and Seamus with an above average technical level was getting away with a mix of buzzwords and rhetoric because nobody knew what he was talking about and nobody would dare to ask in fear of sounding ignorant.
Being upfront about what you don’t know is a great attitude and it ensures everybody is on the same page. You should always receive polite answers.
PILLAR IV
trust and talent recognition
When Seamus was not in meetings he liked to micromanage, that was ineffective because driven by need to control rather then mentor and after dictating the course he would leave and never follow-up. Once I was asked to look in to a library feature and I reported back it was not implemented so he asked me to look again–I did thinking I made a mistake but came back with the same result–he then said I was wrong and that he used the feature before and I must have missed it so he decided to look in to it. Turns out the feature was not there but he came up with an impractical option to back up that he was right. When later he reported to the director about that change of plans caused by the missing feature he didn’t say who actually found the problem and took the credit for himself.
Trust should be recriprocal and its initial level should be full, based on events it can either stay that way or decrease. Giving credit to the team is good but an individual taking away credit is very demoralizing and naturally compromise trust.
PILLAR V
beware of undermining to hide fear
2 months went on and Seamus was still product owner of a product that had a real stakeholder on the floor above us that we were not allowed to talk to. When asked about our processes and when I was comparing us to other teams Seamus would cut me off saying “they don’t know what they are doing, we are the better team we are the one building the core of this product that will bring money to the company”. We weren’t all that special–Seamus was afraid to compare with another team so he created an imaginary separation.
The entire organization should be a synergy of committed and transparent individuals–undermining collegues, teams, divisions is a symptom of fear.
PILLAR VI
your peers should be supportive
Seamus was assigning us tasks to work on but we didn’t have a deployment server–we were told that our QA person a sweet girl that I’ll call Mush would have to setup the application on her machine and test it there. She felt upset because she couldn’t do her job but had to ask developers to setup the application each time she was doing testing. Seamus then said she should be writing automated tests and then we would make them pass. This lack of process and understanding was so amateurish that I spoke to another team lead to get his opinion and help–he acknowledged the problem but was not interested in being involved at all–he was fine as long as his little corner was fine.
When something concerns you your peers should be sympathetic and either help directly or point you to someone able to help you.
PILLAR VII
people should not feel helpless
Around 2 months after I started we were a team of 6: me, Luke two other junior developers and a designer. Mush resigned and I remember her crying in one of the last closed door meetings with Seamus, later she told me “I told Seamus he wasted my time here”. Two developers also resigned, if Seamus was the reason for their departure I don’t know I was scared to ask them and that’s when I decided I was going to actively do something about this. A new developer called Gerard joined to work on a part of this “project” that had no specifications–he would later tell us he was sitting there doing nothing. The other 2 junior developers were at the company for about 10 years and when speaking with them about Seasmus they agreed he was a bad manager but they said there is nothing you can do about it.
Some people will put up with anything to pay the bills and this is a problem for company culture that genuinely wants to change but can’t rely on people to speak up. Having the wrong people on the bus for too long will attract more of them and force good people off the bus.
PILLAR VIII
leaving the office and having lunch should not be the best thing about your job
The discomfort Seamus created in the team made our bond really tight a sense of comradeship. The team was regularly going out for lunch, once before in my career I had this comradeship feeling were we all agreed the lunch break was the best part of that workplace. Seamus schedule didn’t allow him to consistently have lunch and when he did he was sitting and being awkwardly silent or stare at you.
Lunch is a great part of the day to bond with your peers but when it shouldn’t feel like the only good part.
Suggestions
Set a deadline for change
I spoke with human resources about Seamus and decided to hold a little bit longer… I wasn’t sure for how long, no more then a month or two. I was curious to see where this was going in the same way you reach for a higher cliff when you are rock climbing or when you try a new recipe–you go out of your comfort zone to learn something valuable for the future. In the meantime I was setting my own goals experimenting with technologies, writing maintainable code and mentoring Luke but knowing these applications would never go live wasn’t great for morale.
Document and report the misbehaviour to human resources and if you can in front of the entire team. Start looking for other options before you do that since it’s possible you will be put in front a fire squad–set a deadline by when you either see change or leave. If your financial or personal situation doesn’t allow you to find other options try to focus on pockets of work you love. ### If change is actually coming consider waiting for it
The company was unable to take action, instead they hired a vice president that started overseeing this situations. I was asked if I would feel comfortable speaking once a week to the VP to describe the evolving situation–I did but no action was taken–the VP wanted to collect more feedback. I was asked to approach team members and see if they would feel like talking to the VP about the situation. Not everyone felt comfortable and some wanted the VP to contact them first in fear of repercussions.
The VP collected feedback from team members and put Seamus on a timebound evaluation period. It was unbearable to wait 4 more weeks but I wanted the new VP to have time she needed.
The VP genuinely reviewed Seasmus behaviour, I was very skeptical about change people behaviour in such a short time. They also reviewed Seasmus work to ensure if he was let go he wouldn’t leave a knowledge void but there was nothing worth keeping.
It’s worth seeing closure and it’s insightful to see an organization response to change. Leaving might be like watching a movie and miss the finale but if you’ve been under too much stress first take care of yourself.
Epilogue
It took about 5 months but in the end Seamus was fired, the team was scarred and mistrusting an organization that took a huge amount of time to support its employees when they most needed and colleagues only concerned with their interests.
The VP apologised to the team behind a closed door on behalf of the company. I would have preferred a transparent public announcement instead Seamus disappeared and the company moved on hiring a new development manager.
Seamus background had an average job duration between 6 to 9 months so this was not the first incident. Amazingly he had quite a few positive Linked in reviews, me and Luke joked about giving him a good review as long as he would leave. The people that were silent while Seamus was around didn’t say much, some still support him saying he was misunderstood and that the team did not support him and my fault for questioning him.
I hope the pillars will help you understand if you are working in a dysfunctional organization and take actions.
You might think you are the only one feeling uncomfortable but if you have a Seamus your colleagues are feeling like you and are probably scared to speak up.