Peck, peck, peck

October 26th, 2011
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.  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.

This assertion rests on tired analogies from sports or the animal kingdom.

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. Maybe.

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 manager 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.

Rarely, 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.

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 your thinking about rewards 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.

13 Comments

  1. Laura says:

    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.

    • Esther Derby says:

      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.

  2. [...] blog post talks about how there is supposedly a “pecking order” in project teams.Esther [...]

  3. Jason says:

    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?

    • Esther Derby says:

      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.

  4. YvesHanoulle says:

    very recognisable.
    I even see companies doing this at team or department level.
    y

  5. 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)

    • Esther Derby says:

      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?

  6. (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.

  7. 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.

    • Esther Derby says:

      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.

  8. Developmental psychologists provide quite an interesting perspective: Most of them agree that what differentiates people is mostly what they call their internal “action logic” – how they interpret events, or make meaning.

    In a HBR article – http://hbr.org/2005/04/seven-transformations-of-leadership/ar/1 – David Rooke and William R. Torbert identified and described seven action logics. Now, it’s important to note that we should not think of action logics as little boxes to put people in. Rather, they are more akin to successive life stations people go through as they mature. They’re not enduring characteristics such as being right-handed or left-handed.

    As per the action logics description, the person who made the assertion at your workshop might come from either a Diplomat or Expert action logic. People coming from a Diplomatic action logic typically observe protocol, obey group norm, and work to group standard while people coming from an Expert action logic tend to regard the self referential logic of their own belief system as the only valid way of thinking.

    My hunch is that the person came rather from an Expert action logic, otherwise he or she wouldn’t have made the declaration in public in the first place. The HBR article also reveals that a lot of software engineers are coming from an Expert action logic.

    Anyway, I believe there is value for managers and coaches in being aware of these various action logics to get a better feeling and understanding of where people on a team are coming from.

Leave a Reply

Contact Me

Phone me: +1 612.239.1214

Email me: esther@estherderby.com

Search this site

Sign up for my newsletter

Sign up for my newsletter. I will send you updates about my public workshops, information about human and organizational dynamics, and articles that I think you will find useful.
* Email
 First Name
 Last Name
  * = Required Field
 

Follow My Updates on LinkedIn

Archives