The Developer Incentive Snakepit
Getting Incentives Wrong
A while ago I was talking to a friend of mine, and he told me that developers in his shop get monetary bonuses for absorbing additional scope in a “waterfall” project. (I use quotes because I don’t think that “waterfall” is actually a thing — I think it’s just collective procrastination followed by iterative development) . That sounds reasonable and harmless at first. Developers get paid more money if they are able to adapt successfully to late-breaking changes without pushing back the delivery date. Fair enough…. or is it?
Image credit to Renaud d’Avout d’Auerstaedt via wikimedia commons.
Let’s digress for a moment. In colonial India, the ruling British got tired of all of the cobras hanging around and being angry and poisonous and whatnot, so they concocted a scheme to address this problem. Reasoning that more dead cobras meant fewer living cobras, they began to offer a reward/bounty for any cobra corpses brought in to them by locals. As some dead cobras started coming in, circumstances initially improved, but after a while the number of dead cobras being brought in exploded even though the number of living cobras actually seemed to increase a little as well. How is this possible? The British discovered that Indian locals were (cleverly) breeding cobras that they could kill and thus cash in on the reward. Incensed, the British immediately discontinued the program. The cobra breeders, who had no more use for the things, promptly discarded them, resulting in an enormous increase in the local, wild cobra population. This is an iconic example of what has come to be called “The Law of Unintended Consequences“, which is a catch-all for describing situations where an incentive-based plan has an effect other than the desired outcome, be it oblique or directly counter. The Cobra Effect is an example of the latter.
Going back to the “money for changes absorbed” incentive plan, let’s consider if there might be the potential for “cobra breeders” to start gaming the system or perhaps less cynical, subconscious games that might go on. Here are some that I can think of:
- Change requests arise when the actual requirements differ from those defined initially, so developers have a vested interest in initial requirements being wrong or incomplete.
- Change requests will happen if the marketing/UX/PM/etc stakeholders don’t communicate requirements clearly to developers, so developers have a vested interest in avoiding these stakeholders.
- Things reported as bugs/defects/issues require changes to the software, which developers have to fix for free, but if those same items were, for some reason, re-classified as change requests, developers would make more money.
- The concept of “change request” doesn’t exist in agile development methodologies since any requirement is considered a change request, and thus developers would lose money if a different development methodology were adopted.
So now, putting our more cynical hats on, let’s consider what kind of outcomes these rational interests will probably lead to:
- Developers are actively obstructionist during the “requirements phase”.
- Developers avoid or are outright hostile toward their stakeholders.
- Developers battle endlessly with QA and project management, refusing to accept any responsibility for problems and saying things like “there was nothing in the functional spec that said it shouldn’t crash when you click that button!”
- Developers actively resist changes that would benefit the business, favoring rigidity over flexibility.
Think of the irony of item (4) in this scenario. The ostensible goal of this whole process is to reward the development group for being more flexible when it comes to meeting the business demands. And yet when incentives are created with the intention of promoting that flexibility, they actually have the effect of reducing it. The managers of this department are the colonial British and the cash for absorbed change requests is the cash for dead cobras. By rewarding the devs for dead cobras instead of fewer cobras, you wind up with more cobras; the developers’ goal isn’t more flexibility but more satisfied change requests, and the best way to achieve this goal is to generate software that needs a lot of changes as far as the business is concerned. It’s an example of the kind of gerrymandering and sandbagging that I alluded to in an earlier post and it makes me wonder how many apparently absurd developer behaviors might be caused by nonsensical or misguided incentive structures triggering developers to game the system.
So what would be a better approach? I mean with these Cobra Effect situations, hindsight is going to be 20/20. It’s easy for us to say that it’s stupid to pay people for dead cobras, and it was only after ruminating on the idea for a while that the relationship between certain difficulties of the group in question and the incentive structure occurred to me. These ideas seem generally reasonable on their faces and people who second guess them might be accused of arm-chair quarterbacking.
Get Rid of Cobras with Better Incentives
I would say that the most important thing is to align incentives as closely as possible with goals and to avoid rewarding process adherence. For example, with this change request absorbed incentive, what is the actual goal, and what is being rewarded? The actual reward is easy, particularly if you consider it obtusely (and you should): developers are rewarded when actual requirements are satisfied on time in spite of not matching the original requirements. There’s nothing in there about flexibility or business needs — just two simple criteria: bad original requirements and on-time shipping. I think there’s value in stating the incentive simply (obtusely) because it tends to strip out our natural, mile-a-minute deductions. Try it on the British Empire with its cobra problem: more cobra corpses means more money. There’s nothing that says the cobra corpses have to be local or that the number of cobras in the area has to decrease. That’s the incentive provider being cute and clever and reasoning that one is the logical outcome of the other.
Flexibility image credit to “RDECOM” via wikimedia commons.
Going back to the bad software incentives, the important thing is to pull back and consider larger goals. Why would a company want change requests absorbed? Probably because absorbed change requests (while still meeting a schedule) are a symptom (not a logical outcome, mind you) of flexibility. Aha, so flexibility is the goal, right? Well, no, I would argue. Flexibility is a means rather than an end. I mean, outside of a circus contortionist exhibit, nobody gets paid simply to be flexible. Flexibility is a symptom of another trend, and I suspect that’s where we’ll find our answer.
Why would a company want to be flexible when it comes to putting out software? Maybe they have a requirement from the marketing department stating that they want to cut a sort of hip, latest-and-greatest feel, so the GUI has to constantly be updated with whatever latest user experience/design trends are coming from Apple or whoever is currently the Georgio Armani of application design. Maybe they’re starting on a release now and they know their competition is coming out with something in 3 months that they’re going to want to mimic in the next release, but they don’t yet know what that thing is. Maybe they just haven’t had any resources available to flesh out more than a few wireframes for a few screens but don’t want all progress halted, “waterfall” style, until every last detail of every last screen is hammered out in IRS Tax Code-like detail.
Aha! Now we’re talking about actual business goals rather than slices of process that someone thinks will help the goals be achieved. Why not reward the developers (and QA, marketing, UX, etc as well) for those business goals being met rather than for adherence to some smaller process? Sadly, I think the answer is a command and control style of hierarchical management that often seeks to justify positions with fiefdoms of responsibility and opacity. In other words, many organizations will have a CEO state these business goals and then hand down a mandate of “software should be flexible” to some VP, who in turn hands down a mandate of “bonuses for change requests absorbed” to the manager of the software group or some such thing. It is vital to resist that structure as much as possible since providing an incentive structure divorced from broader goals practically ensures that the prospective recipients of the structure care nothing whatsoever for anything other than gaming the system in their own favor. And in some cases, such as our case, this leads to open and predictable conflicts with other groups that have (possibly directly contradicting) incentive structures of their own. As an extreme example, imagine a tech group where the QA team gets money for each bug they find and the developers lose money for the same. A good way to ensure quality… or a good way to ensure fistfights in your halls?
Take-Away
Why keep things so simple and not fan out the deductive thinking about incentives, particularly in the software world? Well, software people by nature are knowledge workers that are paid to use well-developed, creative problem-solving skills. Incentives that work on assembly line workers such as “more money for more holes drilled per hour” are more likely to backfire when applied to people who make their living inventing ways to automate, enhance and optimize processes. Software people will become quickly adept at gaming your system because it’s what you pay them to do. If you reward them for process, they’ll automate to maximize the reward, whether or not it’s good for the business. But if you reward them for goals met, they will apply their acute problem solving skills to devising the best process for solving the problem — quite possibly better than the one you advise them to follow.
If you’re in a position to introduce incentives, think carefully about the incentives that you introduce and how closely they mirror your actual goals. Resist the impulse to reward people for following some process that you assume is the best one. Resist the impulse to get clever and think “If A, then B, then C, then D, so I’ll reward people for D in order to get A.” That’s the sort of thinking that leads to people on your team dropping cobras in your lunch bag. Metaphorical cobras. And sometimes real cobras. If you work with murderers.
There are few things in life more frustrating than pouring a good amount of effort into something only to have it shot down without any kind of satisfying explanation of the rationale. For children this tends to be unfortunate for self interested reasons: “I want to do X in the immediate future and I can’t.” But as you get older and are motivated by more complex and nuanced concerns, these rejections get more befuddling and harder to understand. A child making a case for why he should own a Red Rider BB Gun will understand on some level the parental objection “it’s dangerous” and that the parental objection arises out of concern for his welfare. So when the “enough — I’m your parent and I say so” comes up it has the backing of some kind of implied reasoning and concern. An adult making a case that adopting accounting software instead of doing things by hand would be a money saving investment will have a harder time understanding an answer of “no, we aren’t going to do that because I’m your boss and I say so.”
To drive the point home, consider a conversation with a friend or family member instead of a mere acquaintance. Consider that in this scenario the “you’re wrong” would probably be good-natured and said in jest. “Dude, you’re totally wrong–everyone knows red is the best color!” That would roll off your back, I imagine. The first time, anyway. And probably the second time. And the third through 20th times. But, sooner or later, I’m pretty sure that would start to wear on you. You’d think to yourself, “Is there any matter of opinion about which I’m not ‘wrong,’ as he puts it?”
I didn’t really go into details there, but there are many ways to be active, rather than reactive, about being blocked (I think most would have said “proactive”, but I think I kind of hate that word for seeming bombastically redundant — but don’t mind me if you use it because I’m weirdly picky and fussy about words). Taking action not to be blocked has a variety of benefits: alleviates boredom, helps your company, boosts your reputation, opens up potential additional opportunities, etc. The way I see it, being blocked is something that you can almost always manage and opt out of. When I worked in retail many years ago, there was an adage of “if there’s time to lean, there’s time to clean.” I would say the equivalent in the world of software development is “if you’re blocked, you aren’t trying hard enough.”
So far I’ve talked a lot about the Expert Beginner–his emergence, his makeup, his mindset, and a relatively sympathetic explanation of the pseudo-rationality, or at least understandability, of his outlook. But how does this translate into support of my original thesis that Expert Beginners cause professional toxicity and degeneration of software groups? To explain that, I’m going to return to my bowling analogy, and please bear with me if the metaphor is a touch strained. For those of you who didn’t read the first post, you might want to give the second section of it a read because this is a lot to rehash here.
The bowlers who don’t leave learn two interesting lessons from this. The first lesson they learn is that if they wait their turn, they can wield unquestioned authority regardless of merit. The second lesson they learn is that it’s okay and even preferred to be mediocre at this alley. So when new bowlers are hired, in the interests of toeing the company line and waiting their turn, they participate in the inculcation of bad practices to the newbies the same way as was done to them. The Expect Beginner has, through his actions and example, created additional Expert Beginners and, in fact, created a culture of Expert Beginnerism.
