Aligning Incentives in Software Development
Shit happens.
Sometimes it happens because you screwed up, sometimes it happens because somebody else screwed up, and sometimes, well, it Just Happens.
Relying on it not happening is a sucker’s bet — don’t go there, especially when it comes to software. Software will not, and can not, be defect free (•).
Sometimes it happens because you screwed up, sometimes it happens because somebody else screwed up, and sometimes, well, it Just Happens.
Relying on it not happening is a sucker’s bet — don’t go there, especially when it comes to software. Software will not, and can not, be defect free (•).
A far, far better approach is to assume that it will happen, and set things up so that you can deal with the aftermath — limit the blast radius, clean up the detritus, fix the bug, deploy the update, compensate the afflicted, etc.
And that, my friends, finally gets us to Incentives — the carrots and sticks — which ensure that all the parties are committed to, appropriately, dealing with the aftermath. The sticks, in this case, are “the pain and suffering caused by the issue”, and the carrots as “relief from this pain”.
The way to align incentives, is to make sure that that the people who can actually resolve an issue should feel pain from the issue as soon as possible, and this should let up at resolution.
Mind you, i’m not advocating shock-collars (that would be … illegal. Then again, maybe — have you actually read your employment agreement?). I’m referring more to stuff like “the developer in charge of the API stack gets notified when the API latencies go south”. Note that this is not the same as saying “page the sysadmin when the server crashes” — what we’re looking for here is long-term resolution of the issues, e.g.
• Why are the APIs going south?
• Are other components involved? Perhaps a change in user-behavior?
• What will be involved in remediation?
etc.
Mind you, i’m not advocating shock-collars (that would be … illegal. Then again, maybe — have you actually read your employment agreement?). I’m referring more to stuff like “the developer in charge of the API stack gets notified when the API latencies go south”. Note that this is not the same as saying “page the sysadmin when the server crashes” — what we’re looking for here is long-term resolution of the issues, e.g.
• Why are the APIs going south?
• Are other components involved? Perhaps a change in user-behavior?
• What will be involved in remediation?
etc.
Do note that the larger the team, the more complicated this gets — sometimes you end up being the recipient of the pain associated with somebody else’s issue (you’re customer support, or you wrote the API handler, or whatever). In either case, if at all possible, you should get the pain transferred over. And yes, please, if you have any authority whatsoever, don’t let it get to this state in the first place!
On a related note, “pain & suffering” does not strictly mean “things that break”. It can be soft in nature, e.g., are you pissed off that you don’t get credit for the things you did, your uptime, etc.? In this case, your remediation consists of better reports, dashboards, and so forth (••).
Note that, again, the key here is aligned incentives!
Note that, again, the key here is aligned incentives!
The bottom line is that those who suffer from an issue should have the power/ability to fix it, and vice-versa — those who have the power/ability to fix an issue should feel the pain.
(•) Yeah, yeah. Formal code verification tools, etc. Allow me some nuance here, ok?
(••) You might also talk to finance to put some numbers against your dashboards. “$275K/month saved” can be a very powerful statement!
Comments