Let’s see if we can pull this all together.
In recent weeks we’ve talked about teams and team dynamics. We’ve talked about the too-often perverse relationship between knowledge and certainty. We’ve talked about culture and how its self-reinforcing nature can result in appalling behavior just as it can help bring out the best in people.
Teams, as described here from time to time, are groups of people who trust each other, and are aligned to a common purpose.
Toss in some additional reflection and discussions with various correspondents over the past few weeks and it’s clear that while trust and alignment are important team-ness ingredients, they aren’t the whole recipe.
Another is interdependence. In the world of sports, members of baseball, football, and basketball teams depend on each other move-by-move to get the job done. Golfers competing in the Ryder Cup, in contrast, do root for each other, but don’t nudge the ball when nobody’s looking. Likewise tennis players in the Davis Cup who presumably don’t use mirrors to try to blind members of opposing teams from the stands.
The world of business can be even more extreme: Many companies pit members of the so-called “sales team” against each other in the quest to receive the sales incentives that only go to the top 10% of producers.
And some business leaders still buy into the old MBO (management by objectives) method of setting management goals, assuring that each manager will do whatever it takes to achieve his or her objectives whether or not it’s at the expense of other members of the “management team” trying to achieve their goals.
Does this mean the “sales team” and “management team” are only teams in scare quotes?
Not entirely, because of another ingredient of team-ness. That’s affinity – a shared sense of identity that’s independent of both trust and purpose. Independent, that is, except for a desire to beat other, competing groups.
Which gets us to culture. Shared identity can be and often is independent of trust and purpose. It’s never independent of culture.
Here in KJR-land our working definition of culture is how we do things around here. It’s the informal, unwritten rules the affinity group … the tribe … enforces far more strictly and ruthlessly than HR enforces any of what’s spelled out in the company’s policies and procedures.
Identity politics … tribalism, that is … isn’t limited to politics.
Because if it were, how would you explain soccer riots?
It’s time to connect all this theory to your work-a-day responsibilities as an IT manager.
As the golden rule of engineering is form follows function, start with what you want. I imagine that in most situations, most of the time, you want the men and women who work in your organization to accomplish important results.
Most of the time, they’ll accomplish important results more effectively as a result of teamwork than of working in isolation. So you need to encourage team-building in the trust-and-alignment sense.
But like it or not, achieving trust and alignment is hard work that requires constant, steady leadership. That’s in contrast to achieving an us vs them tribal sense of identity, complete with unwritten rules governing how we do things around here. You’ll get that in spite of your best efforts to prevent it.
What you can do, sometimes, if you’re lucky and the wind is blowing in the right direction, is to channel your employees’ natural tendency to form up into rival tribes, so tribal and team identities coincide, or at least overlap heavily.
It isn’t a perfect solution by any means. Yes, project teams that have a strong sense of tribal identity will work harder and collaborate better internally than employees assigned to a project whose sense of team identity is limited to trust and alignment to a common purpose.
But that same sense of tribal identity will make the team less likely to collaborate with other teams they think of as the them to their own us.
Is there anything you can do to limit the extent to which the tribes take over?
There is. You can keep projects short, so project-based tribes disband before their tribalism starts to dominate the cultural landscape. And, you can populate new project teams cross-functionally, redefining us and them frequently enough to break down tribal animosities faster than new ones can form.
Or, you can do what most managers seem to do: Hope for the best, complementing hope with an occasional lecture about how we’re all on the same team.
That’ll work well.
…which reminds me of the famous quotation called “Brooks Law”, from the book The Mythical Man-Month, by Fred Brooks: “adding manpower to a late project will make it later.” Fred was talking about teams and his experience in developing OS360 for IBM. My own experience in managing software development is a little different. What is the “optimal” team size. 1 person working alone can usually produce 0-5 person-days per day, depending on the skills of that person. Management must make sure that the work is well-defined enough to allow excellence by a truly talented person. There is a greater difference in programming or systems engineering talent than in any other profession. Adding another person to “help” a 5 person/day programmer will certainly slow them down. On the other hand, for an average programmer (1 person-day/day) adding a helper can elevate this 2-person team to a 3-5 person=day/day level. Forming a 3-person team will probably not gain anything, and may actually reduce the output to no better than 1 average person working alone. Obviously, it all depends on the skills of the individuals. A manager’s job is to fit the work to the team available to get maximum productivity, and it is not easy.
“Is there anything you can do to limit the extent to which the tribes take over?”
One aspect of company culture that can help with this is to make “them” the company’s competition.
So my IT project team and the Sales team are more “us,” and our competitor across the street becomes “them.”