Carrot or the stick

This post was originally published here.

Managerial styles regarding motivation interest me from time to time, and I always like to refer to a series of articles from Joel Spolsky:

• http://www.joelonsoftware.com/items/2006/08/08.html
  • http://www.joelonsoftware.com/items/2006/08/09.html
    • http://www.joelonsoftware.com/items/2006/08/10.html</ul> In these articles, Joel describes a set of managerial styles and what kinds of motivation they create.  Whenever I’m trying to introduce different practices or ideas, I’ve always kept these styles in the back of my mind, as it’s very easy to drop into a negative style without noticing.

    The idea behind the carrot or the stick is that there are basically two ways to motivate a mule to do anything.  You can either dangle a carrot in front of him, to entice him to go forward, or beat him with a stick, to punish him for not going forward.

    The Carrot

    Relating a carrot to a development team, it could be financial or other kinds of rewards for following a certain practice.  Practices could be lines of code written, tests introduced, pages of documentation written, etc.  If the developer meets some bar, they will be rewarded.  The problem is that this style creates extrinsic motivation.  That is, I’m not doing a certain action because it matches my values and goals, but meets someone else’s seemingly arbitrary measurement.

    What happens in practice is that developers are smart, and will do only what is minimally required to meet the goal if the measurement is a fixed point.  If the reward is on a sliding scale, developers will game the system, play the numbers game, and make themselves appear better in the eyes of the measurement, regardless if the underlying system has actually improved.

    Consider paying employees or contractors based on lines of code written.  The problem with that measurement is that the most maintainable, clear, soluble systems are usually an order of magnitude less code than a poorly written system.  With this measurement, the poorly written system will net the developer a greater financial reward, so there is no motivation to create a better system.

    The Stick

    The opposite of the reward would be the punishment.  If a developer does not perform a specific action, they will be punished in some form, whether it’s verbal, monetary, lower review scores, etc.  Again, this creates extrinsic motivation.  The developer is smart enough to do just enough to not get punished, without any regards to the values behind the actions/processes.

    Suppose we mandate code comments as part of our review process.  If you don’t have your code commented, your review score is lowered.  It’s not possible to measure the quality of the comments, but just that they exist.  What would happen would be the comments would exist, but they would be sloppy, misleading, and in some cases, completely incorrect.  The developer doesn’t care why code comments are valuable and necessary, but only that if they don’t put them in, their annual review score will suffer.

    A third option: shared values

    The final option is the “identify” style.  This is where I get the mule to identify with my goals, share them, and move forward together.  When I introduce new ideas, I usually start with the values I’m trying to reinforce.  We can argue over the validity of practices and processes, but it’s easy to see whether or not a practice supports a value.  A development team does a much better job determining if a practice doesn’t do a good job supporting our values than quibbling over individual practices.

    The only times shared values have worked for me is in close-knit, collaborative development teams.  If developers are treated like commodities, only the carrot and the stick will work, with uninspiring results.  With a highly collaborative team, as agile practices reinforce, the team not only better identifies with internal values, but external ones as well since each member is acquainted with a shared value system.  When management has a process requirement, it would have a much higher success rate within the team if the team can identify with the values and goals behind the requirement.

    Final thoughts

    Certain styles are needed for certain contexts and people.  If a highly collaborative team is possible and obtainable, the “identify” style will reap the greatest rewards.  Most developers are smart enough to game systems based on extrinsic motivation, and will welcome opportunities for intrinsic motivation.  If someone refuses to respond to shared values, that’s when the carrot or stick needs to come out.  It’s only when dealing with a jackass that a carrot or stick is needed.