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

Does your IT salary depend on what makes you different?

"Rational people" think at the margin...

It’s Monday, and that means I take another crack at an economic principle and apply it to software development and IT. (Here is a link to the series so far.)

This week we are on principle #3 which goes something like this:

Rational people think at the margin.

I am going to put aside questions about whether (or which) people are “rational”, or whether I would be qualified to make the assessment in the first place.

Instead, I want to focus on the “margin”. (Perhaps that makes me “rational”, after all.)

In this context, the “margin” relates to an economics principle called “Marginal Utility“.

A summary of the concept (for our purposes, anyway) is that people will value two otherwise equivalent items against each other based on their “marginal” (or incremental) differences, positive or negative.

So we might pay more for one car based on its gas mileage or on its performance characteristics, all other attributes being pretty much the same.

Fundamentally, the market of buyers and sellers converges on a certain price at which a commodity might be bought or sold.

As long as a surplus of buyers or a shortage of supply exists, prices may rise… and the converse also holds.

Designing for marginal utility

Now, if a company wants to sell its products at a premium, you may have heard that it needs to “differentiate” them in the market.

More specifically, the company needs to name, find or design a marginal utility for its offers… an incremental change that drives a disproportionate increase in assessments of value (price).

Don't quit your day job!

My business teacher, Toby, used an analogy like this (the following numbers are illustrative only, and may not be accurate):

  • A “good” college basketball player, scoring 26 points per game, has no chance of becoming a professional…
  • A “great” player, routinely scoring 30 points per game, might get drafted at a league minimum salary…

While…

  • The “elite” player who always scores 34+ points per game might get a starting salary ten times higher (not to mention endorsement deals and other additions to income)

Looking at it that way, you could say that the difference between getting into the pros and not is 2 baskets per game.

You could also say that the elite player gets 90% of their income from the extra 2 baskets they make every game.

Bringing the topic back to IT

Since I thought it would be good to set up what marginal utility is and offer an illustration, it seems to me that we can spend a couple of weeks on this subject. We can speak about designing marginal utility at the individual, team and organizational levels.

So while we have the notion of salaries fresh in our minds, let’s start with you and me, shall we?

First, let me make my intentions really clear: I accept that people say money isn’t everything. People don’t have to slave and toil to get paid more. There is nothing morally ‘right’ or ‘wrong’ about wanting higher pay or not.

Remember that the topic is marginal utility in the domains of software and IT. So I am just speaking of the topic about how much we get paid. That’s all – I have no judgments and am not making any recommendations – “I’m just sayin’.”

I have nothing particularly witty to write this time - this is a piggy bank on a pile of money.

In the basketball analogy, good players don’t become professionals. There is nothing wrong with them – they’re good… just not valued highly enough to get in at that level of competition.

In my career, most of the IT people I’ve met are good.

They get paid what the market bears for their roles, which our industry declares clearly and consistently in job descriptions from one company to the next.

A Java developer is a Java developer, and they make a certain amount of money. They make a little more as a consultant, generally speaking.

A “senior” Java developer wants to get paid more, but the standard for assessing what “senior” means is not well established.

And don’t get me started on what an “architect” really is in all its various derivations… except they also expect to get paid more, and have higher expectations to live up to.

The point is: as long as what defines your capabilities and accomplishments is the same as everyone else, the market sets your rate pretty clearly.

In this situation, your income fluctuates with the market, and you are a commodity, in a sense. A business may see you as replaceable, you may struggle to find your next role and you may feel trapped in roles, feeling underpaid and undervalued.

On the other hand, when you find those strengths that you bring to bear – those things that makes you incrementally more valuable than someone else in your role – that could be marginal utility (your “2 baskets more“) for which you compel other to pay a premium.

Just be careful in thinking that what you value about yourself is what they value, and that you deliver enough that they will feel your premium is worth it.