Are you the weak link in your team?

Anne-Lise Brown
Anne-Lise Brown ↓ 8 minute read
Jan 31, 2023
Read 487 times

There’s no such thing as the perfect workplace. Or the ideal coworker. But some of us are fortunate enough to be part of teams where each member is trying their best not to be the reason why the others are miserable at work. In a previous article, we talked about what makes developers thrive at work and how happy developers are better problem solvers. Autonomy, mastery, and purpose are the key ingredients for these creative, yet analytical, innovation-driven minds to function at their peak. Knowingly or accidentally, software companies are promoting the idea of flourishing happiness among developers and are enacting the happy-productive worker thesis (Graziotin et al., 2018). But it is not always quite that simple… To get a more complex understanding, we need to explore what being unhappy at work means, and where this feeling roots. And nonetheless, what are the toxic elements that stay in the way of the developers from putting their best foot forward?

Do we want to call anyone out?

Not really.

But do we want some people to better understand their possible negative influence?

Uhm, yes, please.


Four pain areas and the type of developers that make them so painful.

The main sources of conflict fall into 4 major categories as identified by Iden & Bygstad (2017). And as if it wasn’t enough to deal with them individually, keep in mind that they are interdependent and should be managed as a collective whole in the context of the team/company. There seems to be a great need for more committed cooperation (partnership and shared knowledge) and formal coordination (communication and integrated planning).

Let me break it down for you:

1. Partnership

Software development usually implies multiple teams working on different aspects and an “us and them” situation is more than likely to appear. The little personal contact or lack thereof doesn’t really help either, nor do the different objectives, concerns, or priorities that teams, or even members of the same team, have. Partnership requires cooperation, shared goals, and trust. But this is obviously not the case in many software development projects.

  • Dear Main Character, your experience is yours and is valid. So is everybody else’s. Some people like another piece of software than you. They might have another approach to solving their problems and just because it doesn’t align with your preferences it doesn’t mean you should instantly dismiss it. Show some curiosity and try to find a common ground for collaborating.

  • Mr. Disruptive. Challenging the status quo is not inherently wrong. To a certain extent, it brings innovation and progress. But when it becomes the norm it can lead to an overall feeling of mistrust. Constant disruption can be the foundation of an ever-suspicious collective, with toxic dynamics, that ends up not being able to focus on the actual relevance of its work.


2. Shared knowledge

    When too many teams or individuals come together, there might be a concern that professionals in the various domains have inadequate insight into each other's knowledge areas. A study conducted by Caglayan & Bener (2016) stated that “the number of people a developer collaborates with is linked with increased defect induction rates”. So we get it, teamwork can be a little tricky, but it’s in everyone’s benefit to have an overall picture of the process.

    • Smarty Pants. There are some brilliant minds out there that beautifully intertwine with the fact of having some good ol’ experience on board. Yet, there’s nobody who knows it all. If a developer thinks they do… well they don’t. Someone who can’t accept feedback can quickly become a threat to the team. First, because they instill this sense of inferiority in others, and this can hinder creativity big time. Second, they create a false sense of control and the team ends up relying on one imperfect human being.

    • No willingness to learn. When resistance to learning or trying new things is not backed up with a proper reason, it can drag the team’s progress down. Inflexibility in a developer’s thinking is one sure way to go reach stagnation. In the tech world, there are new trends and technologies coming up all the time, so unless you are willing to grow and expand your skillset, you are going to represent a weak link in your team.

    ! However, we need to acknowledge the difference between someone who doesn’t want to learn new things because of inflexibility or lack of motivation, and someone who doesn’t want to waste time on trends that are not necessarily bringing value to their work. We’re not encouraging jumping from one trend to another, but the openness to introduce a new piece of stack when a specific project might benefit.


    3. Communication

      Repeat after me: We want systematic and effective communication and information flow! Communication is the greatest tool for managing all the other problematic areas when it is viewed as an opportunity to learn and understand. Active listening and answering assertively, not with superiority, can go a long way.

      • Better than. Behaving with superiority might feel good for a second, but it has a great negative impact on the rest of the group, discourages colleagues to speak up, and leads to the opposite type of behavior, equally dysfunctional for the team:

      • Mouth shut. Speaking up or communicating the issues that appear at work is detrimental to the team’s progress and well-being. Piling up resentment will only bring more negative feelings. Non-communication can be deadly to a project, this is why it is important to build an environment based on trust and respect.


      4. Integrated planning

        This particular area identified by the study refers mostly to the need for a properly planned collaboration between the IT operations personnel and the developers. The bad timing of their involvement in different processes leads to delays, conflict, and extra effort. “One aspect in relation to handover is that the responsibilities of developers and IT operations staff are not sufficiently defined [...] The technical concerns of IT operations should be addressed early in the project, and operational requirements and service level agreements (SLA) need to be discussed and planned for.”


        Besides the fact that it is useful for developers to identify these behaviors not just in others, but in themselves too, in order to create a more pleasant working environment, how else can we benefit from this piece of information?

        That is a good question, thank you! (And yes, I am the one who asked as well)

        Toxic attitudes and behaviors at work are major contributors to the unhappiness of developers and are the starting point for a few undesirable consequences, that Graziotin et al. (2018) grouped into internal and external consequences.

        1. Internal Consequences—Developer’s Own Being

          These consequences “alter the self rather than merely being situated within the person”. They are not states of being of an individual but represent feelings and thoughts professionals could have while developing software, as a response to the tension and unhappiness they experience at work.

          The most significant are:

          • low cognitive performance: “the negative feelings lead to not thinking things through as clearly as I would have if the feeling of frustration was not present”; “Getting frustrated and sloppy”.

          • mental unease or disorder - these are not to play with, they can threaten the mental health of an individual: feeling of anxiety: “These kinds of situations make me feel panicky”; stress: “[. . . ] only reason of my failure due of burnout”; self-doubt: “If I feel particularly lost on a certain task, I may sometimes begin to question my overall ability to be a good programmer”; and sadness and depression “feels like a black fog of depression surrounds you and the project”

          • low motivation: “[the unhappiness] has left me feeling very stupid and as a result, I have no leadership skills, no desire to participate and feel like I’m being forced to code to live as a kind of punishment”, or “Also, I’m working at a really slow pace [. . . ] because I’m just not as engaged with the work”.

          • work withdrawal: “[. . . ] you spend like 2 hours investigating on Google for a similar issue and how it was resolved, you find nothing, desperation kicks in. It clouds your mind and you need to do other things to clear it”, or even considering quitting developing software, “I really start to doubt myself and question whether I’m fit to be a software developer in the first place”

          2. External Consequences:

          • Process Consequences: this category collects those unhappiness consequences that are related to a software development process or set of practices that are not explicitly tied up to an artifact. This looks something like low productivity, glitches in communication, disorganization, and compromise in terms of actions, in order to just get rid of tasks (“In these instances, my development tended towards immediate and quick ’ugly’ solutions”).

          • Artifact-oriented Consequences: these are directly related to a development product, e.g., software code, requirements, and working with it. Low code quality represents an important such consequence and developers reported that “eventually [due to negative experiences], code quality cannot be assured. So this will make my code messy and more bugs can be found in it”. Discharging code is at the extreme end of this section and deleting the entire project because of anger or frustration is not as rare as we might think.


          You probably had an intuition from the very start that someone bringing bad vibes at work is not ideal for the team. But now it’s backed up with science! So you have all the more reason to show up at work as your most assertive self and expect others around you to behave professionally and in a manner that lifts up the team instead of dragging it down. Find out the pain points in your team and try to work them out together with the management team, putting in place strategies that are effective for your team’s particular working style.

          And, hey!, if you identified yourself in some of the toxic little categories above, I am proud of you! It means that your self-awareness brought you one step closer to fixing some bugs in your behavior. Cheers!


          • Graziotin, D., Fagerholm, F., Wang, X., & Abrahamsson, P. (2018). What happens when software developers are (un)happy . Journal of Systems and Software, 140, 32-47.
          • J. Iden, B. Bygstad, 2017. The social interaction of developers and IT operations staff in software development projects, Int. J. Proj.Manag.
          • Bora Cüaglayan, Aysüe Basüar Bener, Effect of Developer Collaboration Activity on Software Quality In Two Large Scale Projects, The Journal of Systems & Software (2016)

          Introducing the developer’s

          Sign up to our newsletter and you will receive periodic updates of new blog posts, contests, events and job opportunities.