Team players and MVPs

Team players (yes, these two are mine...)

What are the qualities you look for in a “team player”? Respect? Experience? Competence? Levelheadedness? A great personality?

When I hear people use the phrase, I confess I don’t know what they really mean. That is, I know it is a common phrase, but I wonder if people give the jargon any thought.

Sometimes it seems people use the words when they really just wants someone else to change… as in “he/she is not a very good team player”. Yet they offer no (or little) direction on precisely how to become one.

Have you ever met a “team player” you didn’t like to work with? Have you ever seen the term “team player” used in quotes, besides in this post? Ever?

Putting the jargon aside, who do you want on your teams?

Standardization, commonality and best practices

Every project includes some fundamental tasks. Sometimes they are repeatable, even mechanical, and you can train people to do them. You can often anticipate contingencies, and you can teach people to recognize them and act appropriately when they arise.

To that extent, you can train people and substitute them into teams as backups or replacements. So we cross-train on each others’ jobs to provide backup for people to go on vacations. We define standard practices and “best practices” and teach them to people to drop our costs of repeating the same tasks over and again.

Now, the last thing we need is somebody on the team who messes up our routines every day. The person who habitually “breaks the build” or who fails to write unit tests forces his teammates to bear added costs to keep everything running smoothly, until eventually we start to wonder how we can get those people off our team.

So the factors that help us work together in standard practices are one thing that makes us good “team players”.

But that is not the end of the story…

Marginal utility in the team

Not everybody takes the tiller

This post is the fourth in the principles of economics in software development series. We are pausing for a time on the third of Greg Mankiw’s principles, which says “rational people think at the margin“.

Last week I wrote about the implications of this principle on the value of our work (and our salaries). As an illustration, I suggested the difference between the professional basketball player’s income and the amateur’s income might come down to four extra baskets per game.

They’re paid all the extra money because of the incremental points they score.

Now, nobody asked them to score those points in high school or college. Nobody forced them to practice. Nobody read their job description to them.

They did the work. They built their abilities. They found ways to produce value for their teams… and they earned their rewards.

For that, they were not easily replaced. For that, they could compel a little VIP status. For that, they sometimes got out of hand, acted like prima donnas and started producing high costs for their employers (and themselves).

Thinking at the margin doesn’t discriminate

So while there are marginal utilities, which produce marginal value… there are also marginal costs.

“Rational people think at the margin” means nobody worries about what is the same. All “team players” who follow standard practices and never step out of line, but never produce incremental value over their coworkers may feel “safe”… whatever that means to them. But they can never be valued any more than what is commonplace (…and there is nothing wrong with that).

Hire this guy? The most interesting guy in the world...

On the other hand, rational people evaluate the costs associated with picking up those few extra points in a basketball game… with adding that expert to their team, along with any eccentricities they bring. The person who has that unique knowledge of a technology or who can make the database “sing”, but who may not perfectly fit in some other way, might be just what is missing.

They evaluate whether it’s “worth it” – worth the costs in terms of time, energy, money and lost opportunities. And then they willingly make investments to get access to all the difference in the world, if it will help them achieve their tactical, strategic or ultimate objectives.

So let me ask again… who do you want on your teams?

Advertisements

About ken
Creative insights, passion and technical adrenaline - strategist, agile coach and marketer, providing a good life for wife of 20 years & 2 awesome teenagers!

18 Responses to Team players and MVPs

  1. ken says:

    From LinkedInGroup “IASA: The Global IT Architect Association”:

    DSK Chakravarthy wrote “I prefer those who talk from their experience and know some technical”.

    Chris Shayan wrote “commitment …”

    • ken says:

      My response: @DSK, in the experience area, it is also useful if their experience produced accomplishments… winning and losing are both valuable accomplishments, when we learn fundamentally from them.

      @Chris, commitment is also very powerful, though commitments change from time to time.

  2. ken says:

    From LinkedIn Group “Agile Executives”, Dennis Phillips wrote:

    We had a great discussion on this at the monthly Agile Executives meeting. The discussion centered around good attitude vs. great skills. Obviously if you could find both in one candidate you’d take it. Personally, I would take good attitude over great technical skill. Skills can be learned, attitude, well I am not so sure. And I would get rid of a “bad apple” regardless of skills. As Bob Sutton of Stanford stated, “Eliminating the negative is more important than accentuating the positive. Bad Apples are a distraction and contagious.” I also like the research by Will Felps which showed that “Bad Apples” including deadbeats, downers and rude jerks – bring down performance 30-40% compared to teams that don’t have them.

    • ken says:

      And my response: @Dennis, these are great insights. I am also one to work on removing negatives from a team. Many years ago, Kent Beck wrote “I am not a great programmer, but a good programmer with great techniques.” I accepted that as permission not to have to know everything, and I began to notice what great teams I could work in where there were no gurus.

      Meanwhile, I also began to notice how engaging fully in a great team mobilized me to do more for others, to find ways to emphasize my strengths, and that led to areas where I stood out, if only to offer more help where I could. That form of expertise amplifies the overall team capabilities, but may not be something you can compel or legislate. It sort of “shows up”.

  3. ken says:

    In LinkedIn Group “Creative Product Managers”:

    Prem Jha wrote “I want a guy in my team who is having positive attitude
    willingness to learn from mistakes , Unknowing the art of Unlearning
    in order to learn new.”

    Melissa Snyder wrote “Creative thinkers who do not have to be babysat. People who can admit when they don’t know what they don’t know. People who will brainstorm without fear of judgement. People who believe in timely follow through and are able to manage expectations.”

    • ken says:

      And my response: @Prem, this capacity you mention to learn from mistakes implies also that we give people some room to make those mistakes. That is a great insight, and goes a long way to building an autonomous team. Stepping in to rescue others all the time does not help them develop problem-solving skills and begin taking on bigger challenges.

      It also implies to me that you have some thinking around removing people from the team who do not learn from their mistakes?

      @Melissa, I interpret what you are saying as people who act with some autonomy – freedom to be self-directed, make decisions and lead… and I also read commitment and some political/psychological maturity. I wonder if that last part could also be dependent on the role they hold in the team?

  4. ken says:

    In LinkedIn Group “Michigan Agile Enthusiasts”, Marvin Toll wrote (no kidding):

    “Who do I want to run my team?” Why… Ken Faw of course!

    • ken says:

      And my (most gracious) response: Joker. Be careful what you wish for!

  5. ken says:

    In LinkedIn Group “SCRUM Practitioners”, Richard Quinn wrote a great response for deeper conversation:

    Who do I want on my team?

    If you mean, “what characteristics should your teammates share” I’ll answer. As it stands, the question annoys me. I don’t “own” the team, much less the people on it. I’ve been a CTO, lead developer, lead architect, team leader, a group leader, a project leader, a product owner and a scrum master. But never a team owner.

    So what characteristics are important to me in my team-mates?

    Self-belief and a willingness to contribute new ideas.
    Ability to listen and be gracious when other people’s ideas are also good.
    A conviction that the only way to productivity, happiness, fulfillment and sustainable success is through a dedication to quality and delivering the best work possible.
    Technical / professional proficiency is also very important, but is neither the only nor the most important thing for me.

    Hope this helps!

    • ken says:

      My response: @Richard, thanks for your assessment. It was not my intention to annoy you, and I must apologize that when I posted to this group, I double-pressed “Enter” so you got no description or amplification to my question that would have help you in your response. Please forgive me for that, and I have developed a practice to prevent it in the future.

      In addition, thank you for sharing your characteristics of a good teammate. I value each of those as well, though sometimes I am not the best at practicing them myself.

      One thing that I am curious about is your distinction for “ownership” of a team. In asking who you would want, I was not asking about ownership… but now that the topic is opened, what do you think about the notion of “self-selection”?

      Self-selection says that people join teams and leave teams based on their associating themselves and claiming membership in the team. For me to be in the SCRUM Practitioner’s LinkedIn Group, I practice SCRUM. I declare that I do, and as long as I claim membership in the group, you should expect it of me. If you determined that I did not, and it were a requirement for membership, then it would only be reasonable that I be removed from the group.

      So it is, for me, on my agile teams. If we practice TDD (for example), and a team members elects not to… and consistently refuses to participate in the standard practice… then I would not want them on my team. That has nothing to do with owning the team, though as a team lead, lead developer or CTO I claim responsibility for enabling my teams to be effective… and that means I would remove them if they won’t join the social structure that the team has set up.

      Based on how you expressed your characteristics of a teammate, I think you might as well. How do you (or anybody else here) think about self-selection?

  6. ken says:

    In LinkedIn Group “IASA: The Global IT Architect Association”, Art Freas wrote:

    New to this group but I’ll jump in.

    I am a bit counterculture to a lot of the conventional wisdom about teams. I pretty much play the cards I am dealt. I would rather spend time forging the group of folks I am given in to a team that spend time trying to pick the perfect person for each position. Too many rockstars and you end up with a trashed hotel room because you had the wrong color M&Ms. A good leader can find a way to bring almost any group together to form a team. The sooner you get folks together the sooner you pass through forming, storming, and norming and arrive at performing.

    • ken says:

      My response: @Art, conventional wisdom isn’t necessarily wise or effective. I tend to lean toward your description as well, though the leading and molding that produces a good team also means sometimes that people don’t fit well together. Given the opportunity to work within a team, some may self-select out and others may not be able, for some other reason, to work well in the environment provided.

      There have been times when bringing the team together and delivering on our promises meant not every individual who started the project ended together. Sometimes they opted out, and sometimes I made the decision to remove them from the team.

  7. ken says:

    In LinkedIn Group “SCRUM Practitioners”, Joao Ambrosi wrote:

    Being practical, I would say good team members are ethical and commited, also techincally sound individuals, lets-do-it attitude, humble but creative, passionate about the objectives. You can always improve technical aspects, learn, develop and apply new techniques, if you have the other facets. Usually cannot do the other way around. Does it help?

    • ken says:

      And my response: @Joao, I accept. I can (and enjoy) developing people on my teams, but I also find it valuable to pay for special skills from time time. There is nothing moral about that… it is just practical to pay for knowledge while also developing knowledge. Using the sports analogy, though, not all skills can be developed to the same level of proficiency. In that, people are not substitutable for each other.

  8. ken says:

    On LinkedIn Group “Creative Product Managers”, Karla Guandia wrote:

    I want people with positive energy and hungry for knowledge. People that are capable to take accountability for their mistakes and move on. People that are not afraid to praise the work of others. Risk takers and those who are not afraid to communicate ‘crazy ideas” in group settings.

    PS: As a former, basketball player, I would love “Magic’ in my team. A player that can dribble, pass, dash, penetrate, rebound and still make his whole team look good

    • ken says:

      My response: @Karla, me too.

  9. ken says:

    In LinkedIn Group “IASA: The Global IT Architect Association”, Julie Kalu wrote:

    Also new here. Its so interesting and educational to read the different points of views on this subject.

    In addition to commitment, competence and good leadership, the best teams I’ve worked with were the least egotistical. I’ve seen remarkable results come from a team that trusted and respected the individual expertise of each of its members, and disasterous results from teams who’s members are threatened by the notion of saying “I don’t know” or are driven by their own personal agendas.

    • ken says:

      My response: That’s a key to me as well, @Julie… egotism in a teammate, or even a perception of selfishness, would be like having (in the basketball sense) Dennis Rodman rather than Michael Jordan… at least as far as I understand public opinions about them.

      [Being from Detroit, I accept that I might have a different assessment of Dennis, though.]

%d bloggers like this: