brainsnorkel.com

A while back I purchased and read a book by Jeffrey Pfeffer and Robert Sutton called “Hard Facts Dangerous Half-Truths & Total Nonsense” subtitled “Profiting from evidence-based management” which seeks to examine many deeply ingrained business-related beliefs that aren’t necessarily backed by any study or evidence.

I have had an interest in performance management programmes and software engineers for a long time. This is probably because all of the systems of assessing and rewarding performance I have participated in over the years have seemed flawed in different ways. This post is an examination a random walk through the Hard Facts chapter on incentive programmes.

Performance management programmes typically consist of processes for goal-setting, development, performance appraisal and reward. While the reward is expected to be commensurate with the amount performance exceeds expectations, when the objective is not met a program of correction cane be undertaken instead of a reward system. As carrots are said to be a better control of behaviour than metaphorical sticks, most companies opt for a system of financial incentives to reward good performance.

In their book Hard Facts Pfeffer and Sutton examine the question “Do Financial Incentives Drive Company Performance?”

Fundamentals

Hard Facts lays out the theory of how organizational performance can be improved with incentives.

1. Motivation effects: Even though incentives don’t have an immediate effect on ability, individuals will work harder if they know they will be rewarded for harder work.

2. Information effects: Incentives inform individuals about what the organization considers important.

3. Selection effects: An incentive program can help drive away the wrong type of person and attract the right type for the organization.

Motivation

In IT and related fields, financial incentives are the norm. Hard Facts makes the point that not everyone is motivated by money. Additionally, people motivated by money aren’t necessarily the right people to have in an organization. Undeniably, it seems humans are motivated to apply more effort to their work by money.

It turns out that most people wildly overestimate the effect of financial incentives. Hard Facts quotes a General Social Survey of US citizens where the same people who rated pay as the third most important aspect of their jobs (“important work” and “a feeling of accomplishment” were first and second) thought other people were much more motivated by pay than themselves. “73 percent thought that large differences in pay were necessary to get people to work hard…”

Information

Software Development industries are filled with knowledge workers, whose day-to-day activities are a mix of engineering practices and inspired invention. The activities necessary to release or service software are complex and are often subtly inter-related. Setting easy-to-measure goals that have a surface-level relationship with the behaviour to be encouraged is both seductive and commonplace, but it is rarely able to define broader organizational goals.

Most software developers have a story that parallels the legendary Dilbert Cartoon above. A decision is made to set goals or provide incentives in a way that was intended to solve a problem, but introduces disastrous side-effects; You’ve been told that you need to write more code so you set up a cron job to generate zillions of lines of perfect template code each day and check it into source control; or you’ve been asked to cut down on software costs so you’ve illegally copied software rather than raise a purchase order.

The example that comes to my mind is when projects in my part of an organization were measured based on how long problem reports stayed open. Developers would take emails and phone calls and write problem details in their journals, working on the problem off the books. When the problem was fixed, they would report the problem in the problem reporting database and shortly after they would close the problem with the fix they had prepared earlier. While this made for some very impressive metrics, it was not the most efficient use of developer resources. Hard Facts summarizes this problem as “Be careful what you wish for, you might just get it.” The question is, is there a better way?

A simple plan

Peter Drucker, in his essay on “Management by Objectives and Self-Control” talks about a device called a “management letter.” This is part of a system he used in his organizations to make sure there was a correctly-communicated understanding of what each person needed to do to help the organization reach its goals in a top-down manner, and allow each person in the organization to reflect the best way to achieve those goals back up the hierarchy — bottom up. Each manager’s subordinate writes a “management letter” twice a year to their manager.

“In this letter to his superior, each manager first defines the objectives of his superior’s job and of his own job as he sees them. He then sets down the performance standards that he believes are being applied to him. Next, he lists the things his superior and the company do that help him and the things that hamper him. Finally he outlines what he proposes to do during the next year to reach his goals.”

And so, at every level of the organization an understanding is negotiated, made, and remade every 6 months with useful information about what needs to change, and how the organization has been perceived to be changing along with some goal-setting in the language of the person that needs to reach them. The oft-forgotten part of Drucker’s title of this seminal essay is “…and Self-Control” which emphasizes the optimal state of an organization — one where supervisors understand their staff, and trust them to work with minimal supervision.

This kind of objective alignment and goal setting doesn’t lend it self to being put in an organization-wide database and relies on prioritizing effective communication and elimination of misdirection over measurable goals.

Mirror mirror

Another potential pitfall Hard Facts emphasizes is differential reward systems. Most reward systems divide the world into three groups of people; High achievers, people not worth mentioning, and people who need help. They observe that very few organizations fund their rewards significantly enough to provide substantial differences in the rewards offered to people in the three categories, but the social cost of this tiered approach is enormous. Small differences in salary can cause huge damage to self-esteem or counterproductive behaviour.

Summing up

Hard facts warns to be very careful about using financial incentives and to try very hard to use non-financial rewards. The origins of being blinded to other forms of incentive go back at least to Taylor in the 1900s and probably beyond. Simple goals and incentives can work, particularly for workers who perform tasks with a straightforward relationship between effort and productivity. Multi-dimensional roles like software and other knowledge work are very tricky to design performance incentives for. In both cases, incentives must be carefully designed not to diminish other important organizational goals.

Making goal-setting a meeting of the minds with understanding of goals flowing up and down an organizational hierarchy seems a good approach. This approach places a priority on subjective assessment against established goals and doesn’t make reward decisions any easier.

Hard Facts doesn’t offer a recipe for providing fair and worry-free compensation while avoiding the risks of poorly directed incentive systems, but it does highlight some significant issues to consider. No wonder there are so many compensation consultants available to regularly change an organization’s performance management and incentive programmes. This stuff is hard.