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

Unintentional “lies” in the software development field?

Beware the Chicken-a-saurus!

Marketing folks have learned a few things from software developers.

It is funny to me that developers often speak of marketing professionals as if they mainly lie to people about what they want to hear (or as if that were a moral thing).

I say that because it sometimes happens in our industry as well… maybe more often than we want to admit.

80% complete

I remember when I was just getting started in software… senior developers would report their tasks being 80% done… and remaining 80% done for weeks afterwards.

On better projects, they would report 80% complete on their first status report, and then 85%, 90%, etc.

And some of them couldn’t tell me what the “method of successive approximations” was. Go figure.

“Ready to ship” in 3 months

Or how about another example – that the software will be ready to ship in “N” months? In a recent MarketingProfs short, “How to Sift Through Unintentional Lies”, it cautions marketers to brace themselves for “one lie after another”.

It is worth reading, not so much to raise your hackles, but to learn about the perception we create in customers in whom we want to build an assessment of value. Though the article speaks about other domains than software, here is a fragment related to us, from their perspective:

No development team wants to miss a deadline—but it will happen. “There’s one project I’ve been watching that has literally been three months away from shipping for 18 months now,” notes Anthony. You’ll get more reliable estimates if you eschew a single, long development cycle for rapid cycles that produce a “minimal viable product” for testing and further augmentation.

[Bold emphasis mine. Again, please read the article at the source reference I included in the preceding lines.]

So there you have it… marketers asking for agile delivery of value. That’s pretty cool and a good place for us to work together on rebuilding trust.

Notice the article is careful to say the development team is not being malicious or intentionally deceitful.

I cannot remember a case where we have been, either. Most developers I know love to write software. We love to create and we love to solve puzzles… but let me highlight a third example before we close for the day.

Trusting each other

Now, there are explicit promises and implicit promises. In fact, it is the implicit promises that can do the most damage. You can try to disavow them easily or you may not even realize others think you made them in the first place.

In this case, DON'T read the manuals!

Have you ever made a promise to a teammate that you intended to keep, but failed in the end to keep? I know I have.

Did you ever “break the build” or overwrite someone else’s changes because of a merge conflict? I have done that, too.

Have you willingly taken on some task for a long time, and then just decided not to do it because it wasn’t really yours to do? Did anyone depend on it getting done, and did they know you stopped doing it?

Did you know you’d made a promise, or acknowledge the breakdown you produced? Not always, for me.

Do you think that failing to notice that you made a promise in the first place makes it any easier on the person you let down?

These are situations we create with our own teammates… and yet we sometimes try to diminish the importance of the cost we produce for others in failing to hold the promises we make.

Keeping promises requires professional attention

Many people write about agile methods being based on a notion of trust (including me). Quick releases, adaptive requirements, continuous integration, better testing and quick communication can go a long way to help us make and keep promises.

There are many levels in a project in which we make promises. They all count, especially in the eyes of those who accept our promises.

Keep the ones to your customers, but also keep the ones to your teammates.

Think about this – You may be committed to the top thing or two on your list, and everything else gets shifted around and de-prioritized. Though it makes you feel better to tell others you are over-committed, you may really be over-promising and failing to commit to the promises you make.

What hurts others also hurts your identity with them.