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.
📅 Join the 25th Hands-on Agile meetup on August 20, 2020, to explore the virtual Ecocycle Planning.
Do you want to get this article in your inbox? Then sign up for the Food for Agile Thought newsletter and join 26k 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.
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.
✋ Do Not Miss Out: Join the 7,900-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.