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

The last time I wrote about teamicide was in 2015, so I thought it would be interesting to revisit this topic along with examples that would resonate with today’s reader.  But before we do that, it would be helpful to understand more about where this term originated from.

What Causes Most Teams to Fail?

In 1987, Tom DeMarco and Timothy Lister published a classic book about managing the development of digital products and services, Peopleware.  For me one of the most interesting parts of this book was the insight they uncovered after studying the results of nearly 500 software projects.  For the projects that were canceled, failed to deliver or delivered a product that was never used, the principal cause of failure, according to the project leaders and participants, was attributed to ”politics”.

But assigning blame to “politics” is too easy and simplistic.  People in the 1980s were just as intelligent as people today, so DeMarco and Lister probed deeper to uncover the root cause(s) of these failures.  What they found surprised them – there was no single technological reason to explain the failures!  In fact, a more accurate description for the cause of project failure was not “politics”, but “project sociology”.  This led them to one of the most profound insights from their book:

“The major problems of systems work [software development] are not so much technological as sociological.”

So why did people from the 1980’s, and today, overlook project sociology and blame “politics” for their failures?  According to DeMarco and Lister, it is because they subscribed to the High-Tech Illusion.  The High Tech Illusion is the belief that because someone works with computers and technology, they work in a high-tech business, like nuclear fusion or quantum computing.  And as a result, project leaders and participants spend the majority of their time managing the technology.  What would yield better outcomes for the business would be to spend more time focused on interpersonal communication and interactions.  Somehow that sounds familiar . . .

What is Teamicide?

In “Peopleware,” DeMarco and Lister introduced the delightful term “teamicide” to describe all the actions and decisions managers and leaders take to kill high-performing teams.  Sadly, there are nine categories of behaviors that reduce the performance of self-organizing teams.

For each category of behaviors, I offer three examples.  The first is a common example that should be accessible to most product developers.  The second is an extreme example that pushes the boundaries…but might not appear to be so extreme in some environments.  Finally, the third example is one that appears to be reasonable and rational, but overtime inhibits team performance.

Phony deadlines

Setting dates and other targets that everyone knows are impossible.

• Common: senior leaders announce a release date for the product based on a timetable created by the marketing team.
• Extreme: after setting an impossible deadline, executive leaders distribute an email that only the top 50% of developers will keep their jobs post-release.
• Seems reasonable: assigning ambitious “stretch goals” to the team week after week regardless if they are delivered or not.

Defensive management

Creating an environment where people are afraid to make mistakes.

• Common: the tech lead heavily annotates every pull request with dogmatic comments about style or minor formatting issues.
• Extreme: after an outage, managers use the root cause analysis process to assign blame to the developer(s) responsible for the incident.
• Seems Reasonable: engineering leaders implement an updated code review process with the goal to “find more errors”, with the expectation that finding more errors demonstrates rigor and thoroughness.

Bureaucracy

Following unnecessary procedures that add no value to the final product.

• Common: everything the developers work on, even the smallest bug fix, must be entered into Jira.
• Extreme: before developers can begin working on a new user story, they must have completed a five-page design brief and received approval from all business owners impacted by the change.
• Seems reasonable: business partners and engineering leaders add new steps to the CI\CD pipeline that include manual interventions, sign-offs in different systems and a lengthy checklist, even for minor updates.

After reviewing this article, I recognized that nine categories is a lot to absorb in one sitting so I decided to break this big article into a series of three, shorter articles.  In the next article, we are going to talk about how overtime, competition and fragmentation of time disrupt team performance.