Toxicity at Work
The Start of Toxic Traits
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
This will be a particularly difficult article to write, not only because I intend to share some stories from when I was a junior developer but also because I am lucky enough to work in an environment where I don’t need to manage toxicity that much. This means I am lucky not to handle in a day to day basis the majority of topics below. But my past helped to identify the kinds of toxicity that can destroy the working culture and my goal is to share some ideas on how to mitigate or handle those toxic behaviors.
Note the articles written about this topic are much more victim-centric. Which they should be. However, I would like to create a note and ask you, the reader, if you watched any toxic behaviors at work, to please take action. Hopefully, this article will help you to address the situation by providing you with tools and strategies to handle difficult situations.
Since the topic is so complex, it will be divided into multiple articles to allow the breathing room and attention that it deserves. This topic will be written in the current format:
Hard-core toxic stuff
Soft toxic behaviors
The tools to address (Addressed in a future article)
What you can do as a colleague (Addressed in a future article)
Hard-core toxic stuff
Early on in my career, I started to venture into the world of J2EE development. In other words, for the people out there who don’t speak Jedi language, I was a Java developer for Web-based enterprise solutions. The company has secured a project in the public sector and we were creating the system from the bottom up. With me, there was a series of experienced developers, managers, and of course, the juniors with whom I was included.
The work culture there was intense. You were supposed to stay long hours and there was a clear division between seniors, mediors, and juniors. One of the juniors, a female developer (let’s call her Miss. J), was having a hard time with the project. Back then I didn’t have experience in identifying the root cause, but asking for help in that project was not an easy thing to do. Especially for asking senior developers’ time and attention to have someone explain the project and the tasks. For some reason, even though I was a junior, other juniors were asking me questions during lunchtime, in a somehow low-profile manner. There was a culture in which someone couldn’t be seen having a problem and be helped since there was a strong competition mentality inside the team.
For this particular example, I ended up sitting next to Miss J. and I tried to explain what she was doing wrong. This became notoriously visible, that even I was mocked during some of my attempts to help her. Sitting between us, there was a senior developer (Mr. N) who was a difficult person to manage. I barely spoke with Mr. N. Even if I was sitting next to him, I avoided as much contact as possible. Mr. N had the ambition to grow in the project, and he had the technical expertise and influence to do so, but he was a jerk.
The episode that struck my memory even after 20 years, was the moment Miss J. was being corrected by Mr. N. In a way that seemed aggressive and patronizing, that became offensive even to watch. Mr. N almost accused Miss J. of stupidity and the poor girl didn’t manage to hold back her tears and started visibly crying in the open space. She left for the bathroom to compose herself, and in the open space, everything was going like nothing just happened. Mr. N’s behavior was acceptable in that work culture, and I never saw him be corrected by anyone whatsoever.
In this example, we have several problems: Lack of cooperative culture, lack of empowerment by even penalizing me for helping, and what is today seen as bullying. I was very young and “toxic environment” was not in the vocabulary back then, or at least I wasn’t aware. So I didn’t have any tools at my disposal to help me handle this kind of event. This example can be used as a retrospective and we can work together on identifying the tools to address such examples.
In terms of today’s experience and that situation that happened under my leadership, I would have hoped I had notified the behaviors of Mr. N. For someone to behave like a jerk in a way that put someone into tears, there were smaller negative behaviors before that event. By correcting and addressing the small behaviors beforehand, we could avoid a big no-go behavior later on like disrespectfully correcting someone in the workplace. Mr. N was comfortable behaving as he did because nobody said anything about minor offenses.
Another important point as a Leader is having someone with the ability to become influential in the project but lacking the intra-personal skills. Having someone in the team who is potentially offensive, and allows that person to become more influential, will contribute heavily to turn-over. Some leaders might need to make a difficult decision: Firing the problematic engineer despite the technical expertise, or embracing and managing some not positive behaviors. On a personal note, I would not be comfortable in managing a jerk, so for me, the decision is obvious.
Soft toxic behaviors
Other examples of soft toxicity, if we can refer to it like that, are examples of gossip on both a professional and personal level; finger-pointing every time something goes wrong in the project; leaders doing some level of micromanagement; stealing the credit for ideas and executions; etc.
Examples of gossip that can be harmful, are any form of comments that can degrade the person, simply by mocking or accusing something without any facts. Some examples of these behaviors can look like grown-ups behaving like teenagers. As Leaders, we might fall into culprits easily without realizing it, because it can occur in a casual conversation while having coffee or at the end of a meeting. An easy example is when we have a colleague, who lacks personal skills and has issues integrating the team, becoming a source of jokes. Or spreading rumors that Mr. X and Miss. Y are becoming closer at a personal level, or even when someone is searching for allies inside the team against a colleague in particular.
For these examples, the first step is to create awareness. We are all responsible for creating a good working environment. If we watch a somehow with less positive behavior we can just dismiss the comment or even correct the person by asking for more facts or evidence. The goal is not to promote and reward in any form some dubious behavior.
As a leader, you could be a victim as well. Note that a leader typically needs to make the hard decisions, and is ultimately responsible if a project goes south. Therefore is normal to have a certain degree of performance expectation to any team members. The leader should make everyone accountable for their performance and reward accordingly. If a team member is below the expected level, that person might rally the team against the leader as a defensive maneuver to try to find allies. In these scenarios, don’t take it too personally because is not you (the person) who is being targeted, but your role inside the project. If the project rewards good performances and feedback, any attempt to rally against a leader will be received with a grain of salt inside the team. Some team members might even be uncomfortable with some comments against the leader, especially when it becomes apparent if that team member has performance issues inside the project.
Another example is finger-pointing, which can be a reflection of a bad working environment. Here people will be especially afraid to make mistakes and possibly avoid any risky work items or tasks related to the project. The leadership has a direct responsibility to manage this kind of environment. If something goes wrong in the project or task, the first mentality is to fix the problem at hand, and in a later stage, make a constructive retrospective of what happened. People will more easily make mistakes if they are working on weak processes, or working with tools that are not ideal for the task at hand. A good process can prevent errors from happening, even if handled by less motivated and skilled engineers. Having strong processes provides a positive environment or a net, for allowing controlled errors by identifying them early and providing some room for the engineer to improve. However, strong processes don’t necessarily mean bureaucratic or heavy in nature. An example of a good lightweight strong process is the code review. Since it allows the engineers to learn from different approaches, have a different take while handling a problem, or simply avoid mistakes that can hurt the project later on.
Micromanagement can be a curse that a leader might cast on the team. These cases typically come from a place of insecureness, where the leader sees him or herself as the expert on the matter and is afraid to lose control of a process or project. On which the leader has secured the position inside the company and the interpretation is if the task is delegated to someone else, the leader can be closer to be fired or lose the influence inside the company somehow.
Another form of micromanaging is the leader being always on top of the people executing the work to make sure everything is working as expected. Both of the cases will wear out the team and turnover will be inevitable.
The first example of micromanagement above can be arguably a case where an expert was promoted due to the expertise in the project but is not leading at all. Companies should normalize the step down of a leader by offering two types of career paths: One for leadership and another for experts. Seasoned companies can offer the leader the possibility to change career paths, since not everyone wants to tackle the burden of leadership and only wants to become the expert on the matter they are working on and not handle the human part of the equation.
Finally, the stealing of credit for somebody’s work can be detrimental to an empowering work environment. Clearly. This can be difficult to manage, especially when ideas are thrown onto the table and the leader might not be in the conversation when those ideas appear or when they are executed. Some colleagues might steal the authorship while having a conversation in private with the leader, creating the illusion that a person is doing the job. Be mindful that the messenger and the one doing the work can be separate individuals, and for complex tasks, the person working on the topic might not have the time (and focus) to deal in private conversations with the leader during the execution. Especially when the work involves highly focused moments, like coding. If in a project many people are working, but one person is communicating with you all the time, this can be a sign that the messenger is not contributing that much to the code base, and is taking somehow the credit for the success of a team-based effort. Be mindful that this happens, a lot.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur