The Pay Off in Merit Pay (Not)

If you've been reading this blog for a while, you know how I feel about compensation systems that claim to motivate better performance with differential pay.

For example,

A Compensation Story in 2006,

It's What We Know That Ain't So and

Pay for Performance and Why it Doesn't Really Work in 2007

So of course, I was interested when I came across Where's the Merit-Pay Payoff? by Fay Hansen on WorkforceWeek.com. (requires free registration).

A few snippets:

The seemingly self-evident premise underlying merit pay and other individual performance-based pay plans is that they produce higher employee and organizational performance. Most companies, however, do not test the actual impact of performance-based rewards on employee behaviors and financial results. The most comprehensive empirical studies flow from the academic world, where evidence is mounting that the assumptions underlying individual performance-based pay programs are wrong.

"The evidence is overwhelming that individual pay for performance does not improve organizational performance except in very limited cases."
—Jeffrey Pfeffer, professor, Stanford University Graduate School of Business

"Effective management is a system, not a pay plan. The mistake is that companies try to solve all their problems with pay."
—Jeffrey Pfeffer. professor, Stanford University Graduate School of Business

Pfeffer notes the existing evidence points to group bonuses, profit sharing and gain sharing, which is a form of profit sharing, as more effective forms of performance-based pay than merit pay or individual incentives. "Group plans are more collective and recognize the interdependent nature of work today," he says. "Most employees look at their total compensation and want to see that they share in the success of the organization."

This is particularly germane to organizations that are asking people to work collaboratively in teams. Yes, we do pay individuals. There are rational ways to do that without so-called merit raises. I'm glad to see that group bonuses and profit sharing are starting to come up in the conversation.

----------------------------------------------------------------------------------
I will address the top concerns that come up when I write/talk about this topic preemptively.

1. I am not suggesting that everyone be paid the same salary. Skills, experience, domain knowledge and the current market are all considerations in setting salary. The key is to pay people equitably (which is very different from "pay equally").

2. I am not suggesting that everyone's skills and performance are equal. Of course people have different skill levels and perform differently. Most companies recognize this with salary bands.

3. I am not saying that teams should have a team salary. Salaries are paid to individuals... though I suppose an independent team could contract jointly, and then decide how to allocate pay within their group. But that's a different topic.

4. I am not saying people don't need feedback on their performance at work. People need feedback--which is information about performance, not evaluation--on a frequent basis. The more we can design systems where the feedback comes from the work, the better (e.g., build lights, green bar/red bar test frames). Peer feedback and feedback from managers are crucial for improving performance.

5. I am not saying that people who aren't actually working should continue on the payroll. But any manager who needs a pay-for-performance system with ratings and rankings to figure this out is in big trouble.

I think these are some of the things people fear when they think about removing merit pay. There are other rational pay systems... but they aren't as wide spread, so few people know about them. More on those, later, perhaps.

A Retrospective Report

John Wilger has posted his experience leading a release retrospective. It's a nice description of the flow of the retrospectives, and shows how activities help people get beyond superficial and habitual thinking.

In summing up, John writes:

Before we held this retrospective, I think some of the team members felt that we would not gain much from doing a full-day retrospective this time around. We had made good progress on our action items from the previous retrospective, and the general feeling was that things were going basically well. What could we possibly need to change?

People, please don’t hold retrospectives only when your team feels like there’s a problem that needs to be dealt with. If you hold retrospectives on a regular basis, whether you feel like you “need” to or not, you will uncover issues before the become problems. In our case, we managed to uncover a number of issues during our retrospective that could easily have grown into much larger problems if we didn’t bother to think about them until the effect was obvious.

intake->meaning->feeling->response

Mike Cottmeyer writes about Feelings, Thoughts, and Actions.

When people have a strong response, Mike describes thoughts as the point of leverage to change behavior.

How we think can be influenced more directly... it is somehow less personal. We can learn about our environment and the people that are a part of our lives. We can gather more information about what motivates those around us and learn something about their intentions and circumstances. With new information, we can learn to think differently about what is happening to us.....By guiding thinking, we are able to broaden the perspective of our team and create the opportunity to coach behavior.

This lines up nicely with a model I use, Ingredients of an Interaction, from the work of Virginia Satir.

Intake: We take in data from the environment (filtered by our preferences, education, stress level...)

Meaning: We make an interpretation of the data (influenced by past experiences, education, stress level...)

Significance: We have a feeling, based not on the observed data, but on our interpretation of the data.

Response: We act out of our interpretation and feelings.

(Don Gray describes the Satir interaction model in more detail here.

When Mike coaches about thoughts, he's working on the level of Meaning, expanding the possible interpretations. When he talks about bringing in more information, he's working on the level of Intake.

I find this is a powerful model for untangling communication that's gone awry, and for understanding and shifting my own reactions.


***

On a related note, Mike talks about telling people their behavior is "unacceptable."

Rather than start out by telling some one his behavior is unacceptable, I find it usually works better to get agreement that the behavior happened. That usually requires neutral language...rather than "you were pounding the table in our meeting today" I might say "In our meeting, I saw you raise your fist and bring it down on the table." It's too easy for people to get into a Yes-you-did/No-I-didn't argument when there's any hint of judgment in the description. If people don't agree with the data, they aren't likely to listen to anything else you say.

Once I've got agreement on the data, I talk about the impact of the behavior. "I was startled. I noticed that Jen and Josh both pulled back from the table, and didn't say anything else for the rest of the meeting." Depending on how the other person response, I might go further. "When you hit the table, its hard for me to continue participating in the meeting. What I see is that when you bring your fist down on the table, it gets in the way of people listening to your ideas" (or something like that).

I'd rather let the person conclude that the behavior is ineffective and counter-productive and make a different choice. I find that works better with adults than having me say "That behavior is unacceptable"....especially since it may have been accepted in the person's family, or some previous context (where they learned it, and where it might have worked--on some level).

There are times when I do say "that behavior is unacceptable here," but I usually don't need to do that with reasonably well-adjusted adults.

Specialists AND Generalists

Johanna's post, projects don't need specialists (and the 19 the comments that went with it), got me thinking.

People tend to coalesce around shared interests--both in terms of what they find interesting, and what concerns them. Take the category of retired people. It's not a particularly strong category, they may have overlapping pursuits, but have a stronger set of shared concerns, such as access to health care, social security, etc.

Professional concentrations are no different.

People who specialize in data modeling are concerned about having a rational and coherent abstraction of the data in the domain.

People who specialize in process control focus on real-time issues.

People who specialize in data bases are concerned about tuning and performance.

I could go on with lots of other professional categories.

All of these are legitimate concerns.

Here's where it gets sticky. When you have a project with a lot of specialists, each has a particular (legitimate) point of view and (legitimate) set of concerns. If they haven't had experience working in other technical areas they may not consider other concerns.

Labels, titles, and functional silos reinforce categories and create an echo chamber for concerns.

So if you have a project with many specialists, you end up with lots of politics as people seek ascendancy for their particular concerns. If the specialists are acting as vendors to a project team, those specialists may not be invested in the delivery goal of the project, only in delivering their part answering their concerns.

That doesn't mean that people are bad and wrong, just acting the way people act when the coalesce around categories.



It's not that projects don't need specialized knowledge; they certainly do. But they need people who can perform specialized technical tasks and understand that there are multiple sets of technical interests involved, all of which must be, at some point, softened to the project delivery goal.

Handling the need for specialized skills isn't only a matter of scheduling constraints. It's a matter of conflicting concerns and politics.

I am in favor of specializing generalists, or generalizing specialists--people who can perform specialized tasks (as well as make a contribution outside their speciality--and see other technical concerns and focus on a project delivery goal rather than one set of concerns.

Reducing categories (having "developers" rather than many named specialists) reduces differences and helps people focus on shared goals.

A Poor Performer?

Mark Levison has an interesting post in response to a Scrum Development discussion about "bad apples" on a team.

Before applying the label, look for reasons the person might not be performing. There are lots of reasons for a temporary dip in performance. Or, it might be a problem with the tools available, or the environment. It's very common to attribute problems with the system to the individuals (and vice versa).

Our own prejudices can get in the way. My friend Jerry tells a story about when he was a grader for a college course. His job was to read essays and grade them based on criteria. When he turned the grades over to the professor, the professor challenged one of the grades, an A. "You can't give this person and A," he said, "he's a C student."

Mark offers a quote from Linda Rising:

"In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice."

Mark advises:

So before we rush off to action on poor performers:

Stop, let go of preconceptions
Re-examine the person's role on the team
Listen/Watch - don't measure
Only if there is a problem - then solve it.

I agree.

Also see:

George Dinwiddie's Working Hard or Hardly Working, and my response.

and...
When is it time to move someone off the team?

Non-valued added, but necessary

Hank Roark, Gerry Kirk and I have been having a chat about "non-value added but necessary" tasks over on Twitter.

It started with an assertion that any thing that doesn't add value to the customer or delays delivery of customer value is waste.

That sets up a binary decision: tasks are either provide value to the customer, or they are waste. I've noticed that when people first start mapping the value stream for software development, they tend to assert that management is all non-value added work.

In addition to value-added and non-value added work, I think there's another category, "non-value added, but necessary."

Non-value added, but necessary are tasks that don't directly add value to the customer, but enable delivering value to the customer. Sometimes these are the tasks and functions that enable the business to stay in business--like accounting, or payroll, or management.

That's not to say that there isn't waste within those functions, there certainly is.

But no one likes to hear that they are adding no value. When people hear that, they tend to feel defensive, and people who are feeling defensive are less like to be able to take an clear-eyed look at how they can best improve the system.

Having a category of "non-value added by necessary" gives a way for people to examine the work that isn't directly on the software development value stream without focusing so much on justify their existence. Then the are more likely to see where they are doing tasks that don't enable creation of value and shift their focus to work that does.

We need to look at "value" from the customer perspective, certainly. We also need to look at value from the viability of the overall organization, and at work that isn't directly related to the product but creates the conditions for creating value.

A Conversation with Glen Alleman

'twas the night before Christmas, and all through the house, not a creature was stirring, not even a mouse...

But Glen Alleman and I were chatting via his blog about the difference between self-organizing and self-directed teams, and how failing to recognize the difference gets people in trouble from time to time.

A (slightly) edited form of the conversation:

Esther: I'd agree that self-organizing teams are not the same as self-directed teams. I specifically reference self-organizing teams, not self-directed teams. Self-organizing teams exist within an organization context and serve the needs of that organization.

I agree there is still a strong role for management in organizations that have self-organizing teams.

Glen: My experience has been whenever the term "self organizing team" is used it is taken to be "self directed." In the absence of a specific statement about the differences in the first sentence of any article the listener jumps to the end with "we're going to run our team in the absence of management." The next step is usually the cancellation of the project ;>)

Esther: As often as I see teams reject guidance from management "because we are self-organizing," I see *managers* abdicate any responsibility to the team or for the team. Neither stance is very productive.

But it does take both managers and team members time to figure out new roles and how to work in a new relationship. That's part of the reason I wrote the article.

Glen: It does take both side of the "team" to understand their individual and combined roles.

I've moved back into defense system for many reasons, but one is the continuous questioning of "how can this benefit the program as a whole - the entire business operation?" Management in this environment are the leaders of the subject matter experts, rather than the "supervisors" of the labor. We are working managers, rather than observers.

The article provides a wonderful starting point for the conversation about how each role contributes to the successful completion of the project.

###

My entire article (referenced earlier in this blog) seems not to be online right now :-(