So who really is a good "team player"?

Seems like everyone describes themselves as a "team player" these days. The label "not a team player" also gets thrown around a lot (and especially by people who are even less of a team player themselves). Which brings me to the topic of this post: so who really is a good "team player"?

I have experienced three types of people:

Type A: Don't have a strong opinion and don't have much to contribute to defining the project's direction, but are willing to follow your lead. This isn't terrible, and having a minority of this type on your team may even be desirable, but, let's face it, they're not that exciting to work with and you don't learn much from them. About 40% of the people I have worked with are of type A.

Type B: Have a strong opinion and a lot to contribute, but cannot compromise. This is terrible. (Let's assume here that the competing project direction is equally valid from a technical perspective.) You learn something from them, of course, but they can easily bring negative value to the team or outright destroy it. The typical course of events is

1. a meeting or a series of meetings is held in which there is vocal disagreement over the direction of the project
   
2. given that no consensus can be reached, a decision is made by the team leader or by the team majority against Type B's recommendations (sometimes Type B will pro forma "agree" so that "the team can move forward" with a tell-tale resigned look)
   
3. Type B displays one or more of the following symptoms (a) makes fun of or talks negatively about the project to outsiders, (b) defiantly hacks his/her vision into the code as fast as he/she can without discussion, (c) authors a competing paper or piece of software, (d) withholds talent, (e) becomes very quiet, (f) uses the phrase "I told you so" and delights in any trouble the project may experience in the future.
4. The team dissolves or Type B resigns (at least from the team project if not from the organization), or gets fired.
   

I have seen the above sequence at least ten times by now. If you have a Type B on the team and you get to stage 1 you will inevitably get to stage 4. Type B's comprise about another 40% of the people I've worked with.

Type C: Have a strong opinion and a lot to contribute, are willing to compromise on direction, then push as hard as they can in the direction the group has agreed upon. Yes, these are the team players. Get a group of them together and miracles happen in terms of innovation and productivity and bonding. These are only about 20% of the people I've worked with. I sure remember every one of them.

"Freakonomics", Compensation, and Motivation

I recently read "Freakonomics", which talks about human responses to financial incentives. One interesting insight was that telling parents that they cannot pick up their kindergardener late works a lot better if you don't define a financial penalty. This makes a lot of sense, of course - if there is a defined penalty it makes it sounds like it's OK to be late as long as you just pay for it... Another interesting insight was that real estate agents keep their own houses on the market 10 days longer and sell them for 3% more than the houses of their clients. It turns out that their financial incentive for selling for a slightly higher price just isn't enough reward for the extra work that would be involved. "Freakonomics" is overall a good read, as long as you don't look for an overall point or take-away, it's more like an essay collection.

Related, I also recently read "The Seven Hidden Reasons Why Employees Leave" that I stumbled upon in the management book section of a Borders Bookstore. Tremendously valuable book - people managers should go through the checklist of seven periodically to see if their employees are at risk. Unsurprisingly, it says that compensation - while often stated in exit interviews - is rarely the real reason people are leaving. That being said, it recommends paying your employees 7.5-12% above market average which makes a lot of sense to me - as people tend to perform to expectation and as they want to keep a good thing going they'll put in extra effort and are less likely to leave. Given how expensive it is to replace an employee that percentage premium will easily pay for itself. (I've heard it said that no one pulls their weight for up to a year in high-tech jobs with a lot of domain knowledge to be acquired; "Slack" has a good quantification of turnover costs) .

"The Seven Hidden Reasons Why Employees Leave" also talks about the various forms of variable pay that are used. I'm really on the fence as to if variable pay is a good idea for software development engineers at all (outside of a yearly bonus or options/stock grant I mean). The Dilbert cartoon's "I just wrote myself a minivan" in response to being paid per bug you fix in your code comes to mind. It's probably best to stick to slightly above average pay and benefits, and to then focus on rewarding your employees with informal recognition, promotions, work of their choice (a la Google's 20% rule), special time off after an intense deliverable, sabbaticals... but that will all have to be the topic of a future post...

Welcome to "development"!

So I've decided to start a blog. It is called "development" because it is about

• software development - effective software engineering
• idea development - innovation in collaborative tagging, structured Wikis, and lightweight ontologies
  
• team development - effective team building and leadership
  
• personal development - my own professional and private growth

I hope to regularly record my experiences and insights here, primarily for my own benefit - but you are more than welcome!