A participant in one of my workshops of my workshops declared that in every team there is pecking order….and every one knows what the order is from one to n. Peck, peck, peck. Since this is the case, he reasoned, it follows that ranking people in organizations is a reasonable management practice.
This is not the first time I have heard this assertion.
It often comes up when I talk about performance reviews, annual evaluations, and the harm done by stack ranking.
Software Teams Are Not Flocks
I’m not buying it.
Software development teams are not “just like” sports teams. Software development teams aren’t packs, pods, herds, clowders, flocks or clutches. Groups of people developing software are people in goal oriented social units–often in teams.
Sometimes, on some teams, it appears that there is one person who is obviously the star.
In some companies, smart talk substitutes for action. So is the smartest talker the best on a team?
Some times there is a self-proclaimed genius who writes code that is so brilliantly complex that other people struggle to understand it. How does that make him the star? He is making it harder for everyone else to do work.
Then there are the people whose managers declare are top performers (though the basis of their assessment isn’t clear)–even though colleagues and peers view them no more than average, brown-nosers or a hindrance.
I observed a team where one person was viewed as the star by many managers. To those managers, Joan (not her real name) looked like the one who generated ideas and figured out problems. From inside the team, Joan, suppressed contributions from other people through aggressive interruption, belittling others’ ideas, and arguing until people caved in because it wasn’t worth the fight.
Consider Multiple Dimensions
There are people who are real standouts. But not on every team.
What about the people at the bottom? What is the basis of the assessment? Does the assessment include all of the dimensions of performance? In most cases it does not– it might include one dimension, perhaps coding. But in collaborative work, that is not the only thing that matters. Some times a person with relatively weaker coding skills contributes in other important ways. He or she may excel at synthesizing information, seeing the software from a customer’s perspective, creating an environment where every one on the team can be more effective.
And the people in the middle? People who ascribe to the pecking order view believe that all of the members of a team could be lined up in rank order. But what is the earthly good of that? What is the basis of the comparison? Does it included the breadth of contribution or just one aspect of performance?
What if people are measurably different on some dimension? Software is a collaborative endeavor. What matters is how well the team is doing. Spending time teasing out relative contribution or trying to discern the pecking order does not aid in team performance, and can cause real harm.
Productivity, Not Pecking
As a manager, don’t waste your time trying to figure out the pecking order. Do everything you can to help the team, as a goal oriented social unit, perform to its full capability. Treat the true stand outs as exceptions. Promote them, or find other ways to reward them (don’t limit yourself to money). Treat the people whose performance is obviously below par as exceptions, too. Either get them them help so they can contribute, or get them to a place where they can contribute (which may not be your company). It is extremely difficult to assess relative contribution to collaborative work. The effort is not worth the benefit, and the downsides are significant. So skip it. And get on with helping the team.
William Muir, a researcher at Purdue University, experimented with increasing productivity (as measured by eggs produced) in chickens flocks. He put together a flock of average chickens and a flock of highly productive chickens. Guess what happened?
I would love to print this out and leave it on a few people’s desks. Sigh.
In addition to your points, another thing that comes to mind is it seems to me that most software engineers are relatively quiet, introverted types who don’t promote themselves or reach out to others from a social angle very much. I am speaking generally, not inclusive of all SW engineers. If a person’s “rank” is weighted by social interaction or interpersonal skills, again as you mention above, harm is done. This time by way of potentially blocking interaction from a key player who may feel slighted or even invisible. I have seen younger devs especially experience this.
I have also seen flagrant suck-ups who promote the pecking order system. Not sure where I got this, because my parents aren’t like this, but you will never see me giving a Happy Boss’s Day card or giving them gifts when I get back from vacation. On purpose. Any compliments, raises, promotions, etc will be the result of consistently high quality, high integrity output on my part.
I wish I could say we don’t have this issue where I work. People have to want to change mindsets. More than that, they have to realize there is an issue or problem that needs to be changed. Until the realization and desire to improve happen, an organization & it’s employees are stuck in a broken paradigm.
Sigh.
I’ve seen the same sort of thing. An obvious pecking order is a sign there is a serious problem.
As coaches and managers, we need to pay attention how we amplify difference on a team. Some differences make a positive difference–but emphasizing status difference in the way you describe seldom leads to effective team work and excellent results.
There’s also the issue of expertise in a subject matter.
Depending on the topic, people will defer to a different person. Even when the team has a great dynamic, and everything is working perfectly, there will be 3 people who are top dog when the topic is testing, three others for security, and yet another three for localization.
So what’s your pecking order now?
There’s nothing wrong with deferring to expertise…unless the deference is enforced or it limits other team members from contributing, learning, and growing their skills. In a well-functioning team, people make the best use they can of all the expertise in the team–which isn’t a pecking order at all.
I do see groups where people defer to faux expertise because status differences are amplified. Might be years with the company, expertise by repeated assertion, dominating personality, academic background or some other mechanism. And that doesn’t serve anyone.
very recognisable.
I even see companies doing this at team or department level.
y
Is it a pecking order the pattern and dismantling practices appropriate when 80%+ of the communication from the manager is between them and a right-hand-man? (pattern, not gender)
Well, it is an odd pattern. Seems like it would create a power difference, especially if the “right hand man” is also a contributor on the team. What effects are you seeing from this pattern?
(I published this also in http://softwarefromnorth.blogspot.com/2011/10/pecking-order-and-crane-flogs.html, might be easier to read)
Even though you say that software teams aren’t like sport teams or flocks, I want to share a view from one ice-hockey coach, Hannu Aravirta. He described his management style to be flying in V-formation, like flock of cranes. The person who is in the front of the formation is changed regularly to give breathing time for everyone. Even though in ice-hockey team (in this case, national team of Finland) there is a formal ranking given by the organization, everyone will take turns in the front of the flock. And everyone must lead the flock in the same direction.
In real world, the rotation is not random, though. The stronger birds might be in the front for a longer time (I’m not sure if this is true). This happens also in the context of software development. The flock, or team, will face variety of problems and issues. Some of those are technical, some are business related, and so on. So it should be the person who has the best capabilities to resolve the current issue who is in front of the flock, giving the direction where to go.
Like all analogies, this isn’t complete. It gives an impression that the current leader of the flock will make all decisions alone, which is not the case.
Thank you for your response. I don’t have any definitive effects beyond the feelings that outside a chain of delegation, it feels like communication will further defines a pecking order, with similar effects. In arbitrary terms I have been wondering if it (or how) qualifies as a teamwork anti-pattern or teamwork-smell.
It doesn’t seem like it would be very helpful. If nothing else, it creates the perception of a special relationship. From there its easy for people to project all sorts of motivations and interpretations onto actions and utterances.
Spot on.