Motivation 2.0

How are you engaging your team? Are you running a regular appraisal cycle where everyone’s individual score is totted up and ultimately dictates financial reward (pay increase, bonus, share options) or, on the other side of the scale, performance improvement plans?

How are you finding this?

Do people who get the financial rewards become more engaged and effective throughout the year? Do those on the performance improvement plans “pull their socks up” and become superstars now that they know they’re not performing to expectations?

I wouldn’t be at all surprised if the answer is no. I’ve never seen this approach actually make any difference & the psychology behind this backs me up.
The title of this blog is taken from the book “Drive: The Surprising Truth About What Motivates Us” by Daniel H Pink. It’s backed up with scientific studies on the psychology of motivation and problem solving. I highly recommend it.

The book talks about the legacy Motivation 1.0 – this is the ‘carrot and stick’ motivation approach that the human race has employed for hundreds of years. It works in certain circumstances, primarily those in which the work is monotonous and just requires effort. It works by manipulating base animal drives like fear and avoidance of pain.

However, when you consider modern software development, the work is complex, requires deep thought, high collaboration, fast learning and creative thinking – this is demonstrably not improved by injecting fear of bad performance, in fact it’s greatly hindered. It’s also not improved by higher pay or bonuses – us humans are very good and getting used to new things very quickly and just raising our expectations to a ‘new normal’.

So what does work? Pink identifies the following things:

Autonomy

There’s a well established psychological principle that the more say you have over your situation the happier you are. If you try to control things you do not actually have control over, you’re in for a frustrating time. Giving autonomy can be considered difficult when we necessarily need people to do things that the business needs, not just whatever they feel is important. However, this apparent difficulty is not as problematic as it first appears. I find people do tend to want to work towards a greater goal rather than go off and do some tangential thing. To maximise autonomy without compromising business objectives: avoid things like handing people detailed designs to code up, instead focus on clear objectives and the reasoning behind these objectives – exactly how the solution is reached on a technical level is what provides autonomy. Developers like to problem solve! Use review cycles and mentoring to minimise the chances of the technical solution straying too far from an agreed path.

Mastery

People want to be good at their jobs, people want to be looked up to as a mentor, but more than that, there’s a great deal of satisfaction that comes from understanding a subject at a deep level.Develop mastery in your team by giving them the space to learn & entrusting them with ownership. Avoid dictating how things should be done. Instead, provide guidance and accept that making mistakes is an important part of the learning process.

Purpose

Why are we doing what we’re doing? A purpose can be an individual one (e.g. teaching others) or it can be a company one (e.g. “to organize the world’s information and make it universally accessible and useful.”). This is part of the reason why it’s so important to have a mission statement that gives employees a wider purpose to what they do.Use 1-2-1s or informal conversations to understand the individuals in your team and help them identify the sort of purpose that motivates them.