teamicide

How to Kill Team Performance in Nine Steps (Part 3)

July 29, 20253 min
This article closes our three part series on teamicide, all the behaviors organizations take to diminish team performance. In part one, I defined teamicide, explained why it exists and gave some examples of teamicide in action.  In part two, I briefly revisited the High Tech Illusion and gave further examples of teamicide in action.  In this final installment, I will offer more examples of how teamicide plays out in development teams.

How to Recognize Teamicide

Teamicide was first defined by Tom DeMarco and Timothy Lister in their book, Peopleware.  In the book, DeMarco and Lister identified nine categories of behaviors that diminish team performance and self-organizing teams.  In my previous articles, I introduced the following categories of behaviors: phoney deadlines, defensive management, bureaucracy, overtime, competition and fragmentation of time.

For the last three categories, I will offer three examples.  The first is a common example that should be familiar to most people, the second is an extreme example (but may not be that extreme to some) and the third is an example that appears to be reasonable and rational, but negatively affects team performance.

Fake empowerment

Phony attempts at boosting morale which often have the opposite effect.
  • Common: distribute branded virtual backgrounds with phrases like, “Be the Change”, “Think Like an Owner” or “Bring Your Whole Self to Work”.
  • Extreme: assigning each person a weekly “mood score” based on an AI analysis of their Slack messages, emails and Zoom calls looking for “negative sentiment”.
  • Seems reasonable: implementing an “kudos” system that allows developers to give each other virtual high-fives for helping and mentoring one another.

Quality reduction

Forcing developers to build a substandard product using tools, or practices, known to be inappropriate for the task at hand.

  • Common: prioritizing the number of story points completed per iteration as the primary measurement of success.
  • Extreme: developers are asked to create a new product using an outdated tech stack because a senior executive used those technologies in their previous role.
  • Seems reasonable: making tool or technology choices based solely on cost without considering developer expertise and\or the long-term suitability.

Physical separation

Inhibiting the formation of team and teamwork by isolating the developers physically and\or virtually.
  • Common: people who work on closely related microservices are in different Slack channels and their only interaction is through formal, scheduled meetings.
  • Extreme: enforcing a strict facilities management policy that prevents co-located developers from sitting together.
  • Seems reasonable: creating a team of subject matter experts to solve a hard architectural problem, but they live in separate timezones that have no overlap.

Self-Organization is Fragile

We have reached the end of this series on teamicide and also the end of my series of articles on self-organization (Part I, Part II and Part III).  Thanks for taking the time to explore why self-organization is important for product development and essential for Scrum.  The benefits resulting from self-organization are enormous: increased productivity, profitability, customer satisfaction, employee engagement and quality.

However, self-organizing teams are fragile.  IME, it is very easy to pop the balloon that is self-organization.  One careless exchange of words or a poorly rolled out HR change can undermine months of effort.  I say this not to frighten you, but to encourage you to think carefully about what sort of organization you want to create and then carefully execute on that vision.  Everyone everywhere can #DoBetterScrum!