The Art of Project Management: Expert advice from experienced project managers in Silicon Valley, and around the world
TOPICS:

Motivating (and not de-motivating) Programmers

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 will de-motivate when they’re lacking – when they go negative

For example, “company policy and 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 decades of managing software teams, to specifically 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

Herzberg’s motivators and hygiene factors as we believe they apply to programmers

The chart is ordered by the motivators – the blue vertical lines – causes of satisfaction and thus what motivates. 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 those 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 having that 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!

Note 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 in order! And Compensation doesn’t come in until 8th! (That’s about where Herzberg puts it for the general population, too, by the way.) Once you’re paying people enough – adding more comp is 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 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 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. 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. 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 keeping them and to keeping them engaged and productive. And then come Working Conditions and Company Policies and Administration. Fighting for your team and its needs – and shielding them from corporate politics and inanities – are critical contributions managers can – and should – make. Again, people don’t hire in for the working conditions or the company policies, but they’ll sure leave because of them. And then there’s Ethical Management – from a team’s direct manager all the way to the execs, lack of ethics will squeeze the life out of a team.

Note that it’s only then, 7th on the list of de-motivators, that we come to Compensation! (Also not far off from 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 led 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, or get more into motivating with money (or not!).

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.

Share

About the Author

Ron Lichty has been transforming chaos to clarity and making software development “hum” for most of his 20-plus years managing software development and product organizations. Ron co-authored 2012's highly regarded Addison-Wesley title, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.managingtheunmanageable.net/ ), his co-author Pixar/Broderbund/Gracenote CTO Mickey Mantle. With over 70 years of combined experience, these two software industry veterans crafted a book designed to help any software manager be more successful. Having spent their careers developing software, leading software development projects, and managing programmers and teams, they distilled their experience into a book that every beginning programming manager would get value from, both to read and to pull from their bookshelves for reference. It's a book that is also helping executives who struggle sponsoring projects dependent upon software success – CEOs, COOs, CTOs, and others – to understand the craft of software development and the intricacies of how to manage software people and teams to deliver software projects successfully. Ron has repeatedly been brought in as a “VPE of Fix-It” to coach and mentor programming managers at all levels and to solve problems like painfully slow product development, past-due estimates with no delivery in sight, challenges arising from geographically dispersed teams, scalability stymied by sluggish data integration, productivity bridled by uncertainty, an "order-taking mentality" from teams that should be eagerly proactive, and teams unable to break out of research and move on to development and delivery. Ron untangles organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers. Chaos to clarity.
Creative Commons License
Note: This work and all associated comments are licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

Leave a Reply

*