Old brick wall in a background image
How to Kill Team Performance in Nine Steps (Part 2)
Welcome to the second part of my three part series on teamicide, identifying all the behaviors organizations take to diminish team performance. In the previous article, I shared that the most common cause of team failure was not politics, but the failure to manage the various social factors associated with product development.
That oversight is driven by the High Tech Illusion, the belief that the biggest risk in product development is managing the technology not the human interactions. What drives the High Tech Illusion? Unspoken assumptions about employee behavior that are embedded within the business’s organizational design choices. As you read about these categories of behavior, take a moment to consider what type of environment is created for product developers who work under these conditions.
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 degrade team performance and self-organizing teams. In the first part of this series, I introduced the first three categories of behaviors: phoney deadlines, defensive management and bureaucracy.
For the next 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.
Overtime
- Common: scheduling routine team meetings outside normal working hours.
- Extreme: while executives are trying to acquire additional funding from investors, they implement a six-month “no time off” policy to stabilize the product.
- Seems reasonable: offering public praise and recognition to team members who sacrifice personal time with families in order to meet arbitrary deadlines.
Competition
- Common: only the top 5% of developers receive annual bonuses.
- Extreme: developing real-time, public dashboards to rank each developer by number of commits, task throughput, number of tickets resolved and bug count.
- Seems reasonable: performance reviews are based solely on an individual’s contributions to features completed, commits and number of reported bugs.
Fragmentation of time
- Common: developers are frequently pulled into ad-hoc calls and other urgent requests for issues that are not directly related to their current work.
- Extreme: developers assigned to multiple projects receive conflicting demands from different project managers (or Product Owners) throughout the day.
- Seems reasonable: the ticketing system alerts developers the moment a new ticket is assigned to them with the implicit expectation of immediate attention.
