TL; DR: 18 Signs of a Systemic Toxic Team Culture
What looked like a good idea back in the 1990ies—outsourcing software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. While they try to become more appealing to product and software developers, they still have difficulties understanding what it takes to build an attractive product/engineering culture. Learn more about typical anti-patterns and signs that an organization is causing a toxic team culture, impeding its efforts to become agile.
Update 2020-08-10: I clarified and extended some of the previous issues and added new ones.
🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.
The Toxic Team Culture: Internal Team Members vs. External Team Members
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 inherent lack of a product/engineering culture in those legacy organizations usually results in hiring numerous contractors and freelancers—software engineers, UX designers, Product Owners, agile coaches, Scrum Masters, etc.—to start at least some projects. Which, in return, often leads to some typical anti-patterns as the internal team members find it challenging to accept the external team members fully:
- 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. Typically, the internal team members occupy the spots at the top.
- Externals to the shop floor: External team members are expected to deliver the work items. Accepting responsibility and developing a sense of product ownership is regarded as impeding this purpose. (In other words: the external team members are paid to write requirement or code.)
- Career issues I: 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, seeking allies among the external team members.
- Career issues II: Internal team members press for the adoption of technology, they have a personal interest in that is not necessarily the best solution for the product. (And external team members accept this push without too much resistance, see #11.)
- Career issues III: Internal career guidelines are pushing employees into competing with each other for promotion at the expense of team cohesion and product quality.
- Hiring minions: Internal team members claim the final say whom to hire and tend to use it to select minions that get work done and do not interfere with their career ambitions, see above.
- 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.
- Tagging external team members: External team members are “tagged,” for example, by adding “ext-” at the beginning of their internal email address.
- Position yourself well with the employees: Contracts of freelancers and contractors are only extended when the internal team members agree to the prolongation. (Think about the effect of this practice on Retrospectives.)
- No access to this event: External team members are excluded from internal events relevant to the future product on the ground that they are not on the pay-role. (Despite usually having signed a non-disclosure agreement.)
Cannot see the form?
Please click here
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 with the intent to create an excellent product for the customers from becoming a team:
- No diversity: The team members practically all have the same background, and no one is trying to go the extra mile and change this.
- Not all developers are created equal: Merge requests from external team members 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, the junior team members have to accomplish those tasks.
- Remote minions: Remote team members are not fully included; for example, they never meet the co-located team members in person, not to mention that they join the co-located team members regularly, or have a decent onboarding.
- The silent treatment: Team members are deliberately ignoring communication only to point at a later stage at a perceived lack of communication.
- Voting with their feet: The team suffers from a high fluctuation among its members.
Conclusion:
What is often difficult to understand is that legacy organizations complain that they cannot hire top engineering or product talent when the problems are home-made creating a toxic team culture. 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 responsibility is essential for organizations—without them, striving to build a product/engineering culture that supports their ambition to become agile is futile. The return on investment on any agile transformation will largely depend on achieving this goal as early as possible.
What signs of a toxic team culture have you observed? Please, share with us in the comments.
📖 Related Articles
Lipstick Agile — 15 Signs You Probably Need a New Job or to Roll-up Your Proverbial Sleeves
Agile Failure Patterns in Organizations 2.0
Download the ’Scrum Anti-Patterns Guide’ for Free
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn more about a Toxic Team Culture: Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Team and Learn more about a Toxic Team Culture
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.
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.
View Comments (3)
Having been part of the 'outsource IT' movement back in 90's and early 2000's may I apologize on behalf of everyone. We thought we were being smart and thrifty. It's interesting how long effects last - 20 years later and we are still paying the price. We forgot that organizations are there for the employees, not for the shareholders.
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)
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.