13 Signs of a Toxic Team Culture

TL; DR: 13 Signs of a Toxic Team Culture

What looked like a good idea back in the 1990ies—outsourcing, for example, software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. And yet, they still do not understand what it takes to build a decent product/engineering culture. Learn more about typical anti-patterns and are signs that the organization has a toxic team culture.

13 Signs of a Toxic Team Culture — Age of Product


The Toxic Team Culture: Internals vs. Externals

20 years ago, many large companies tagged along with Jack Welch’s philosophy of outsourcing non-core business areas — such as software development — to third parties. Today, they find it hard to compete in the war for product and engineering talent with the GAFAs and other agile and technology-focused organizations. Software is finally eating the world.

The lack of a product/engineering culture in those legacy organizations usually results in hiring numerous contractors and freelancers to get at least some projects going. Which in return often leads to some typical anti-patterns as the internals find it hard to team up with the externals:

No equality: There is a pecking order among team members. This order is not based on an individual’s contribution or capability but whether that person is on pay-role or not.

Externals to the shop floor: Externals are expected to deliver the work items. Accepting accountability and developing a sense of product ownership is regarded impeding this purpose.

Career issues: Internals focus on advancing their careers by other means than building an outstanding product, for example, by getting involved in the organization’s politics game.

Hiring minions: Internals claim the final say whom to hire and tend to use it to select submissive minions. (As the saying goes: B people hire C people.)

Lonesome decisions: Internals consider themselves responsible for the product and hence insist on making all decisions themselves—often single-handedly without involving the team or by overriding the team’s decision.

Assigning tasks: Internals dispatch work items to either externals or juniors. (It is even worse when externals accept the situation and ask internals what is the next work item for them is.)

No WiFi for you: Externals are excluded from the use of ‘internal’ infrastructure, for example, WiFi and calendar applications.


The Toxic Team Culture: Equality and Diversity

And then there are other issues beyond the internal vs. external question that might prevent a group of people that happen to be in the same place at the same time from becoming a team:

Not all developers are created equal: Merges need to be requested and are utilized as code quality stage-gates beyond a reasonable level.

Outsourcing to juniors: The senior team members consider writing tests, fixing bugs or documentation as a minor task below their pay-grade. Hence, it is outsourced to the junior team members.

Remote minions: Remote team members are not fully included, for example, they never meet the co-located team members in person.

The silent treatment: Team members are deliberately ignoring communication only to point at a later stage at a perceived lack of communication.

No diversity: The team members practically all have the same background.

Voting with their feet: The team suffers from a high fluctuation among its members.

Conclusion:

What is difficult to understand is that legacy organizations complain that they cannot hire top engineering talent. On the other side, they do not invest in making the company a great place to work for in the first place. And by “great” I am not referring to sushi chefs on the premise or sparkling water from eight different countries in the fridge.

Creating balanced, diverse teams where rank does not have privileges—that are ready and willing to accept accountability—is essential for organizations striving to build a product/engineering culture or even become agile. Their return on investment will largely depend on achieving this goal as early as possible in the transition.

What signs of a toxic team culture have you observed? Please, share with us in the comments.

✋ Do Not Miss Out: Join the 2,400-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

Join the Hands-on Agile Slack Group

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Related Articles

Download the ’Scrum Anti-Patterns Guide’ for Free

2 thoughts on “13 Signs of a Toxic Team Culture”

  1. Hi,
    Interesting issue which is not new. Creating and managing a team is a specific job and not everybody has the competencies to build a good team. You need to understand the skills needed, then you need to recruit appropriate people who have both the technology skills you need and the ability to work in a team and last you need to federate and manage the team.
    Having saying that, personally, I don’t think there are 13 signs. I think there are various signs of failing to work as a team and the signs vary.
    For example, the toxic signs in a waterfall project are not strictly the same than toxic signs in agile. There are some similar, but also some different.
    To come to the 13 signs, yes, there are toxic signs, but the ” I know everthing”, ” I decide everthing”, “I’m just a doer”, “I’m the boss, you’re the slave”, “I work alone, rather outside” , signs are also toxic, and there are many others.
    Back to the root, all what I can say is that these signs exist when the team builder failed to do his/her team building job :
    – Understand the required skills,
    – Recruit the appropriate people,
    – Federate (i.e. give a common goal that will overlap barriers like internal/external, but also business/IT, country1/country2, Web/Legacy technology and so many other barriers)

  2. In my past, I have come across few internals who raise concerns while reviewing code written by externals but do not take care of same things in their own code.
    I had the privilege of being part of a team where I was included in all important discussion though I was external. They were very accepting and supportive of my thoughts. There are very few organizations who get this way of working.

Leave a reply

Your email address will not be published. Required fields are marked *