The Use of Incentives
As usual, I had David Linthicum’s Real World SOA Podcast on during my drive into work today. I’m not going to pick on Dave today, however, as he was just the messenger. In fact, I liked that this week’s podcast mentioned the need for systemic change several times, which is a message that we need to continue to send out. See my last post for more on that subject. Anyway, Dave walked through this post from Joe McKendrick of ZDNet, entitled “Ten ways to tell it’s not SOA.” I hadn’t read this yet, but one item in particular stuck out when Dave mentioned it:
5) If developers and integrators are not being incented or persuaded to reuse services and interfaces, it’s not SOA. Without incentives or disincentives, they will keep building their own stuff.
The word in there that concerns me is “incented.” Many advocates for reuse also recommend some form of incentive program. Clearly, incentives are a possible tool to leverage for behavior change, but we’re much smarter than Pavlov’s dogs. Sometimes, people get too focused on the incentive, and not enough on the behavior. How many times do professional athletes put up big numbers in the last year of a contract because they’re “incented” by the free agent market in the upcoming off-season, only to then flop back down to their career .237 average after signing their multi-million dollar deal. Years ago, I was on a tiger team investigating what it would take to achieve reuse at our organization, and a co-worker would simply say, “Their incentive is that they get to keep their job.” Too often, incentives focus on one-time behaviors, rather than on changes that we want to become normal behavior.
As a very specific example on the risk associated with incentives, I’ve previously posted on how we need to provide context on the degree to which a service might be applicable in my horizontal and vertical thinking post. If you are a developer working in a “vertical” domain, the opportunity to write shared services simply doesn’t exist. Should that developer be penalized for not producing a reusable service? An incentive focused on writing shared services is meaningless for that developer. It’s like making a blanket statement to a baseball team that anyone who hits 20 home runs in a season will get an extra million dollars. You don’t want everyone swinging for the fences every at bat. Sometimes you need to lay down a sacrifice bunt. What about the pinch hitter who only get 100 at bats the whole season? Should they be unfairly penalized?
For me, there’s simply too a big of a risk of having incentives based on something that’s easy to quantify, rather than the actual desired behavior, and when applied to a broad audience, leaves some people out in the cold with no chance of getting the incentive through no fault of their own. Incentives are best used where a one-time change in behavior is needed due to extenuating circumstances, they should not be used to create behavior that should be the norm to begin with. As my colleague said, for normal behavior, your incentive is that you get to keep your job.
4 Responses to “The Use of Incentives”
Leave a Reply
You are right – it’s best not to incentivise at all than to put a half-assed incentive in place.
But that is not to say “don’t incentivise normal behaviour”. After all, sales people are incentivised to continue selling through their commisison payments. And this should be normal behaviour for sales people. Why shouldn’t similar concepts apply to coders?
If it is too hard to figure out the right incentive then either (a) you need to figure harder how to incentivise or (b) you’re trying to incentivise the wrong behaviour.
@Alan: I completely disagree.
Incentives (or pay for performance) at the individual level is rife with trouble.
http://www.evidence-basedmanagement.com/research_practice/commentary/pfeffer_congressional_testimony_08mar2007.html
The link above is to testimony given to the US House about P4P applied to the postal service. I found a couple of points very interesting. While the postal service isn’t the same as your typical IT group, many of the concepts presented apply.
“…the idea that individual pay for performance will enhance organizational operations rests on a set of assumptions. Once those assumptions are spelled out
and confronted with the evidence, it is clear that many — maybe all — do not hold in most organizations.”
The assumptions are listed and discussed under the “The Assumptions that Underlie Individual Pay for Performance” heading in the paper.
“Many people will correctly note that individual pay for performance has increased in popularity,…..if some management approach weren’t
effective, it would not be adopted in the first place or would be abandoned….this line of reasoning is completely fallacious…management fads and
fashion repeatedly illustrate the widespread adoption of techniques that have little or no value…”
“One of the reasons why pay for performance plans frequently fail is that they are seen as arbitrary and capricious….In most work situations, there is substantial interdependence, making the assignment of relative contributions necessarily complex and subjective.”
Pay people a fair wage. Outline what is “normal” behavior. If they don’t perform the normal behavior, let them go.
I, for one, have grown weary of every company paying their people as though they were car salesmen. IMO, it’s a con. It’s a strategy to reduce salary expenses based on the false promise of potential high pay–if you meet all the objectives. “Your base is 100k but your bonus can bump you to 125k.” So you’re lured in with a “promise” of a max of 125k. In reality, it typically amounts to a couple of percentage points at the end of the year, if anything–regardless of if you really busted your butt or not. And the top level execs often get bonuses even when the company lost money for the year. Arbitrary and capricious.
@Alan
Are developers paid incentives to use frameworks or libraries? Not in my experience, they aren’t. So why would we use incentives to get them to use what amounts to, if implemented properly, the same thing?
If we should have been getting paid to use frameworks and third-party libraries for functionality, then I figure a couple of organizations owe me a whole lot of back-incentive pay.
Lori
Thanks for this great post Todd. This reminded me of my first management position nearly 15 years back where it was drummed into our heads by our HR (trainers) that “incentives” or “rewards” based performance does not work for highly skilled (IT) people. Motivation through leadership and example is what works.
– Yogish