Jul 252011
 

A team sport (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 elseto 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 donnasand 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” meansnobody 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?

  28 Responses to “Team players and MVPs”

  1. 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 …”

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

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

    • 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. In LinkedIn Group “Michigan Agile Enthusiasts”, Marvin Toll wrote (no kidding):

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

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

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

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

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

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

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

  10. On LinkedIn Group “IASA: The Global IT Architect Association“, Kinshuk Adhikary write:

    Best to avoid “teams” altogether. A camel is a horse designed by a committee. Have talented individual contributors, just make sure that the communication bus is not clogged, and there is scope for mutual learning and individual target satisfaction. Most of all, make sure there is no “god type” who “leads” without enough deep and wide knowledge of the subject. Good software is made by a benign monk-hood of silent folks in cubicles fighting their own demons, not by heave-ho teams with an ignoramus on top.

    Lets study the way open-source software contributors work. Some of them have never even met each other, and may live 10000 miles away. It does not matter. Management is all about tools, not about people.

    • And then David V. Corbin responded:

      @Kinshuk, I have to respectfully disagree very strongly with that position. First it complete contradicts proven approaches such as pair-programming. Second the open source community is one of the worst examples of software development practices there is.

      People will focus on a few successful projects, and ignore the tens of thousands (and that is actually a low number) of projects that completely fall apart, and never produce a useful outcome. Looking to an environment that produces perhaps a 0.1% success rate (i.e. a 99.9% failure rate) is a “blinders” view at best.

      One the otherhand, when there are good solid teams (talented people + efficient tracable process), the success rates approach 90%. One exercise I regularly perform whith clients (when my company is engaged to help them majke major improvements to their environment) is to “randomly” pick one person on the team, and tell the team that “as of tomorrow this person will be unavailable for the week”. I then calculate what the milestomes were for that week with a full team and subract the appropriate percentage (e.g. 10% is there is a team of 10 and one will be missing), and but that percentage (again “randomly”) from the weeks backlog.

      If the team has problems meeting that delivery then that shows there is too much reliance on a specific individual [and I quoted the word randomly becuase I actually pick the person most likely to have a significant impanct, and make sure NOT to cut the items that wil be most impacted]

      The first time I do this, the results are often horrible. However after some restructuring, and a few repeats of the exercise the success rates are almost 100% in meeting the adjusted goals, and the overall team efficiency has increased measurably (typically 15%-20%) becuase there is no longer a focus on the individuals.

      As one final point, consider scheduling methodologies such as Kanban (proven effective in many environments). There is a single (small) stack of items in the input queue. When a person finishes a task (and the output queue is not full), they take the next item off the top of the list. There is absolutely ZERO association of tasks with specific people ahead of time, however becomes available is expected to be able to perform any task that has risen to the top of the queue.

  11. Sometimes “team player” is simply management jargon for someone who will not challenge assumptions, will not challenge a process that produces demonstrably bad outcomes, will not object to micro-management, will silently lay down on the railroad tracks when the train is coming.

    In short: a lap dog. They can be wonderful. But would you really want a whole team of them?

    • SK, thanks for your comment. I have observed that use of “team player” as well, and it is actually one of the contexts I was writing about. My intention with this post was to speak about how we can individually increase our value to our teams by adding some measure of value that is unique and special to the work we do together.

      We follow processes when they work, but we work together to win regardless. We build our skills and we make and hold commitments to each other that are beyond the simple tasks we are required to perform just to trudge to work every day.

      Not many of the comments to this point have highlighted that, so I appreciate your observation of the jargon-form of “team player”… because while it is great to have team players, it is also great to have more than those who simply tow the line, as they make higher and greater commitments to each other and consistently deliver on them.

      –k

  12. […] term used from time to time is “team player”. One recent blog commenter said that in his experience the phrase “team player” is often used as… simply […]

  13. In LinkedIn Group Lean IT Enterprise, André Andreazzi wrote:

    I would like to add system thinkers and people who go at area to understand the problem.

    • @André, I am glad you brought up systems thinkers… that says a lot to me, in the spirit of Goldratt, Senge and others… having insight into the “system” at work means much more than performing the task at hand.

      In the US submarine force, we learned standard practices so that we could do them in our sleep. We also drilled and we drilled on what might happen in the event of fire or flooding… in that we had to learn the fundamentals and we had to know the systems. If we needed to shut down a side of the engine room for a steam line rupture, and it meant the lives of every person on the ship, we might have to improvise.

      All of our firm grasp of standard practices was critical for operating the ship. And when we had to troubleshoot, we had to be systems thinkers. Much of our casualty response training involved stabilizing the systems and getting out of casualty mode, after which we brought everything gradually back under control again.

      I agree with you that having that capacity in my team members can be a great benefit.

  14. […] ready for the moments they sometimes shut down or defer to others’ “leadership”, even as I hear them making sound observations and assertions, and leading the team in their own […]

  15. […] them to know what a great brand you are building, help them to see how they can fit into that and how they can impact market perceptions – make them brand ambassadors, but don’t ignore that they can have a great positive (or negative) impact on the […]

Leave a Reply