Motivating (and not de-motivating) Programmers by Ron Lichty

One of the great "aha"s for me as a manager was realizing that motivating people - and not de-motivating them - are two different things.

It was years ago - I think I was at Apple. One of my colleagues shared a Harvard Business Review article from the 1980s that recounted Frederick Herzberg's work in the 1950s. Titled "One More Time: How Do You Motivate Employees?", when it was republished in 1987 it had already sold more than 1.2 million reprints since its first publication 20 years earlier - 300,000 more than any other of the thousands of articles HBR had published.

Herzberg posited that motivation isn't so simple:
    ▪    there are a lot fewer factors that motivate people than we think ⁃ a lot fewer
    ▪    but there are an equal number of factors that, while they don't motivate, they'll de-motivate when they're lacking - when they go negative

By example, company policy / administration is just not a motivator - no one joins a company because of its administration. But it can sure be a major de-motivator. Almost all of us have seen companies with policies and administration that could deflate the morale of anyone.

While we summarize Herzberg's findings in our book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, and the article itself is well worth a read - his findings of what motivates and what de-motivates are general to the entire workforce population.

That led my co-author and me to adjust the categories and the weightings slightly, based on our own decades of experience managing software teams, to target those factors we believe motivate and de-motivate programmers.

Here's the chart we came up with: what we believe Herzberg would have found if he had applied his research just to programmers:

Chart showing the factors that motivate and demotivate programmers

The chart is ordered by the motivators - the blue vertical lines; these are the causes of satisfaction and thus what motivate. The red vertical lines, on the other hand, indicate the extent to which the same categories are de-motivators - causes of dissatisfaction. The height of each line, blue or red, is its statistical importance.

Notice that motivators and de-motivators are not aligned!

Stepping through the Motivators (the blue) is easy, given the chart is ordered by them. Here are the motivators in the order that we believe drive programmers to do great work:
    ▪    Making a Difference in the World
    ▪    Learning and Growing
    ▪    Toys and Technology
    ▪    Recognition and Praise
    ▪    Having fun
    ▪    Upside
    ▪    Interpersonal Relationships
    ▪    Compensation

We devised the first of these, "Making a Difference in the World," to both take in Herzberg’s category of Achievement and take it a step further to capture the reason many if not most of us started programming – the opportunity to make a difference. I remember showing off my first programs to my wife and feeling the pride of achievement. But even with those first small efforts I could see the power of the craft to positively affect the world – what a motivator that was!

It's worth noting that the 6th category, "Upside" - that would be stock, stock options, bonuses, that sort of thing - is the first mention of money, and it's 6th down the order! And "Compensation" doesn't come in until 8th! (That's about where Herzberg puts "Compensation" for the general population, too, by the way.) Once you're paying people enough - adding more comp is just not that significant a motivator.

Stepping through the De-motivators (the red) (lack of these are the reasons programmers quit) is a bit harder. Starting with the highest red line, here are the factors in the order we believe they de-motivate programmers:
    ▪    Lack of respect for supervisor
    ▪    Lack of having fun
    ▪    Lack of learning and growing
    ▪    Working conditions
    ▪    Company policies and administration
    ▪    Lack of ethical management
    ▪    Compensation

Notice the first of those is out-and-out us - poor performance by their manager! Programmers may not hire into a company out of respect for their new manager, but they'll surely consider leaving if they don't respect their manager. In fact, there's a rule of thumb in H.R. that "People don't leave their companies. They leave their managers."

"Having Fun" and "Learning and Growing" appear on both lists - motivators and de-motivators. Contributing to making your environment a fun place to work and ensuring that staff have opportunities to learn and grow are enormously important both to retention (keeping your people from leaving) and to keeping your people engaged and productive. And then come "Working Conditions" and "Company Policies and Administration". Fighting for your people and their needs - and shielding them from corporate politics and inanities - are critical contributions managers must make. Again, people don't hire in for the working conditions or the company policies, but they'll surely leave because of bad ones. And then there's "Ethical Management" - whether from a team's direct manager or all the way to the execs, lack of ethics will squeeze the life out of a programming team.

Much as for the motivators, it's only then, this time 7th on the list of de-motivators, that we come to "Compensation"! (Also near where Herzberg placed it for the general population.)

In fact, my coauthor and I issue warnings - in our discussions of motivating programming teams - about attempting to motivate with money, and the studies and experience that lead us to issue those warnings.

There's not room in a single blog post to discuss every factor, show you where our chart differs from Herzberg's observations of the general populace (and describe why), flip the chart to order it by the de-motivators, share with you the other two motivation theorists we find incisive and wrote about in Managing the Unmanageable, or delve more deeply into why, in general, we caution against motivating with money.

But I'm hoping it's enough to clearly show the tightrope that programming managers walk to motivate their teams and the individual programmers that comprise them - and not deflate their motivation.

And I'm hoping it will suggest how project managers, program managers, product managers and other team leaders, by being aware, can collaborate with programming managers in motivating (and not de-motivating) programming teams.