Organizations ignore the power of the tribe at their own peril. In our earliest primitive state, a human being had almost no chance of survival on his own. It is only as a group that we thrive. So it is no surprise that scientists believe that the primary purpose of our large sophisticated brains is social interaction - the complex glue that holds groups together. These instincts around our tribe are hardwired in our brains. They can motivate us to unparalleled levels of self-sacrifice and loyalty or drive us to irrational conflict and mistrust. There are almost no boundaries to the lengths that we will go to protect and sustain the people we consider to be a part of our tribe, and almost no depths to which we won't sink to eliminate threats from opposing tribes. It is the root of obsessional loyalty to professional sports teams, as well as murderous gang violence, and ultimately war.
It is no surprise then that organizations from the military, to sports teams, to business organizations have found ways to channel and manipulate this basic instinct. In business, leaders can use these forces to build strong organizations with sustainable competitive advantages or they can let these forces rip their organizations apart.
At a recent Agile Austin conference, no less than three different speakers emphasized the importance of maintaining long-term teams as a key to high performance in software development. Adding or removing even one member of a highly performing software development team can cause that team to revert to the initial stages of team development. The classic stages of team development - Tuckman's forming, storming, norming, and performing - take a significant amount of time to progress through. It is a careful dance to form a social hierarchy and negotiate the role of each member of the team, but once these teams truly coalesce and mature, they are capable of amazing degrees of productivity, creativity, communication, and support.
I don't believe organizations truly understand and respect the power of the team. Leaders carelessly break-up teams and move members in and out of teams depending on the project, and they undermine the cohesiveness of the team by forcing incompatible personalities onto the same team. At Apple, Steve Jobs famously pitted internal teams against each other, unleashing the destructive rivalry of enemies.
Organizations of all sizes seem to often miss this lesson. An article in the Harvard Business Review cited a study by the NTSB that over 70% of all commercial airline safety incidents occur with crews that are inexperienced in working together, and yet airlines still routinely break-up experienced crews for logistical reasons in a short-sighted effort to maximize efficiency.
An excellent example of the power of cohesive teams is the US Navy SEALS. Navy SEAL teams are legendary for their excellence and teamwork. The Navy has found that the ideal size for a team is four to five SEALS who constantly train together, sometimes for years, until they are a perfectly cohesive unit. They are expected to operate in a semi-autonomous manner and apply innovation and creativity to complete the mission. A excerpt from the SEAL ethos:
We expect to lead and be led. In the absence of orders I will take charge, lead my teammates and accomplish the mission. I lead by example in all situations. I will never quit. I persevere and thrive on adversity. My Nation expects me to be physically harder and mentally stronger than my enemies. If knocked down, I will get back up, every time. I will draw on every remaining ounce of strength to protect my teammates and to accomplish our mission. I am never out of the fight.We demand discipline. We expect innovation. The lives of my teammates and the success of our mission depend on me – my technical skill, tactical proficiency, and attention to detail. My training is never complete. We train for war and fight to win.
Based on my research and experience, I believe that the most effective way for a software organization to achieve outstanding results is to allow developers to self-form into semi-autonomous teams. I believe self-formed teams have the best chance of sustaining themselves for a long period and the best chance of forming a cohesive unit. The organization should adopt a team-centric approach as a core principle. The teams should be allowed to control its membership and given a substantial role in evaluating team member's performance. Rewards and recognition for performance should be awarded primarily to the team as a whole. The team should be given a budget for discretionary spending such training, team development, and software.
Why does a team benefit from this level of autonomy? Because, as Daniel Pink hammers home in Drive, individuals need a strong sense of autonomy to become intrinsically motivated toward a task, so this level of team autonomy facilitates that need. I believe that part of the reason for the success of Agile Scrum teams is the way in which it enables autonomy for the team. Allowing teams to self-form takes these principles to the next level.
This system doesn't preclude the possibility that the individual may choose to switch teams, again facilitating autonomy, but allowing teams to self-form naturally should minimize the desire to switch teams and maximize the chance of maintaining long-term teams.
It is tempting to ask, "Why can't we get developers to see the entire department and/or the entire company as their tribe?" Of course, to some extent, this naturally happens, especially in organizations that strive to develop a high degree of trust, and it certainly should be encouraged in order to ameliorate the natural rivalry between teams, but I believe the small subgroups that naturally form within larger groups provide much more powerful motivation and they also provide a vehicle for the autonomy necessary for intrinsic motivation.
Of course small teams are no panacea; it is imaginable that one could feel stifled by a bullying teammate, but ideally the opportunity to switch teams would make that scenario less likely and also provide incentive for all team members to behave with consideration. This approach doesn't preclude the organization from providing supporting personnel to help coach and facilitate effective team performance such as scrum masters and other process coaches, or technical advisers and trainers, but to be most effective these auxiliary services should be requested by the team.
For this substantial investment, I predict that an organization that follows this model will see even more substantial returns in terms of productivity, creativity, learning, loyalty, and satisfaction. From my personal experience of having once worked in a highly productive team, there is no professional experience that can ever really substitute.
It is no surprise then that organizations from the military, to sports teams, to business organizations have found ways to channel and manipulate this basic instinct. In business, leaders can use these forces to build strong organizations with sustainable competitive advantages or they can let these forces rip their organizations apart.
At a recent Agile Austin conference, no less than three different speakers emphasized the importance of maintaining long-term teams as a key to high performance in software development. Adding or removing even one member of a highly performing software development team can cause that team to revert to the initial stages of team development. The classic stages of team development - Tuckman's forming, storming, norming, and performing - take a significant amount of time to progress through. It is a careful dance to form a social hierarchy and negotiate the role of each member of the team, but once these teams truly coalesce and mature, they are capable of amazing degrees of productivity, creativity, communication, and support.
I don't believe organizations truly understand and respect the power of the team. Leaders carelessly break-up teams and move members in and out of teams depending on the project, and they undermine the cohesiveness of the team by forcing incompatible personalities onto the same team. At Apple, Steve Jobs famously pitted internal teams against each other, unleashing the destructive rivalry of enemies.
Organizations of all sizes seem to often miss this lesson. An article in the Harvard Business Review cited a study by the NTSB that over 70% of all commercial airline safety incidents occur with crews that are inexperienced in working together, and yet airlines still routinely break-up experienced crews for logistical reasons in a short-sighted effort to maximize efficiency.
An excellent example of the power of cohesive teams is the US Navy SEALS. Navy SEAL teams are legendary for their excellence and teamwork. The Navy has found that the ideal size for a team is four to five SEALS who constantly train together, sometimes for years, until they are a perfectly cohesive unit. They are expected to operate in a semi-autonomous manner and apply innovation and creativity to complete the mission. A excerpt from the SEAL ethos:
We expect to lead and be led. In the absence of orders I will take charge, lead my teammates and accomplish the mission. I lead by example in all situations. I will never quit. I persevere and thrive on adversity. My Nation expects me to be physically harder and mentally stronger than my enemies. If knocked down, I will get back up, every time. I will draw on every remaining ounce of strength to protect my teammates and to accomplish our mission. I am never out of the fight.We demand discipline. We expect innovation. The lives of my teammates and the success of our mission depend on me – my technical skill, tactical proficiency, and attention to detail. My training is never complete. We train for war and fight to win.
Based on my research and experience, I believe that the most effective way for a software organization to achieve outstanding results is to allow developers to self-form into semi-autonomous teams. I believe self-formed teams have the best chance of sustaining themselves for a long period and the best chance of forming a cohesive unit. The organization should adopt a team-centric approach as a core principle. The teams should be allowed to control its membership and given a substantial role in evaluating team member's performance. Rewards and recognition for performance should be awarded primarily to the team as a whole. The team should be given a budget for discretionary spending such training, team development, and software.
Why does a team benefit from this level of autonomy? Because, as Daniel Pink hammers home in Drive, individuals need a strong sense of autonomy to become intrinsically motivated toward a task, so this level of team autonomy facilitates that need. I believe that part of the reason for the success of Agile Scrum teams is the way in which it enables autonomy for the team. Allowing teams to self-form takes these principles to the next level.
This system doesn't preclude the possibility that the individual may choose to switch teams, again facilitating autonomy, but allowing teams to self-form naturally should minimize the desire to switch teams and maximize the chance of maintaining long-term teams.
It is tempting to ask, "Why can't we get developers to see the entire department and/or the entire company as their tribe?" Of course, to some extent, this naturally happens, especially in organizations that strive to develop a high degree of trust, and it certainly should be encouraged in order to ameliorate the natural rivalry between teams, but I believe the small subgroups that naturally form within larger groups provide much more powerful motivation and they also provide a vehicle for the autonomy necessary for intrinsic motivation.
Of course small teams are no panacea; it is imaginable that one could feel stifled by a bullying teammate, but ideally the opportunity to switch teams would make that scenario less likely and also provide incentive for all team members to behave with consideration. This approach doesn't preclude the organization from providing supporting personnel to help coach and facilitate effective team performance such as scrum masters and other process coaches, or technical advisers and trainers, but to be most effective these auxiliary services should be requested by the team.
For this substantial investment, I predict that an organization that follows this model will see even more substantial returns in terms of productivity, creativity, learning, loyalty, and satisfaction. From my personal experience of having once worked in a highly productive team, there is no professional experience that can ever really substitute.
This comment has been removed by the author.
ReplyDeleteExcellent article Chad, and I agree with all of your points. One way that management can gain the flexibility needed to accomplish the missions that are always changing is keeping the team as a co-located cohesive whole, but assigning them to new work, even if it's very different than what they've done before. Great teams that are performing will continue to perform and innovate while they are learning. Some will think there's a better way by breaking up the teams (oh, I really need these six persistence guys from different teams in order to ramp up quickly), but the truth is that most of the time, the cohesive team will beat out the newly forming team, even if they have better technical expertise.
ReplyDeleteSeeing the humanity behind agile is a requirement for anyone entrusted in an agile management role.