Why T&M Contracts Suck the Life out of Your Development Project

In my role as a software architect with Patient Zero (www.patientzero.com.au), I'm often drawn into discussions about how to structure projects in a way that will attract and retain good developers. There is a lot involved in that: team dynamics, autonomy and accountability, technology. But invariably money comes into the discussion, and someone always pops up and says, "But we all know that it's not really about the money." The idea being that there exists a perfect level that removes money as a concern, and leaves you free to focus on the real business of assembling and motivating a team.

There is a mountain of research into what motivates people. It would seem self-evident that money has its limits; we've been told that what we really crave is respect and self-actualisation. You may even have heard of Maslow's Hierarchy of Needs, the Rosetta Stone of motivational psychology.

The theory boils down to this: there are intrinsic and extrinsic motivators.

Intrinsic motivators are ones that engage internal, higher order needs, such as respect, recognition and self-determination.

Extrinsic motivators (security, food, shelter and sex) really just equate to money in the modern world.

The theory says that intrinsic motivators are good, and extrinsic, beyond a certain level, are ineffective, and often de-motivational.

I'll give you a couple of examples of extrinsic schemes. Let's assume you are paying your devs enough that they are comfortable (ie, their pay is broadly in line with that of their peers and they are not struggling to make ends meet). To improve productivity, you decide to offer them a bonus based on the business meeting certain revenue targets. Money is an extrinsic motivator, so the theory holds that while this may initially motivate people, the effect will wear off quickly, and the bonuses won't achieve a lasting improvement.

Say instead you decide to pay a bonus based on some more direct metric, like a reduction in the number of bugs, or an increase in team velocity. It seems to work (hardly surprising), the velocity improves, the number of bugs decreases. In this case the theory holds that your extrinsic motivator may have actually had a negative impact. The team simply adjusted their estimates upward and are under-reporting bugs, reducing the transparency of metrics that could otherwise help improve quality.

The solution? Well, the theory says that you need to move higher up Maslow's Hierarchy — you need Intrinsic Motivators. Try recognising the accomplishments of your developers, make them feel valued, give them autonomy and accountability etc. All good stuff, except...

I'm sceptical, parts of this just don't seem to ring true. Maslow's Hierarchy certainly provides some useful insights, but I don't see a lot of evidence supporting the way it's being used inside organisations.

Cognitive Dissonance

There is a concept called "cognitive dissonance", which is the observation that reconciling competing beliefs or ideas can have a negative impact on the performance of an individual. I think developers are highly sensitive to cognitive dissonance, and that they will invariably make decisions that attempt to reduce the inherent contradictions in the systems and people around them.

You can recast the previous examples inside a framework informed by cognitive dissonance. In the first example you are paying developers a bonus that is significantly decoupled from circumstances under their control — they have little control over how the product is sold and marketed, or the selection and prioritisation of features. Yes, they can build better software, but unless you can demonstrate a clear correlation between their day to day activities and what the business earns, it's nothing more than a pay rise. There is no real change in the alignment of what they do and how they are paid; there is no positive gain in motivation.

The second example elevates what should be internal team metrics (bugs and velocity), to performance criteria used to value the team's contribution to the business. You are essentially asking them to self-assess their worth, and doing so in a way that increases cognitive dissonance. "I believe that I'll be a better developer by admitting to bugs and working on ways to reduce them. Contradiction: I want to please the business; the business has said that my worth to them is coupled to how few bugs I produce".

In both examples, the problem is not with the selection of an extrinsic motivator; it's how you have structured it.

And the same is true for intrinsic motivators; there is a glaring incongruity between getting your name engraved on a plaque, and your boss buying his third Tesla (for the year). You might want to consider timing and context before introducing such a scheme.

Maslow as a Pie

One of the problems with using Maslow's Hierarchy to inform organisational motivational theory is that it justifies its conclusions through a process of contrapositive deduction. It makes the penetratingly obvious point that it's futile to worry about issues of self-actualisation when you are starving, but it doesn't automatically follow that the lower levels cease to be significant motivational influences once satisfied. A lot of the research that attempts to quantify the effective difference between intrinsic and extrinsic motivators simply demonstrates how hard it is to construct schemes that work well. Money is a powerful motivator, but it fails without a strong, internally consistent alignment between both individual and organisational values. By all means, keep giving out your Developer of the Month award, but if you are pinning your hopes on it to retain and motivate a talented development team, I think you'll be disappointed.

So what works? The only one I'm 100% certain of is the garage start-up. A small group of people with a dream to own something, build something, earning something; total alignment between intrinsic and extrinsic motivators. You want to make more money? Get better at making customers happy. You want to be a better developer? Get better at making customers happy, (and make more money as a side-effect). I think it's the basic insight behind lean; Maslow should be a pie, not a pyramid, every segment is coupled and the more you are tempted to pull apart those connections, the greater the risk that something will go awry.

I'm curious as to what strategies people have found effective (and ineffective) in motivating developers?